Redis를 처음 사용했습니다. 나는 Sentinel과 Replication에 관한 문서를 읽었는데, 슬레이브가 가능한 한 마스터와 동기화를 유지하려고하는 방법에 대해 이야기했지만, 성공적인 쓰기 후에 마스터가 실패하면 슬레이브가 메시지를받지 못할 수도 있습니다 쓰다. 그런 다음 Sentinel이이 슬레이브를 새 마스터로 표시하면 슬레이브가 부실 데이터를 처리 할 가능성이 있습니다.복제가없는 Redis 마스터/슬레이브
일관성을 잃고 가용성을 선호 할 수 없다면 Sentinel이 새 슬레이브를 마스터로 표시 할 때 모든 첫 번째 요청이 캐시 누락이되고 캐시가 천천히 예열되도록 복제를 끌 수 있습니까? 잠재적으로 오래된 데이터를 반환하는 경우
또한 좋은 생각입니까? 다른 좋은 대안이 있습니까?
나는 일관성을 잃고 그것은 자동화 된 페일 오버 응용 프로그램에 적합한 레디 스가 분명하지 않다 가용성
그것을 통해 선호하는 것을 여유가있을 수 없다. 각 클라이언트는 서버 가용성을 신중하게 관리해야합니다.
몇 개의 클라이언트, 마스터, M1 및 3 개의 복제본 R2, R3, R4가 있다고 가정합니다. 클라이언트 C5는 M1에 새로운 은행 계좌 잔액을 기입하고 즉시 영구적으로 실패하며 R2는 마스터 M2가되도록 승격됩니다. Master는 클라이언트에게 회신하기 전에 복제본으로부터 승인을 얻지 못했습니다. 답장이 C5로 보내지기 전에 서버 사이에서 paxos와 같은 합의 프로토콜이 발생하지 않습니다.
C5는 각 쓰기 요청에 포함 된 카운터/타임 스탬프를 기억하고, 쓰기 페이로드를 잊어 버리고 오래된 읽기를 감지 할 수 있습니다. 그러나 고객 C6은 그러한 데이터를 프로토콜 외부에서 빠르고 안정적으로 제공하지 않는 한 그렇게 할 수 없습니다. Nathan Fritz은 앱이 쓰기 및 PUBLISH 이벤트를 발행하고 해당 이벤트에 대해 LISTEN으로 여러 복제본을 모니터링하여 최종 사용자에게 성공 보고서를 지연시키는 것을 관찰합니다. 가상 동기화의 확실한 약속이 필요한 경우 derecho을 앱에 통합하는 것을 고려해보십시오. redis의 프로덕션 릴리스는 문제 공간의 다른 부분을 대상으로합니다.