4주 김현준

Author: HyeonJun0530

week4(7장)/김현준.md

@@ -0,0 +1,64 @@
+# 분산 시스템을 위한 유일 ID 생성기 설계
+
+- auto_increment 속성은 분산 환경에서 통하지 않음
+    - DB 서버 한 대로는 불가능 + 여러 DB를 쓰면 지연 시간을 낮추기 힘듦
+        - 추가 로직 및 레이턴시가 높아짐
+
+### 다중 마스터 복제
+
+- 데이터베이스의 auto_increment를 활용하되, 다음 ID 값을 사용 중인 데이터베이스 서버 수 만큼 증가.
+    - 확장성이 좋지 않음
+        - 서버 추가 및 삭제 때 잘 동작하게 만들기 힘듦
+        - 여러 데이터 센터에 걸쳐 규모를 늘리기 어려움
+
+### UUID
+
+- UUID를 사용
+    - 충돌 가능성이 지극히 낮음
+- 단순하고 서버 사이의 조율이 필요 없으므로 동기화 이슈도 없음
+- 각 서버가 독립적으로 작동하므로 확장성도 좋다.
+- 128비트로 길며, 시간 순으로 정렬이 불가능하며, 숫자가 아닌 값이 포함된다.
+
+### 티켓 서버
+
+- auto-increment 기능을 갖춘 데이터베이스 서버를 중앙 집중형으로 하나만 사용한다.
+- 유일성이 보장되는 숫자로만 구성된 ID를 쉽게 만들 수 있다.
+- 구현하기 쉽지만 SPOF가 되어서 서버를 여러대 준비하면 동기화 이슈가 생긴다.
+
+### 트위터 스노플레이크 접근법
+
+- divide and conquer를 적용해 ID 구조를 분할해 생성한다.
+- 책의 예를 들면, 사인 비트, 타임 스탬프, 데이터센터 ID, 서버 ID, 일련번호로 64비트를 구성해서 사용한다.
+- 서버가 같은 시간이 아니라 시계 동기화를 해야할 수 있다.
+    - Network Time Protocol을 이용해 외부 서버를 통해 시간을 동기화 할 수 있다.
+
+# 8장 URL 단축기 설계
+
+- URL 단축기 설계
+    - URL을 짧게 단축 시키고, 단축된 URL로 요청이 오면 원래 URL로 안내해야 함
+- 301 Permanently Moved
+    - 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 응답이다.
+    - 영구적으로 이전되어 브라우저는 이 응답을 캐시한다.
+- 302 Found
+    - 주어진 URL로의 요청이 일시적으로 Location 헤더가 지정하는 URL에 의해 처리되어야 한다는 응답이다.
+- 서버 부하를 줄이는 것이 중요하다면 301, 트래픽 분석이 중요할 때는 302를 쓰는 쪽이 클릭 발생률이나 발생 위치를 추적하는데 유리
+
+### 해시를 이용하자 !
+
+- URL 리다이렉션을 구현하는 직관적인 방법은 해시테이블을 사용하는 것
+    - 단축 URL에도 긴 URL을 해시 값으로 대응 시킬 해시 함수를 찾는 일이 중요함
+- 요구사항에 URL에는 [0-9, a-z, A-Z] 문자들로 구성된다고 되어 있으므로 사용 가능한 문자의 개수는 62개이다.
+- hashValue의 길이는 62^n ≥ 3650억(요구사항)인 n의 최솟값을 찾아야함. (n = 7)
+1. 해시 후 충돌 해소(알려진 해시 함수 사용)
+    - 긴 URL을 줄이려면 문자열을 줄이는 해시 함수가 필요하다.
+    - CRC32, MD5, SHA-1 같이 알려진 해시 함수를 이용하면 쉽지만 길다.
+    - 계산된 해시 값에서 7글자만 이용하는게 첫번째 해결 방안
+        - 충돌 확률 상승
+        - 충돌 발생 시 사전에 정한 문자열을 해시 값에 덧붙임
+        - 충돌 해소는 가능하지만 단축 URL 생성 시 DB 쿼리 한번 더 나가 오버헤드 큼
+            - 블룸 필터를 사용하면 성능을 높일 수 있음
+2. base-62 변환
+    - 62진법인 이유는 사용 가능한 문자 개수가 62개이기 때문
+    - URL 길이가 가변적
+    - 유일성 보장 ID 생성기 필요
+- 리다이렉션 시 캐시에 저장해 성능을 높일 수 있다.