728x90
동시성 제어 방법
- 게시물에 컬럼을 추가를 통한 구현
- 비관적 락, 낙관적 락
- 구성
- 조회시 컬럼만 읽어오면됨(장점)
- 쓰기시 게시물 레코드에 대한 경합이 발생(병목 발생)
- 하나의 자원(게시물)을 두고 락 대기
- 같은 회원이 하나에 게시물에 대해 여러번 좋아요를 누를수있음(문제 발생)
- 테이블 추가를 통한 구현
- 낙관적락, 비관적락 으로 해결 하기 힘들때
- 구성
- 조회시 매번 count쿼리 연산(병목 발생)
- 쓰기시 경합없이 인서트만 발생(장점)
- 회원정보등 다양한 정보 저장 가능(장점)
위 방법 중 병목 발생
- 1 > 2 -> 쓰기 지점의 병목은 하나의 레코드를 점유 하고 있다.
- 2 > 1 -> 조회 지점의 병목은 카운트 쿼리를 매번 읽는다.
병목 해결 방법
이전에 프로세스에 대한 성질을 우선 이해한다.
좋아요 수는 높은 정합성을 요구하는 데이터인가?
- 좋아요 수는 데이터가 늦게 수정 되더라도 고객에게 문제가 발생하는 데이터는 아니다
- 즉 100% 실시간성이 아니라 서비스에 문제가 없을정도로만 실시간 성만 유지 되면된다.
추천 아키텍처
!! 테이블 추가를 통한 구현을 기반으로 구성
- 클라이언트가 좋아요 눌렀다는 요청을 한다.
- 좋아요 데이터를 insert한다.
- 좋아요 테이블을 매번 Count 하는게 아니라 게시물 테이블에 캐싱을 해놓는다.
- 특정 주기 마다 실행되는 스케줄러를 사용해 좋아요 테이블을 주기적으로 읽은후에 Count한다.
- Count된 데이터를 게시물 테이블에 데이터를 넣어둔다.
장점
- 고객의 요청이 몇번 오든간에 주기마다 Count 한다.
단점
- 스케줄러를 생성하고 관리를 해야 한다.
- 좋아요를 눌렀다고 해서 바로 좋아요 수가 변하지 않는다.
- 클라이언트 캐싱으로 통해 어느정도 해결 할수 있다.
추천
- Redis를 사용하면 더욱 좋다
결국
데이터의 성질, 병목 지점등을 파악하고, 적당한 기술들을 도입해 해소
728x90
'Server' 카테고리의 다른 글
[Session] Spring Boot에서의 세션 관리 (0) | 2024.02.28 |
---|---|
Session 이란? (0) | 2024.02.24 |
[낙관적락/Optimistic Lock]_기본 개념 (비관적 락/PESSIMISTIC 짧은 설명 포함) (0) | 2024.02.15 |
[비관적인락/PESSIMISTIC]_쓰기락 테스트 (0) | 2024.02.06 |
[비관적인락/PESSIMISTIC]_쓰기락과 읽기락 (0) | 2024.02.06 |