id질문드립니다

네 감사합니다~ ^^

아쉽게도, 넘버만을 위한 api서버를 두고 api서버에 있는 db를 분리하더라도. 문제가 있습니다^^!

주문 서버에서 동시에 주문번호를 요청하면, 넘버만을 위한 api 서버가 아무리 많아도 db isolation이 serialize면 api 들이 순차적으로 실행됩니다.

결국 동시에 여러 요청이 오면 모든 쓰레드들이 대기하게 됩니다.

성능까지 고려해서 이런 문제를 해결하려면 동시성 관련해서 많은 부분을 깊이있게 공부해야 합니다.

성능 부분이 크게 문제가 안되면, 처음부터 데이터베이스에 락을 걸고 문제를 해결하면 됩니다.

(이 부분은 데이터베이스 락 부분을 공부해보시길 권장합니다.)

성능 부분이 크게 문제가 되는 상황이라면, 앞서 말씀드린 JPA의 낙관적 락 메커니즘을 공부해보시면 도움이 되실거에요^^

감사합니다.

혹시 넘버만을 위한 api 서버를 두고 그 api서버를 지나서 create요청이 가게 어떨까 생각이 듭니다 api서버에 있는 db는 isolation을 serialize로 두면 동시성 문제는 안생길거고, 실제 주문에 대한 요청만 넘버링이 되기 때문에 성능상에도 문제가 없을껏 같아서요. 실제 쇼핑몰을 이용하다 보면은 내가 원하는 상품까지 리스트를 불러와서 주문하기까지가 서버렉이이걸리지 실제로 주문하기 클릭하고나서는 서버렉은 잘 안 생겼던것 같아서요

kim님 안녕하세요^^

사실 이 동시성 문제가 참 어렵습니다.

말씀해주신 시나리오대로 진행하게 되면

A사용자와 B사용자가 정말 동시에 요청을 하게 되면

1. A도 51로 업데이트 하고 B도 51로 업데이트 할 수 있습니다.

이 문제를 풀려면 update value=value+1 과 같은 식으로 하면 1번 문제는 해결은 됩니다.

그런데 그 다음에 51로 업데이트 요청을하고나서 51값을 가져오는 구간이 문제입니다.

이 시점에 다른 사용자들이 정말 동시에 들어오면 A가 조회하는 값이 51이 아니라 52나 53일 수도 있습니다.

A,B가 동시에 들어오면

1. A가 51로 업데이트

2. B가 52로 업데이트

3. A가 조회하면 52

4. B가 조회하면 52

이렇게 될 수 있는 것이지요.

이 부분에 대한 해결책으로, 참고할 만한 부분은 JPA의 낙관적 락을 사용하는 방식을 공부해보시면 도움을 얻을 수 있습니다.

JPA책 16장에서 트랜잭션과 락에 대해서 설명하는 부분에 JPA의 낙관적 락 메커니즘이 자세히 설명되어 있으니 참고해보시면 도움이 될 것 같습니다^^

감사합니다.

아 그러면은 번호를 가져올 때 업데이트 -> 셀렉트로 진행하면 될 것 같습니다. 일단 새로 여청이 오면은 51로 먼저 업데이트를 하고 51값을 가져오는 것입니다. 넘버는 의미가 없는 유니크한 속성만 갖면 되기 때문에 중간에 번호를 가져가고 에러가 나서 실제 51을 사용은 안되도 문제가 생기지는 않기 때문입니다. 먼저 업데이트를 했기때뮨에 먼저 시작한 트랜잭션이 번호를 가져감을 보장할 수 있습니다

이렇게 되면 동시성도 해결이 가능할 거 같다고 생각이 듭니다. 

저는 다음과 같이 테이블을 만들어서 구현하면 좋을 듯 합니다.

필드: 날짜, 시퀀스

(2020-01, 0)

(2020-02, 0)

(2020-03, 0)

원하는 날짜가 달이면 달을 기준으로 미리 만들어두고, 일이면 일을 기준으로 미리 만들어 두는 것이지요.

그래서 1월에 100건 2월에 50건이면 다음과 같이 나올거에요

(2020-01, 100)

(2020-02, 50)

(2020-03, 0) -> 아직 2월

이렇게 구현한다고 가정했을 때, 시나리오를 다시 써 주시겠어요?

처음부터 번호 테이블에 값을 많이 생성하거나

sequence 전용 테이블을 만들어서 배치로 매달 1일마다 초기화할 것 같습니다

많이 고민하셨군요^^!

우선 1번을 해결하고 그 다음으로 가는게 좋을 것 같아서 추가 질문을 드릴께요

1) 저번달 주문을 기준으로 3배정도의 번호를 테이블에 미리 준비해둠

-> 만약 요구사항이 저번달 주문보다 수백배(예측 불가) 많은 주문이 다음달에 발생할 수 있다면 구현 방법을 어떻게 변경하시겠어요?

넵 오늘 알아보고 답변드리겠습니다 ㅎㅎ

안녕하세요. kim님^^ 좋은 질문입니다.

여러가지 해결방안이 있을 수 있는데요. 제가 바로 말씀드리면 더 많은 것을 얻어가실 수 없으니 반대로 질문을 드릴께요^^

(해답을 찾아가는 과정속에서 더 많이 배울 수 있으니까요)

애플리케이션 서버(WAS)는 2대 이상 확장될 수 있다고 가정하고, kim님이 생각하는 나름의 방법을 찾고 고민해주시면, 제가 그 방법의 장점과 단점을 말씀드릴께요^^

다양하게 고민하고, 자료도 찾아보시고 답변 주세요^^