멀티스레드 로직 구현 방식

1. 개체 단위 lock.

개체 수와 종류가 늘어날 수록 헬.

dead-lock 위험성도 매우 크다.

상위 개체 단위로 lock을 잠글 수도 있는데, 이마저도 상호 연관 이벤트가 늘어나면 헬이다.

사실 lock만으로 멀티스레드 로직을 구현한다는 것은 사실상 불가능에 가까운 복잡도를 만들어 낸다는 것을 이미 여러 프로젝트가 증명했다.

2. 데이터 사본 연산

그룹마다 (방 혹은 채널, 존) 스레드를 따로 생성하고 데이터 사본으로 연산 한 후 연산 결과를 이벤트로 다시 던져,  다음 턴 수행 전에 적용하는 방식이다.

기본적으로 턴(프레임이라 불리기도 하는) 단위를 잡고, 해당 단위마다 로직이 돈다는 것을 전제로 삼을 수 있어, 여러가지 계측의 기준점이 되기도 한다.

여러 그룹에서 동시 다발적인 변화가 발생해, 데이터 변경이 일어난다 해도 변경 사항들을 긁어와 턴 마다 적용하기에 문제가 생기지 않는다.

주로 응답을 message 개체로 변환해서 받기 때문에 message queue를 푸는 동작이 순서가 필요할 경우, 싱글 스레드로 풀어서 적용해도 된다.

주의 사항은 데이터가 클 경우 사본을 생성하는 과정이 무거울 수 있다는 점.

이런 과정도 delta를 잘 만들어 낼 수 있다면 가볍게 턴마다 수행 가능해, 정해진 영역 내에서는 비동기라는 생각 없이 프로그래밍이 가능하단 장점이 있다.

3. immediatly 연산

모든 오퍼레이션이 즉시 연산으로 이루어지게 설계 하는 방식이다. 현재 상황에서 즉시 알아낼 수 없는 정보는 취급하지 않거나, 티어를 옮기는 과정이 다른 요청에 영향이 없게 독립적으로 구성 되어 있어야 한다.

이 방식으로 구현하려면 middle-ware들도 non-blocking으로 응답 할 수 있는 구조로 지원되어야 한다. (혹은 그렇게 랩핑하거나)

즉시 연산을 위해선 connection (request) 대비 blocking 연산 비율이 1:1에 가까워야 한다.

가급적 cache 데이터 등에 접근해 blocking 도 줄이고, 계산 시간을 낮춰야 한다.

또한, 처리 티어를 옮겨 갔다 오게 되는 상황이 다른 요청에 영향을 끼치지 않으려면 stateless 해야 한다. (한번의 요청에 모든 필요데이터를 검증,취합,처리 해야 함을 의미)

대 다수의 web 서버가 이 구조라 할 수 있다.