Redis의 분산 잠금은 낙관적 잠금입니까?

간단히 말하면 Redis는 비관적 잠금보다 구현이 더 간단하고 일부 시나리오에서 더 나은 성능을 제공하는 낙관적 잠금을 사용합니다. 가볍고 빠른 캐싱 엔진인 Redis는 모든 기능을 갖춘 관계형 데이터베이스가 아니며 비관적 잠금을 사용할 필요도 없고 비용도 저렴하지 않습니다.

Optimistic Lock은 이름에서 알 수 있듯이 매우 낙관적입니다. 데이터를 얻으러 갈 때마다 다른 사람이 수정하지 않을 것이라고 생각하여 잠그지 않을 것이지만 업데이트할 때는 판단하게 됩니다. 다른 사람들이 이를 다시 변경할 것인지 여부. 이 데이터를 업데이트했습니까? 버전 번호와 같은 메커니즘을 사용할 수 있습니다. 낙관적 잠금은 처리량을 향상시킬 수 있는 다중 읽기 애플리케이션 유형에 적합합니다.

낙관적 잠금 전략: 업데이트를 수행하려면 제출된 버전이 현재 레코드 버전보다 커야 합니다. (권장 학습: Redis 비디오 튜토리얼)

Redis는 트랜잭션에 대해 매우 제한적인 지원만 제공합니다. 문제를 우회하려는 시도가 더 많습니다.

먼저 Redis는 동일한 트랜잭션에서 일련의 작업을 즉시 실행하지 않고, EXEC가 실행될 때 이를 큐에 넣습니다. 트랜잭션 실행은 전역적으로 배타적입니다. 즉, 하나의 트랜잭션만 동시에 실행되며 중간에 다른 트랜잭션에 의해 중단될 수 없습니다. Redis는 경쟁 조건을 피하기 위해 가장 간단하고 성능이 가장 낮은 방법을 사용합니다.

둘째, Redis 트랜잭션에서는 하나 이상의 작업이 실패하더라도 다른 작업은 계속 성공합니다. 즉, 롤백 메커니즘이 전혀 없습니다.

이 방법은 많은 심각한 문제를 야기합니다. 그 중 하나는 특정 값을 먼저 읽은 다음 이 값에 의존하는 작업을 수행할 수 없다는 것입니다. 왜냐하면 트랜잭션에 넣으면 동시에 실행되기 때문입니다. . 동일한 트랜잭션에서 경쟁 조건이 발생합니다. 해결 방법은 하나 이상의 변수를 모니터링하는 WATCH를 사용하는 것입니다. WATCH를 호출한 후 트랜잭션이 커밋되기 전에 다른 트랜잭션에 의해 변수 값이 수정되면 전체 트랜잭션이 실패합니다. 이는 운영체제의 CAS(비교 및 설정)와 유사합니다. WATCH가 구체적으로 어떻게 구현되는지는 모르겠지만, 지정된 변수의 버전 번호를 모니터링하는 것으로 추측됩니다.

WATCH를 사용해도 Redis 거래는 심각하게 제한됩니다. 첫째, WATCH는 읽기 작업에 작동하지 않기 때문에 데이터를 읽을 때 일관성을 얻지 못합니다. 둘째, 롤백을 지원하지 않습니다. 셋째, 동일한 변수에 대한 동시 쓰기 작업이 많은 경우 트랜잭션이 제출될 때마다 WATCH에서 모니터링하는 변수가 수정되어 트랜잭션이 여러 번 제출에 실패하므로 성능이 매우 저하됩니다. . 그러나 Redis는 원래 KV 유형의 캐시 엔진이므로 대량 읽기와 소량 쓰기 시나리오를 처리해야 하며 일관성에 대한 요구 사항이 없습니다.

Redis 관련 기술 기사를 더 보려면 Redis 데이터베이스 사용 튜토리얼 소개 칼럼을 방문하여 알아보세요!

위 내용은 Redis의 분산 잠금은 낙관적 잠금입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!