You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Case 1. MySQL(쓰기+읽기) 1대 -> MySQL SPOF이긴 함
Case 2. MySQL(쓰기) 1대 + MySQL(읽기) 3대
Case 3. MySQL(쓰기) 1대 + MySQL(읽기) 3대 + Redis(읽기+쓰기) 1대 -> Redis 중단되면, MySQL에서 사용자 요청 처림
Case 4. MySQL(쓰기) 1대 + MySQL(읽기) 3대 + Redis(쓰기) 1대 + Redis(읽기) 3대
딜 상품
계획
LookAside 캐시 전략으로 Redis 를 캐시 서버로
고려사항
Redis가 죽게 되면?
상품이 수량만 선택하는게 아니라, 색상 옵션, 사이즈 옵션(S/M/L, 90/100/110/120) 등을 선택하는 상품도 있을 수도 있을 텐대 이런 경우 스키마를 어떻게 할 것인가?
재고
계획
딜 상품 목록 페이지와 상세보기 페이지의 재고수량 10초마다 갱신된 재고수량으로 보이도록 -> 서버에서 모든 클라이언트한 push 할 수 있나?
고려사항
주문
계획
고려사항
주문을 어떻게 받을 것인가? 바로 MySQL에 저장할 것인가? 캐시를 둘 것인가? 아니면 다른 거(예 : 메시지 큐)를 둘 것인가?
딜 상품 상세보기에서는 재고수량이 있었는데, 결제 완료 시점에 재고가 없게 될 수 있는데, 이 문제를 어떻게 풀어낼 것인가?
Comment
일단 빠르게 API 서버 구현한 후 AWS에 올려서 프리티어 버전으로 TPS 얼마나 되는지 측정해보고, 구체적인 설계를 진행해보려고 합니다.
What
How
DB 구조
Case 1. MySQL(쓰기+읽기) 1대 -> MySQL SPOF이긴 함
Case 2. MySQL(쓰기) 1대 + MySQL(읽기) 3대
Case 3. MySQL(쓰기) 1대 + MySQL(읽기) 3대 + Redis(읽기+쓰기) 1대 -> Redis 중단되면, MySQL에서 사용자 요청 처림
Case 4. MySQL(쓰기) 1대 + MySQL(읽기) 3대 + Redis(쓰기) 1대 + Redis(읽기) 3대
딜 상품
계획
고려사항
재고
계획
고려사항
주문
계획
고려사항
Comment
Reference
The text was updated successfully, but these errors were encountered: