주문 번호 발급

[marinesnow34]

주문 번호 란?

위의 사진처럼 카페에서 흔히 사용하는 익명의 유저를 호출하는 방법

요구 사항

1. 주문 번호를 통해 사장님이 주문건 수를 직관적으로 파악 가능 해야 함
2. 같은 영업일, 같은 카페에 동일한 주문번호 X
3. 순차적으로 증가해야 함

문제 인식

• 같은 시간에 주문이 들어올 경우 동일한 주문 번호가 발급 됨

해결 1

• 현재는 synchronized로 해결 함

한계 1

• 다른 가게에서 동시에 주문이 들어올 경우 synchronized로 인한 성능 저하 우려

해결 2

• sequence table을 만들어 pessimistic Lock을 사용
• 다른 가게에서 동시 주문 성능 저하 개선
• 배치 돌려서 매일 번호 0으로 초기화

한계 2

• 추후 추가 기능에서 혹시 모를 dead lock이 우려스러움
• 개인적으로 db로 해결하는 것을 비선호

뇌피셜 (작성자는 redis를 잘 이해하지 못하고 있습니다.)

1. redis는 싱글 쓰레드이다. -> race condition 잘 발생 하지 않음
2. redis는 빠르다

따라서

1. key: 가게Id이고 value에 set을 사용
2. set에 orderId(UUID)를 집어 넣고 size를 가져옴
3. cron tab을 활용해서 주기적으로 set 초기화 (매일 첫 주문 고객은 1번 이여야 함)

의문? 다음과 같은 상황은 일어나지 않을 것인가??

(기대) 1번 사람이 set.push(uuid1) -> set.size() -> 결과 1개 2번 사람이 set.push(uuid2) -> set.size() -> 결과 2개 (예상) set.push(uuid1) set.push(uuid2) set.size() set.size() -> 2개 2개

[marinesnow34]

• 현재 해결2를 적용한 상태

[marinesnow34]

• 뇌피셜에 대한 해답
  • redis MULTI를 통해서 순차적(queue)으로 실행할 수 있음
  • 따라서 예상에 대한 문제는 발생 안할 가능성 높음
  • spring boot에서 기대처럼 되는지 확인해야 함

[marinesnow34]

• 레디스 동시성 관련한건 블로그에 작성했습니다.ㅎㅎ
• 결론적으로 레디스를 사용해도 레이스 컨디션 발생을 막을 수 있어요

[marinesnow34]

• 현재 상황에서 set은 비효율 적인것 같아서 key-value로 숫자 관리하는게 나을거 같네요.

[marinesnow34]

• 쓸데없는 고민이었음...
• redis INCR을 하고 리턴값 사용하면 됨