Redlock의 리스 시간과 펜싱의 경계
Redis의 조건부 리스 모델과 Kleppmann·Sanfilippo의 서로 다른 주장을 구분한다. 락 획득과 자원 측 쓰기 검사는 같은 보장이 아니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
Redlock은 시간 가정 아래 제한된 리스를 조정하고 펜싱은 자원 측에서 요청 순서를 검사하는 별도 기능이다.
실제 장애 시험이 아닌 개념 설명이다.
보호하려는 자원부터 정리한다
리스는 제한된 시간 동안 작업을 조정하지만 만료 뒤 요청 전송을 스스로 막지는 않는다. Redis 문서는 주 노드의 락 획득 뒤 비동기 복제가 끝나기 전에 장애가 나는 페일오버 경쟁을 설명한다. 무작위 소유자 값은 다른 클라이언트의 락을 해제하지 않도록 돕는 값이며 모든 쓰기의 순서를 정하는 번호가 아니다. Redis 락 모델
가상의 설계 검토에서는 라이브러리보다 작업부터 적는다. 누가 권한을 주고, 누가 작업하며, 누가 결과를 받아들이는지 나누면 서로 다른 구성 요소일 수 있다. 두 작업자가 버릴 수 있는 결과를 중복 계산하는 상황과 기준 레코드를 함께 변경하는 상황의 영향은 다르다. 이 비교는 검토할 질문을 정할 뿐 검증된 구현을 선택하거나 락이 유일한 조정 방식이라고 주장하지 않는다.
과반수 획득은 조건부 시간 구간이다
현재 Redis 문서는 독립 마스터에 병렬로 획득을 시도한다. 다섯 노드는 설명용 예이며 모든 배포의 필수 수는 아니다. 클라이언트는 과반수 획득과 경과 시간을 확인하고, 획득 시간과 드리프트 여유를 제외한 유효 구간 안에 작업을 끝내야 한다. 이 설명에는 상대적인 시계 진행에 관한 가정이 따른다. 획득과 유효 시간
가상 시간선에서는 리스를 구하는 구간, 남은 리스를 보유하는 구간, 자원에 작업을 보내는 구간을 분리한다. 구체적인 숫자가 없어도 획득이 늦으면 작업 시간이 줄어드는 관계를 읽을 수 있다. 성공 응답과 최종 부수 효과를 아는 것도 다르다. 획득에서 끝나는 그림은 실제로 중요한 이후 작업을 가린다. 이는 재시도나 지연을 측정한 결과가 아닌 읽기 연습이다.
전문가의 주장은 시스템 모델에서 갈린다
Martin Kleppmann은 2016년 2월 8일 블로그에서 리스보다 오래 지속되는 중단과 지연 요청을 들어 정확성에 의존하는 용도의 Redlock을 비판한다. 효율성 논의에서는 더 단순한 락을 권하며 Redlock을 승인하는 것이 아니다. Salvatore Sanfilippo의 답변은 제한된 상대 시간 모델과 획득 경과 시간 검사를 옹호하고 획득 지연과 이후 리스 초과 작업을 구분한다. 학술 동료 심사를 거친 증명이나 합의로 표현해서는 안 된다. Kleppmann의 비판 Sanfilippo의 답변
결론과 가정을 함께 읽어야 한다. 컴퓨터의 절대 시각이 같은지와 로컬 시계의 진행 속도가 허용 범위에 있는지는 다른 질문이다. 획득 시간을 계산하는 것과 멈춘 소유자의 이후 요청을 막는 것도 다르다. 한 질문에 답한 주장을 다른 문제의 해결책으로 읽지 않는다. 과거 시계 API 변경 의도는 현재 구현의 증거가 아니다.
펜싱은 자원이 관찰한 순서에 달려 있다
Kleppmann은 증가하는 펜싱 토큰을 자원이 검사하여 이미 관찰한 더 높은 토큰보다 오래된 요청을 거부하는 방식을 설명한다. 이는 조건부 해제용 무작위 소유자 값과 다르다. 보호 자원이 참여해야 하며 만료 소유자를 즉시 모두 철회하거나 트랜잭션을 자동으로 직렬화하는 기능은 아니다. 자원 측 펜싱
가상 순서에서 옛 요청이 자원이 새 토큰을 보기 전에 도착했다면 다른 곳에 새 권한이 존재한다는 이유만으로 거부되는 것은 아니다. 권한 순서와 도착 순서를 따로 그린 뒤 어느 구성 요소가 번호를 비교하고 효과를 수행하는지 적는다. 그 검사의 신뢰성은 구현에서 확인할 조건이지 문서가 무조건 보장하는 결과가 아니다. 토큰을 검사하지 않는 외부 효과는 별도 경계로 남는다.
결론보다 먼저 가정을 검토한다
현재 Redis 페이지는 벽시계 TTL 문제를 인정하고 펜싱을 고려하도록 안내한다. 이것이 과거 두 저자의 모델을 동일하게 만들지는 않는다. 설계 검토에서는 출처의 날짜와 입장을 구분한다. Redis 일관성 주의
허용할 실패, 시간 가정, 리스 초과 동작, 자원 측 검사, 실제 증거를 검토표에 적을 수 있다. 미확인을 모든 환경에서 안전하거나 위험하다는 말로 대체하지 않는다. 한 중단 사례를 시험해도 모든 스케줄과 장애 조합을 다룬 것은 아니다. 시험하지 않았다면 시간선을 결과로 부르지 않는다. 이 글은 개념과 가상 비교를 제공하며 Redis 배포 시험이나 형식 증명, 금융 정확성의 보장이 아니다.