파티원과 파티장에 대한 요청을 어디선가 처리를 해줘야한다. 근데 msa로 서버가 각각 떠 있으면 요청도 분산될 것 같다
요청이 분산되면 DB에 저장해서 하면될것같긴 한데 그건 너무 비효율적이라 생각
매칭 요청 시 응답을 계속 기다리게할 순 없다. 사용자는 요청만하고 매칭은 백그라운드로 진행되야한다
중복 매칭이 되면 절대 안된다
가능하면 결제도 자동으로 되어야 한다
그래서 매칭 절차는 어떻게?
해결
파티원과 파티장에 대한 요청을 어디선가 처리를 해줘야한다. 근데 msa로 서버가 각각 떠 있으면 요청도 분산될 것 같다
-> 파티 요청을 받는 서버와 별개인 매칭 서버를 별도로 만든다.
매칭 서버는 Spring Batch보단 스케쥴러로 구현하는게 좋을 것 같다.
지정된 시간에 진행되기 보단 실시간으로 계속 매칭이 진행되야한다는 점에서 스케쥴러가 맞다라고 생각한다
파티 요청을 받는 서버에선 요청만 받고 kafka를 이용하여 매칭서버로 요청 정보를 전달해주면 된다
요청이 분산되면 DB에 저장해서 하면될것같긴 한데 그건 너무 비효율적이라 생각
-> 정말 고민 많이하였고, 매칭 서버는 1개의 서버로 동작하도록 구현 할 생각이다. 그리고 DB에 저장하게 되면 매초마다 계속 네트워크를 태워야하는 비효율적인 리소스가 계속 발생하기 때문에 kafka로 전달받은 요청정보를 Queue에 저장하여 관리할 생각이다
매칭 요청 시 응답을 계속 기다리게할 순 없다. 사용자는 요청만하고 매칭은 백그라운드로 진행되야한다
-> 1번 고민에서 해결이 됐다. 매칭을 하는 서버는 별도로 만들어 kafka를 통해 데이터를 주고받는다
중복 매칭이 되면 절대 안된다
-> 2번에서 Queue를 사용하기로 결정하였다. 자원을 공유하기 때문에 동시성 이슈가 발생한다. Queue를 설계할땐 Thread-safe하게 설계를 한다.
가능하면 결제도 자동으로 되야한다
-> 파티 매칭 요청을 받을 때 기본적인 정보를 받아놨다가 백그라운드에서 매칭이 진행되면 전달받은 정보로 결제하면 될듯
그래서 매칭 절차는 어떻게?
-> 파티원,파티장 매칭 요청 -> 요청정보를 매칭서버로 전달 -> 서로 조건이 맞으면 매칭 진행 -> 매칭이 됐으면 결제 진행 -> 매칭 결과 전달
파티원과 파티장 매칭은 로직을 어떻게 만들어야 할까?
고민
해결
파티원과 파티장에 대한 요청을 어디선가 처리를 해줘야한다. 근데 msa로 서버가 각각 떠 있으면 요청도 분산될 것 같다 -> 파티 요청을 받는 서버와 별개인 매칭 서버를 별도로 만든다. 매칭 서버는 Spring Batch보단 스케쥴러로 구현하는게 좋을 것 같다. 지정된 시간에 진행되기 보단 실시간으로 계속 매칭이 진행되야한다는 점에서 스케쥴러가 맞다라고 생각한다 파티 요청을 받는 서버에선 요청만 받고 kafka를 이용하여 매칭서버로 요청 정보를 전달해주면 된다
요청이 분산되면 DB에 저장해서 하면될것같긴 한데 그건 너무 비효율적이라 생각 -> 정말 고민 많이하였고, 매칭 서버는 1개의 서버로 동작하도록 구현 할 생각이다. 그리고 DB에 저장하게 되면 매초마다 계속 네트워크를 태워야하는 비효율적인 리소스가 계속 발생하기 때문에 kafka로 전달받은 요청정보를 Queue에 저장하여 관리할 생각이다
매칭 요청 시 응답을 계속 기다리게할 순 없다. 사용자는 요청만하고 매칭은 백그라운드로 진행되야한다 -> 1번 고민에서 해결이 됐다. 매칭을 하는 서버는 별도로 만들어 kafka를 통해 데이터를 주고받는다
중복 매칭이 되면 절대 안된다 -> 2번에서 Queue를 사용하기로 결정하였다. 자원을 공유하기 때문에 동시성 이슈가 발생한다. Queue를 설계할땐 Thread-safe하게 설계를 한다.
가능하면 결제도 자동으로 되야한다 -> 파티 매칭 요청을 받을 때 기본적인 정보를 받아놨다가 백그라운드에서 매칭이 진행되면 전달받은 정보로 결제하면 될듯
그래서 매칭 절차는 어떻게? -> 파티원,파티장 매칭 요청 -> 요청정보를 매칭서버로 전달 -> 서로 조건이 맞으면 매칭 진행 -> 매칭이 됐으면 결제 진행 -> 매칭 결과 전달
고민 흔적
아래 사진은 매칭서버를 만들기 위해 고민한 흔적의 일부를 첨부해봤습니다