10-12

10장 알림 시스템 설계

 

- 안정성 : 메시지가 소실되면 안 된다.

알림 로그 데이터베이스를 유지한다. (카프카?)

 

- 알림 중복 전송 방지

알림에 이벤트 ID를 부여하고 중복된 이벤트이면 버림.

 

중복 전송을 100% 방지할 수는 없다.

-> 최대 한번, 최소 한번, 정확히 한번의 옵션이 있는데 정확히 한번은 불가능 

네트워크의 복잡성과 불안정성 때문에 최대 한번이나 최소 한번 중 선택해야 한다.

유실되거나, 재전송을 하거나 ( 재전송을 중복 검사하여 최대한 막을 수는 있음 )

RabbitMQ는 최소 한번을 보증. 

 

- 큐에 쌓인 알림의 개수 모니터링 

많이 쌓이면 문제가 있는 것.

 

 

11장 뉴스 피드 시스템 설계

 

읽어오는 데이터양이 많기 때문에 캐시가 필수인 시스템

 

중요한 API 2가지는 피드 발행, 피드 읽기

 

피드 발행 : 나를 팔로우한 친구들의 뉴스피드에 업데이트

피드 읽기 : 뉴스피드를 가져옴

 

- 앞단에 인증과 처리율 제한을 두어야 함.

스팸과 같은 피드 발행 방지

 

팬아웃 : 피드 발행 시 새 피드를 친구들에게 전달하는 과정

- 쓰기 시점의 팬아웃 : 새포스팅 기록 되는 순간에 친구들 뉴스피드를 업데이트.

읽기를 하지도 않는 사용자의 뉴스피드까지 업데이트 하기 때문에 낭비가 될 수 있음

 

- 읽기 시점의 팬아웃 : 읽는 시점에 로딩이 오래 걸릴 수 있음.

 

그래프 데이터베이스 : 친구 목록을 관리하는 데에 특화된 데이터 베이스

 

그래프 데이터베이스에서 친구 목록을 가져온다 -> 피드 업데이트 거부한 친구 목록을 거른다 -> 친구 목록과 새 포스팅ID를 큐에 넣는다 -> 하나씩 꺼내어 팬아웃 작업 서버가 업데이트 한다

 

캐시 구조도 잘 생각해서 세분화 해야한다. 

 

 

 

12장 채팅 시스템 설계

 

메시지 로그 NoSQL에 저장 - HBase, 카산드라

채팅방에 따라 일정 기간의 로그를 읽어와서 최근 순서부터 보여주는 방식으로 사용 가능

 

채팅 송신 클라이언트 -> 채팅 서버 -> 채팅 수신 클라이언트

 

채팅 수신 클라이언트의 메시지를 가져오는 방식

 

1. 폴링 : 주기적으로 서버에게 물어보는 방식. 요청마다 새 커넥션

- 메시지가 없을 때도 불필요하게 자원 낭비

 

2. 롱 폴링 : 메시지가 올 때까지 연결유지. 새 메시지를 받으면 연결 종료 후 새 커넥션

- 서버 입장에서 연결 유지 중인지 알 방법이 없음.

 

3. 웹소켓 : HTTP 연결해서 웹소켓으로 업그레이드.

80이나 443 포트 그대로 사용.

양방향 메시지 전송 가능.

 

API는 stateless 서비스로 유지

채팅 서버만 상태 유지(stateful) 서비스로 제공

 

 

1:1 채팅 메시지 테이블

message_id

message_from

message_to

content

created_at

 

그룹 채팅 테이블

channel_id

message_id

message_to

content

created_at

 

id는 고유해야하고 정렬가능해야 한다. ID 생성기의 스노플레이크 방식

 

접속 상태 표시 - 수동으로 하자 혹은 heartbeat 체크