Pessimistic Locking in Distributed Systems

https://medium.com/@_sidharth_m_/how-distributed-systems-avoid-race-conditions-using-pessimistic-locking-1dc112a82b5e

How Distributed Systems Avoid Race Conditions using Pessimistic Locking?

 

 

잠금을 획득하는 것만으로는 충분하지 않습니다

노드가 잠금을 획득한 후 해제하기 전에 동결되거나 실패하는 시나리오를 생각해 보세요. 이 경우 노드가 잠금 데이터베이스/서비스에서 잠금 해제 정보를 업데이트하지 않았기 때문에 나머지 시스템에서 볼 때 노드는 여전히 잠금을 보유하고 있습니다.

이 문제를 해결하기 위해 노드가 잠금을 획득할 때마다 잠금 데이터베이스 레코드에 잠금에 대한 임대 기간이라고도 하는 TTL(Time to Live)이 설정됩니다. 임대가 만료되면 처음에 잠금을 획득한 노드가 업데이트를 완료했는지 여부에 관계없이 공유 리소스에 대한 잠금이 해제됩니다. 이를 통해 시스템은 노드가 장애로 인해 잠금을 해제하지 못하는 시나리오를 처리할 수 있습니다.

 

 

 

 

노드가 실패하지 않고 일시 정지되었다가 다시 시작됨

이제 임대가 있는 잠금이 있으므로, 노드 A가 임대가 있는 잠금을 획득한 후 공유 리소스를 업데이트하기 전에 어떤 이유로든 일시 중지하거나 동결하는 시나리오를 상상해 보겠습니다. 이 동결 기간 동안 임대가 만료되고 나머지 시스템에 대한 잠금이 해제됩니다. 다른 노드(예: 노드 B)가 공유 리소스에 대한 이 잠금을 획득하고 그 값을 업데이트합니다. 노드 B가 리소스를 업데이트하면 노드 A는 자신이 여전히 잠금을 소유하고 있다고 생각하여 리소스에 업데이트를 푸시하여 노드 B의 업데이트를 덮어씁니다. 이렇게 되면 공유 데이터 리소스가 잘못된 상태가 됩니다.

 

펜스 토큰

이 문제를 해결하려면 시스템의 각 노드가 공유 데이터 리소스에 대한 쓰기 요청과 함께 새 펜싱 토큰을 보내야 합니다. 공유 데이터 리소스는 이미 최신 펜싱 토큰을 확인한 경우 이전 펜싱 토큰을 거부합니다. 간단히 설명하자면, 이 펜싱 토큰은 공유 리소스에 대한 잠금이 요청될 때마다 잠금 데이터베이스가 증가시키는 숫자일 수 있습니다.

이전 시나리오에서는 노드 A가 잠금을 획득할 때 펜싱 토큰 값 10을 할당받았고, 노드 A가 동결된 후 노드 B가 잠금을 획득할 때 펜싱 토큰 값 11을 제공받았습니다. 노드 B가 업데이트를 실행했으므로 공유 데이터 자원은 이미 펜싱 토큰 값 11을 보게 됩니다. 따라서 노드 A의 펜싱 토큰이 (노드 A 이후에 잠금을 획득한) 노드 B보다 작으므로 재개된 후 A가 보낸 업데이트를 거부하게 됩니다.

 

 

 

 

다른 post 참고
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

How to do distributed locking — Martin Kleppmann’s blog