0
Azure Redis Cache 팀 구성원의 대답 this에 따르면 Azure Redis Cache는 단일 끝점을 노출합니다. 해당 엔드 포인트는 자동으로 마스터 또는 슬레이브 노드로 라우팅됩니다 (장애 조치시 가정).Azure Redis Cache - 복제 된 인스턴스에 대해 올바르게 작업하는 방법
푸른 ... 노드가
그래서 클라이언트가 하나의 엔드 포인트를보고 언젠가 확인해야 마스터 또는 슬레이브
실제로 있는지 확인하기 위해 클라이언트 측에서 확인이 필요합니다 그 대답도한다고 어떤 질문을 제기하면 어떤 질문을 제기합니까?언제 Redis 클라이언트가 마스터 또는 슬레이브 노드와 통화하는지주의해야합니까? 장애 조치 중 불일치를 방지하는 것입니까? 아니면 여기에 다른 문제가 있습니까?
클라이언트가 마스터 또는 슬레이브 인스턴스에 연결되어 있는지 여부를 클라이언트가 어떻게 확인해야합니까?
info replication을 실행하고 있습니까? docs에서
즉, 클라이언트는 슬레이브 인스턴스에 연결되었음을 알 수 없습니다. 또한 승격되기 전에 슬레이브가 일부 쓰기를받지 못하면 페일 오버 중에/후에 일관성 문제가 발생할 수 있습니까? – Malt
역시 내 자신의 해석이지만 이것은 모두 여전히 적용됩니다 - https://redis.io/topics/replication은 마스터/슬레이브가 일관성을 얻기 위해 최선을 다할 것이라고 말하지만 보장되지는 않습니다 (물론 캐시입니다 결국 데이터베이스가 아님). Microsoft가 춤을 개선하기 위해 모자에서 여분의 토끼를 당길 경우에만 대답 할 수 있습니다. – evilSnobu
포트 6379/6380을 통한 Azure Redis 연결은 항상 클러스터되지 않은 캐시의 마스터 노드를 가리 킵니다. 장애 조치가 발생하면 장애 조치 후 새 마스터 노드에 대한 모든 연결이 자동으로 재 라우팅됩니다. 복제는 비동기식이므로 슬레이브에 아직 복제되지 않은 모든 쓰기가 손실됩니다. 이는 표준 Redis 동작이며 Azure Redis에만 국한되지 않습니다. 클러스터 된 캐시 인 경우 상황이 약간 다르게 작동합니다. 클러스터 구성은 초기 연결을 통해 다운로드되고 클라이언트는 클러스터의 모든 노드에 직접 연결됩니다. – JonCole