Server

동시성 제어

Raconer 2024. 2. 18. 22:21
728x90

동시성 제어 방법

  1. 게시물에 컬럼을 추가를 통한 구현
    • 비관적 락, 낙관적 락
    • 구성
      1. 조회시 컬럼만 읽어오면됨(장점)
      2. 쓰기시 게시물 레코드에 대한 경합이 발생(병목 발생)
        • 하나의 자원(게시물)을 두고 락 대기
      3. 같은 회원이 하나에 게시물에 대해 여러번 좋아요를 누를수있음(문제 발생)
  2. 테이블 추가를 통한 구현
    • 낙관적락, 비관적락 으로 해결 하기 힘들때
    • 구성
      1. 조회시 매번 count쿼리 연산(병목 발생)
      2. 쓰기시 경합없이 인서트만 발생(장점)
      3. 회원정보등 다양한 정보 저장 가능(장점)

위 방법 중 병목 발생

  1. 1 > 2 -> 쓰기 지점의 병목은 하나의 레코드를 점유 하고 있다.
  2. 2 > 1 -> 조회 지점의 병목은 카운트 쿼리를 매번 읽는다.

병목 해결 방법

이전에 프로세스에 대한 성질을 우선 이해한다.

좋아요 수는 높은 정합성을 요구하는 데이터인가?

  1. 좋아요 수는 데이터가 늦게 수정 되더라도 고객에게 문제가 발생하는 데이터는 아니다
    • 즉 100% 실시간성이 아니라 서비스에 문제가 없을정도로만 실시간 성만 유지 되면된다.

추천 아키텍처

!! 테이블 추가를 통한 구현을 기반으로 구성

  1. 클라이언트가 좋아요 눌렀다는 요청을 한다.
  2. 좋아요 데이터를 insert한다.
  3. 좋아요 테이블을 매번 Count 하는게 아니라 게시물 테이블에 캐싱을 해놓는다.
  4. 특정 주기 마다 실행되는 스케줄러를 사용해 좋아요 테이블을 주기적으로 읽은후에 Count한다.
  5. Count된 데이터를 게시물 테이블에 데이터를 넣어둔다.

장점

  • 고객의 요청이 몇번 오든간에 주기마다 Count 한다.

단점

  • 스케줄러를 생성하고 관리를 해야 한다.
  • 좋아요를 눌렀다고 해서 바로 좋아요 수가 변하지 않는다.
    • 클라이언트 캐싱으로 통해 어느정도 해결 할수 있다.

추천

  • Redis를 사용하면 더욱 좋다

결국

데이터의 성질, 병목 지점등을 파악하고, 적당한 기술들을 도입해 해소

728x90