1주차 면접 스터디

 

DispatcherServlet 의 역할에 대해 설명해 주세요.

 

공식 설명 

Central dispatcher for HTTP request handlers/controllers, e.g. for web UI controllers or HTTP-based remote service exporters. Dispatches to registered handlers for processing a web request, providing convenient mapping and exception handling facilities.

 

등록된 핸들러에 붙어 웹 리퀘스트, 편리한 매핑, 그리고 exception을 핸들링 해준다고 합니다.

HTTP 프로토콜로 들어오는 모든 요청을 먼저 받아서 적합한 컨트롤러에 위임을 해주는 역할을 하고 있습니다.

 

 

스프링의 디스패처 서블릿이 동작하는 과정을 설명해주세요.

 

• 클라이언트로 부터 요청이 들어왔을 때 디스패처 서블릿은 요청 정보를 HandlerMapping에 넘겨주고, 요청 URL과 매핑되는 핸들러를 검색합니다.
• HandlerMapping은 해당 요청을 처리할 수 있는 HandlerAdapter를 찾습니다.
• HandlerAdapter는 컨트롤러에 있는 비즈니스 로직을 수행한 뒤에 컨트롤러는 실행 결과를 모델에 저장합니다. 
• 컨트롤러는 모델에 저장된 view name 을 다시 HandlerAdapter에 넘겨주고, 다시 View Resolver에 반환해줍니다.
• 디스패쳐 서블릿은 View에게 모델을 전달하고 화면 표시를 요청합니다.
• 서버의 응답 결과를 클라이언트에게 반환합니다. 

왜 디브패쳐 서블릿은 요청 정보를 직접 처리하지 않고 핸들러 매핑에 검색 결과를 위임하나요?

 

디브패처 서블릿은 프론트 컨트롤러 패턴을 구현하여 공통된 작업을 처리하는 역할을 하고 있습니다. 모든 세분화된 역할을 디스패처 서블릿이 수행하게 된다면 해당 책임이 너무 많아지기 때문에

 

컨트롤러를 직접 찾는 역할은 핸들러 매핑에게 넘겨줘서 역할과 책임을 분리해서 구현한 것 입니다. 

 

여러 요청이 들어온다고 가정할 때, DispatcherServlet은 한번에 여러 요청을 모두 받을 수 있나요?

•  HTTP 요청이 들어올 때마다 각각의 스레드가 생기기 때문에 여러 요청이 병렬적으로 처리될 수 있습니다. 위와 같은 방식은 멀티 스레딩으로 작동하기 때문에 가능합니다(?)

 

수많은 @Controller 를 DispatcherServlet은 어떻게 구분 할까요?

 

아까 말했던 디스패처 서블릿은 요청 정보를 HandlerMapping에 넘겨주고, 해당 요청 정보와 일치하는 컨트롤러를 검색합니다. 

 

일치하는 결과가 찾아지면, 디스패처 서블릿은 해당 컨트롤러를 실행하기 위해서 HandlerAdapter를 실행하고, 해당 컨트롤러의 로직을 실행합니다.

 

HTTP 메서드 (GET, POST)..와 URL 정보를 통해서 수많은 컨트롤러를 구분할 수 있습니다.

 

+) HandlerMapping이랑 HandlerAdapter가 하는일에 대해서 각각 알아보기 ?

 

 

++) 인터셉터와 필터의 차이

++) WebApplicationContext가 생성되는 과정에 대해 설명해주실 수 있나요? 

 

 

출처

https://zzang9ha.tistory.com/441

Spring DispatcherServlet(디스패처서블릿) 개념부터 동작 과정까지

 

https://velog.io/@sdsd0908/Spring%EC%97%90%EC%84%9C-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%9A%94%EC%B2%AD-%EC%B2%98%EB%A6%AC-%ED%9D%90%EB%A6%84-Tomcat%EA%B3%BC-DispatcherServlet-%EC%8B%9C%EC%A0%90

Spring에서 사용자 요청 처리 흐름 + Tomcat과 DispatcherServlet 시점

 

 

Redis와 캐시

 

Local Cache와 Shared Cache에 대해 각각 말해주세요

 

Local Cache

• 서버마다 캐시를 따로 저장하기 때문에 다른 서버의 캐시를 참조하기 어렵습니다.
• 서버 안에서 작동하기 때문에 속도가 빠르다는 특성이 있지만, 상대적으로 Shared Cahce보다 수용할 수 있는 데이터가 적습니다.

Shared Cache

• 다른 서버의 캐시를 참조하는 것이 가능하기 때문에 데이터 공유가 가능합니다.
• 네트워크 트래픽을 사용하기 때문에 속도가 상대적으로 느립니다. 

 

 

+) Redis의 AOF, RDB 방식에 대해 알고 계신가요? 

 

+) 백그라운드 세이브 -> 그 이유 

 

 

 

Redis의 서버가 다운되면 데이터가 다 날라가지 않나요? 

 

+) Redis의 정보 저장 방식 인메모리를 벗어나서 디스크에 저장했습니다.

 

 

로컬 캐시를 사용하다가 확장성을 고려해 shared cached을 도입하면 어떤 문제가 생길 수 있을까요? 

 

DB와 캐시간의 정합성 문제가 발생할 수 있습니다. 로컬 캐시에 A라는 정보가 존재할 떄, 글로벌 캐시에서 Shared Cache에서 A라는 정보가 수정될 때, 로컬 캐시에는 여전히 수정 전의 데이터가 남아있어서 정합성이 깨지게 됩니다.

 

이를 해결하기 위해선, 캐시 무효화 전략, TTL, 동기화 전략등 여러 방법들을 생각해봐야 합니다.

 

데이터의 변경이 많은 값을 로컬 캐시로 관리할 때 어떤 문제가 생길 수 있을까요?

• 데이터 변경이 잦을 때 캐시를 계속 변경해야하기 때문에 이로 인한 오버헤드가 발생할 수 있습니다.

캐시를 사용하는 이유는 데이터를 신속하게 조회하기 위함인데, 갱신이 너무 빈번하다면 성능적인 장점이 없어질 것 입니다.

 

 

+) 캐시 쓰기 정책(write policy)_

 

+) 캐시 TTL이랑 RTT에 대해서 알고 계신가요? 

 

 

 

참고

https://soongjamm.tistory.com/146

카테고리에 캐시를 적용한 경험