Redlock 구현 라이브러리
Java Redisson Star 9458
C# RedLock.net Star 259
Go redsync.go Star 249
뒤에 있는 알고리즘은 동일하지만, 이건 엄지척 숫자는 참으로 설득력이 있습니다.
단일 포인트 Redis 잠금
먼저 단일 포인트 Redis 잠금이 어떻게 구현되는지 간략하게 살펴보겠습니다.
잠금 가져오기
SET resource_name my_random_value NX PX 30000
클라이언트 A는 Redis를 사용하여 키-값 쌍을 설정하고 교착 상태를 방지하기 위해 시간 초과를 지정합니다. 다른 클라이언트가 접속할 때 먼저 키가 이미 존재하는지, 그 값이 "my_random_value"인지 확인합니다. 존재하는 경우 기다리십시오. 그렇지 않으면 성공하여 비즈니스 코드를 실행하십시오. 모든 클라이언트에 공유되고 알려진 개체에는 resources_name 및 my_random_value가 포함됩니다.
잠금 해제
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end
키로 얻은 해당 값이 같은지 비교하여 같으면 삭제(해제)하고, 그렇지 않으면 실패를 반환합니다.
단일 지점 Redis 잠금 결함
Redis 인스턴스가 하나만 있는 경우 오류가 발생하면 이를 사용하는 모든 서비스가 중단됩니다. 이 결함은 매우 명백합니다. 분명히 대규모 애플리케이션에는 적합하지 않습니다.
간단한 Redis 마스터-슬레이브 아키텍처에서 발생하는 문제
단일 실패 지점을 피하기 위해 우리는 하나의 마스터와 하나의 슬레이브로 구성된 Redis용 마스터/슬레이브 마스터-슬레이브 아키텍처를 구축합니다. 아래에서 이러한 문제가 발생합니다. 다음은 사용 시나리오입니다.
클라이언트 A가 마스터에 대한 잠금을 획득합니다.
이 데이터를 슬레이브에 동기화할 때 마스터가 전화를 끊었습니다(마스터와 슬레이브 간의 동기화가 비동기이기 때문입니다).
노예가 마스터가 됩니다.
클라이언트 B는 동일한 키와 값을 통해 잠금을 획득합니다. 분산 잠금 실패
Redlock 알고리즘
N(5개 가정) Redis 마스터 인스턴스가 있고 모든 노드가 서로 독립적이며 비즈니스 시스템도 간단한 호출이고 다른 유사한 메시지가 없다고 가정합니다. 재전송 클래스 보조 시스템. 아래 알고리즘을 시뮬레이션해 보겠습니다.
1. 클라이언트는 서버의 현재 시간 t0을 밀리초 단위로 가져옵니다.
5개의 인스턴스에서 동일한 키와 값을 사용하여 잠금을 획득합니다. 비즈니스 잠금을 획득할 때 클라이언트는 비즈니스 잠금에 필요한 시간보다 훨씬 짧은 시간 제한을 설정합니다. 예를 들어 잠금에 10초가 걸린다고 가정하면 제한 시간을 5~50밀리초로 설정할 수 있습니다. 다시 쓴 문장: 클라이언트가 잠금을 획득하려고 할 때 Redis가 실패하는 상황을 방지하려면 조치가 필요합니다. 시간 초과 후 다음 노드로 직접 점프합니다.
3. 클라이언트는 잠금을 획득하는 데 걸린 시간 t2(=t1-t0)를 계산하기 위해 현재 시간(t1)에서 t0을 뺍니다. t2가 잠금의 비즈니스 유효 시간(즉, 두 번째 단계에서 10초)보다 작고 클라이언트가 최소 3개(5/2+1) 플랫폼에서 잠금을 획득한 경우에만 잠금 획득을 고려합니다. 성공적인.
4. 잠금 장치를 획득한 경우 잠금 장치의 비즈니스 유효 시간은 10s-t2입니다.
5. 클라이언트가 잠금을 획득하지 못한 경우 N/2+1개 이상의 인스턴스에서 잠금이 획득되지 않았거나 유효 시간(10s-t2)이 음수일 수 있습니다. 해당 노드에서 잠금을 얻지 못하더라도 잠금을 해제하려고 시도합니다.
잠금 해제
해제는 비교적 간단합니다. 모든 인스턴스에서 해당 키를 삭제하면 됩니다.
위 내용은 Redis의 분산 잠금 Redlock 분석 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!