Redis 클러스터는 강력한 일관성을 보장하지 않습니다. 일부 특수한 시나리오에서는 클라이언트가 쓰기 확인을 받더라도 여전히 데이터가 손실될 수 있습니다.
시나리오 1: 비동기 복제
- 클라이언트가 마스터 B에 쓰기
- 마스터 B가 OK라고 응답함
- 마스터 B가 슬레이브 B1 B2 B3
B와 동기화 B1 B2 B3의 확인을 기다리지 않고 클라이언트에 응답 슬레이브 동기화가 완료되기 전에 마스터가 다운되면 슬레이브 중 하나가 마스터로 선택되고 클라이언트가 이전에 작성한 데이터는 손실됩니다.
wait 명령은 이 시나리오에서 데이터 보안을 강화할 수 있습니다. wait 命令可以增强这种场景的数据安全性。
wait 会阻塞当前 client 直到之前的写操作被指定数量的 slave 同步成功。
wait 可以提高数据的安全性，但并不保证强一致性。
因为即使使用了这种同步复制方式，也存在特殊情况：一个没有完成同步的 slave 被选举为了 master。
场景2：网络分区
6个节点 A, B, C, A1, B1, C1，3个master，3个slave，还有一个client，Z1。
发生网络分区之后，形成了2个区，A, C, A1, B1, C1 和 B Z1。
这时 Z1 还是可以向 B 写入的，如果短时间内分区就恢复了，那就没问题，整个集群继续正常工作，但如果时间一长，B1 就会成为所在分区的 master，Z1 写入 B 的数据就丢了。
maximum window（最大时间窗口） 可以减少数据损失，可以控制 Z1 向 B 写入的总数：
过去一定时间后，分区的多数边就会进行选举，slave 成为 master，这时分区少数边的 master 就会拒绝接收写请求。
这个时间量是非常重要的，称为节点过期时间。
一个 master 在达到过期时间后，就被认为是故障的，进入 error 状态，停止接收写请求，可以被 slave 取代。
小结
Redis Cluster 不保证强一致性，存在丢失数据的场景：
- 异步复制
在 master 写成功，但 slave 同步完成之前，master 宕机了，slave 变为 master，数据丢失。
wait
wait는 이전 쓰기 작업이 지정된 슬레이브 수에 의해 성공적으로 동기화될 때까지 현재 클라이언트를 차단합니다. -
wait는 데이터 보안을 향상할 수 있지만 강력한 일관성을 보장하지는 않습니다.
A, B, C, A1, B1, C1, 3개의 마스터, 3개의 슬레이브 및 1개의 클라이언트, Z1 code> . 
🎜🎜🎜현재 Z1은 여전히 질문할 수 있습니다. B 서면, 단기간 내인 경우 파티션이 복원되면 문제가 없습니다. 전체 클러스터는 계속 정상적으로 작동합니다. 그러나 시간이 지나면 B1이 해당 파티션의 마스터가 되고 Z1이 쓴 데이터는 다음과 같습니다. B는 길을 잃을 것이다. 🎜🎜