CAS(Check & Set) 값이란?
Optimistic Concurrency Control
- 문서의 일관성을 유지하기 위한 필드입니다.
- 하나의 문서에 CAS의 값이 설정이 되어 있고, 문서의 값(VALUE)가 변경될 때 마다 이 CAS의 값도 변경됩니다.
Example
- Step 1 : 클라이언트 A가 문서를 읽습니다.
- Step 2 : 클라이언트 A는 문서의 값을 1 증가 시킵니다.
- Step 3 : 클라이언트 B는 클라이언트 A가 문서를 업데이트하기 전에 문서를 읽습니다.
- Step 4 : 클라이언트 A는 문서를 업데이트를 진행합니다.
- Step 5 : 클라이언트 B는 문서의 값을 1 증가 시킵니다.
- Step 6 : 클라이언트 B는 문서를 업데이트를 진행합니다.
Example 결과는 어떠할까?
- 두 번의 문서의 값이 증가하여 문서의 값은
12가 되어야 하지만 실제11이 문서에 업데이트가 되는 것을 확인할 수 있습니다. - 데이터의 일관성 문제를 예방 위해서 보통 RDBMS의 경우 lock을 거는 방법을 사용하지만,
- 분산 DB의 경우에는 전체 분산 노드 간에 lock을 거는 것이 성능상 문제가 발생할 수 있기 때문에, CAS라는 필드를 사용합니다.
How to work CAS?
- 문서의 값이 10일 때 CAS값이 1인 경우, 클라이언트는 문서 값 10뿐만 아니라 CAS값도 같이 읽습니다.
- 다른 클라이언트가 해당
문서를 업데이트를 진행하면 CAS값도 같이 변경됩니다.
업데이트 이전의 CAS값을 가진 클라이언트가 문서를 업데이트를 진행한다면?
서버에 저장된 문서의 CAS값과클라이언트가 가지고 있는 CAS 값이 불일치하기 때문에 문서 업데이트는 실패하게 됩니다.- 실패한 클라이언트는 다시 문서를 읽어 CAS값을 조정한 뒤 문서 업데이트를 진행해야 합니다.
그렇다면 CAS를 사용하는데 문제가 없을까?
- 서로 저장하기 위해 경쟁하는 Race Condition인 경우에는 급격하게 성능이 낮아집니다.
- 문서 저장을 실패하게 된다면 다시 재시도해야하는 Cost가 필요합니다.
- 다시 문서를 읽어 문서를 저장하는 Loop안에서 Side Effect가 없어야 합니다.
- Loop에서 Message Queue로 메시지를 보내는 Logic이 있다면 예측이 불가능한 문제가 발생할 수 있습니다.