Skip to content

Latest commit

 

History

History
29 lines (19 loc) · 2.51 KB

Chapter9.md

File metadata and controls

29 lines (19 loc) · 2.51 KB

질문

근우

  • keep-alive 의 max는 하나의 커넥션에서 사용할 수 있는 Http 요청 개수이다. 시점이 동일할 때, 커넥션:스레드 는 1:N 이 아니고 1:1 이고 1:1이 반복적으로 진행되는 횟수의 최대 개수를 정의하는게 맞는지?

이슬

  • MSA 환경에서는 FeignClient를 많이 쓰는 것 같다. WebClient의 비동기/논블로킹보다 동기식인 FeignClient를 더 많이 사용하는 이유는 Retry, Circuit breaker 같은 기능을 제공하기 때문인가?

창현

  • 커넥션이라는 개념은 클라이언트-서버 또는 서버-서버간 연결일텐데 이 커넥션은 서버-서버 구조에서 살아있는 커넥션이라 가정했을 때 양쪽 서버는 커넥션이 유지되는동안 요청에 대한 쓰레드가 계속 살아 있는 것인가?

실습문제

송금이라는 서비스는 프론트 채널계, 계정계로 구성됩니다. 계정계는 모놀리식한 서버이기 때문에 많은 트래픽을 감당하지 못합니다. image

토스뱅크는 기존의 빅테크와 동일하게 무한 스크롤을 제공함으로써 거래내역을 계속해서 사용자가 볼 수 있습니다. 그렇다면 사용자의 요청의 부하가 높아져 빠른 응답속도를 위해 채널계의 DB에서도 거래내역을 가지고 반환합니다. 이때 계정과 채널의 데이터 동기화가 중요해집니다.

image

당행의 입금내역을 계정계에 보내기 전에 채널에 저장합니다. 이런 경우에는 타행의 송금내역을 볼 수 없는 문제가 발생합니다.

image

타행의 입금 내역도 알 수 있게 하기 위해 계정계에서 카프카 메세지를 프로듀싱하여 채널이 컨슘하여 동기화를 진행합니다. 이렇게 되면 모든 문제가 해결된 것 같지만 위 아키텍처는 정상적인 상황일 때만 동작하는 구조입니다.

  1. 송금 서버가 계정계에 송금 완료 요청을 보냈지만, 계정계가 반환하는 과정에서 타임아웃이 발생한다면 결과적으로 유저에게 정상적인 송금 내역이 보이지 않습니다. 이를 어떻게 해결할까요?

이후 상황은 실제 스터디에서 구두로 설명한다.