1. 로그인
JWT
Refresh Token 관리
이메일 로그인
소셜 로그인 - 사장님과 손님 소셜 로그인 방식 통일
2. 예약
한번에 들어오는 예약을 처리하기 위한 방법?
<aside>
💡
락(Lock)이란?
여러 트랜잭션이 동시에 데이터에 접근할 때 데이터의 일관성과 무결성을 보장하기 위한 메커니즘.
ex. 4,000원이 있는 계좌에 A와 B가 동시에 3,000원을 입금할 때, 최종 금액이 10,000원이 아닌
7,000원이 되는 문제를 방지.
</aside>
-
분산 락
장점
- 여러 서버에서 동시에 예약 요청 처리 가능
- 확장성 좋음
단점
-
JPA Lock
낙관적 락(optimistic lock)
- “충돌이 거의 일어나지 않을 것"이라고 낙관적으로 가정하는 방식
- 일반적으로 버전 체크 실패 시 트랜잭션을 롤백하고 재시도(재시도 로직 필요)
동작 방식
- 데이터를 읽을 때는 락을 걸지 않음
- 데이터 수정 시 버전을 확인하여 충돌을 감지
비관적 락(pessimistic lock)
- "충돌이 발생할 것"이라고 비관적으로 가정하는 방식
- 데이터에 접근하기 전 락을 획득하므로, 일단 락을 얻으면 작업 안전하게 수행 (재시도 필요X)
동작 방식
- 트랜잭션이 완료될 때까지 다른 트랜잭션의 접근을 막음
- 데이터를 읽을 때부터 락
장점
- 데이터의 일관성을 보장
- 충돌이 자주 일어나는 환경에 효과적
단점
- 동시성이 낮아 성능 저하 발생 가능
- 데드락 발생 가능
<aside>
💡
데드락이란?
둘 이상의 프로세스가 서로가 가진 자원을 기다리며 무한히 대기하는 상황.
</aside>
- 오버헤드 발생 가능
- 다른 트랜잭션이 이미 락을 보유하고 있을 경우, 대기 시간이 발생
- 데이터에 접근할 때마다 락을 획득하고 작업 완료 후 해제하는 과정이 필요
선택 기준
- 낙관적 락 : 충돌이 적고 읽기 작업이 많은 경우에 적합
- 비관적 락 : 충돌이 자주 발생하고 데이터 일관성이 매우 중요한 경우에 적합
-
큐 시스템
- 예약 요청을 큐에 저장하고 순차적으로 처리
- 대량 요청 처리에 효과적
장점
- 순차적 처리로 충돌을 방지
- 부하 분산에 효과적
단점
- 실시간 처리가 필요한 경우 지연이 발생 가능
- 큐 관리에 추가적인 리소스가 필요
-
synchronized
- 여러 스레드가 공유 자원에 동시에 접근하는 것을 방지
- 데이터의 일관성을 유지하고 race condition을 방지
-
AOP(Aspect-Oriented Programming)를 이용한 락
- 락 관련 코드를 비즈니스 로직에서 분리하여 코드의 가독성과 유지보수성을 향상
- 락이 필요한 메서드에 ‘@DistributedLock ‘을 사용하여 간편하게 락을 적용
- Redis를 기반으로 한 Redisson 클라이언트를 사용하여 분산 락을 구현
- 어노테이션이 붙은 메서드 실행 전후로 자동으로 락을 획득하고 해제
-
그 외
- CAS(Compare-And-Swap) 알고리즘 사용
- 멀티스레딩 환경에서 동기화를 달성하기 위해 사용되는 원자적 명령어
- 락(lock)을 사용하지 않고 동기화를 구현
- 트랜잭션 짧게 잡기
결론
테이블 예약의 동시성을 제어하기 위해 JPA Lock의 비관적 락 채택.
인기 있는 테이블의 동시 접근이 많아 충돌 상황에 효과적.
낙관적 락과 달리, 충돌 시 자동으로 대기하므로 별도의 재시도 로직이 필요 없음.
예약 시 짧은 시간에 충돌이 많을 것을로 예상하여 일관성을 위해 비관적 락을 사용함.
오버헤드 주의.
데드락 발생하지 않도록 주의.
락 범위 최소화.
무한대기 방지를 위한 타임아웃 설정.
3. 실시간 통신
예약 후 식당과 회원간의 1대1 채팅을 위한 방법?
사장님이 한번에 여러 손님들에게 공지를 하는 방법
예약 후 바로 알러지 여부를 물어보는 자동 설문지 등록