25.04.04 회의록 - LIMITED-TEAM25/wiki_repository GitHub Wiki

04/04 기술 논의

  • 파티션 병렬처리 문제에 대한 고민:

    • 우선적으로 100개 제한일 경우 100 안에 드는 경우는 순서가 상관없으므로, 레디스를 이용하여 제한된 개수를 처리한다.
      • 레디스에 저장시 시간 데이터도 함께 넣어서 시간 기준으로 순차적 처리를 하여 100→101 넘어가는 순간 순차적 처리에 안정성을 더한다.
      • 100번째 이후의 데이터는 레디스와 연동하여 바로바로 실패처리. *

  • 공통 사용 모듈

    게이트웨이, 카프카(메시지 전송 및 트래픽 처리/큐 관리), 레디스, 모니터링 도메인 별 이벤트 처리 서비스 -> 각 하나씩 단순 CRU 서비스 : order, product, coupon, user, preuser(체험단)

  • 레디스 관련 논의

    레디스는 1개. 근데 선착순 주문을 받아주는 주문 서비스는 여러개 이때 동시 다발적으로 레디스에 데이터를 삽입할텐데 레디스는 이 데이터가 처음에 클라이언트로 부터 받은 순서로 저장하는지 보장할 수 있는가?

    → 클라이언트로부터 주문 요청이 오면 주문 요청 시간과 유저아이디를 레디스에 저장(타임스탬프를 Sorted Set의 score로 저장하여 요청을 순차적으로 처리)

    • SISMEMBERS key value 사용시 : key에 저장된 집합에 value가 존재하는지 boolean 형태로 반환 → 시간 복잡도 O(1)
    • ㄴ 집합 형태

  • Redis + Kafka 사용 기능

    • Lua Script
      • 여러 명령을 한번에 묶어서 처리할 수 있게 해주는 기능
    • 샤딩
      • 하나의 상품ID로 하나의 파티션만 사용하는 것이 아닌, 여러개의 파티션을 사용하여 병렬처리 가능하도록 해주는 기법
      • ex) 상품 ID = 123, 파티션 0,1,2,3,4,5 존재시 : key 값을 123-0, 123-1, 123-2 로 지정하여 하나의 상품에 대해서도 병렬처리가 가능하게 한다.

  • 중복 주문 방지시 Redis의 자료구조 선택

    1. Sorted Set 이용
      • 경매의 경우 동일 가격을 적은 사람들에 한해 먼저 제시한 사람이 선점하는 정책이므로, *가격, *경매시각 을 정렬 할 필요가 있음.
      • 편의성 부분에서 이점이 강하나 성능 저하 우려 - 기능상 이점 높음
      • Set이나 Hash Set를 하게되면 정렬이 불가하므로 정렬이 가능한 Sorted Set을 사용
    2. Set 이용 → 쿠폰, 선착순
      • O(1) 으로 성능이 가장 좋고 중복제거에 좋다고 생각함.
      • 영구적으로 데이터가 삭제되지 않는 상황우려 → but, 우리의 경우 한정된 시간 안에서만 판매를 하므로 이런 부분에서 자유로울 것이라고 생각함. (한정된 시간 지난 후 레디스의 데이터를 지워주는 형태 고려)