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

(*-*)浩
풀어 주다: 2019-06-18 10:35:28
원래의
4817명이 탐색했습니다.

간단히 말하면 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!

관련 라벨:
원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿