Redis Cluster到底会不会丢数据？

redis cluster 不保证强一致性，在一些特殊场景，客户端即使收到了写入确认，还是可能丢数据的。

场景1：异步复制

• client 写入 master B
• master B 回复 OK
• master B 同步至 sl*e B1 B2 B3

B 没有等待 B1 B2 B3 的确认就回复了 client，如果在 sl*e 同步完成之前，master 宕机了，其中一个 sl*e 会被选为 master，这时之前 client 写入的数据就丢了。

wait 命令可以增强这种场景的数据安全性。

wait 会阻塞当前 client 直到之前的写操作被指定数量的 sl*e 同步成功。

wait 可以提高数据的安全性，但并不保证强一致性。

因为即使使用了这种同步复制方式，也存在特殊情况：一个没有完成同步的 sl*e 被选举为了 master。

场景2：网络分区

6个节点 A, B, C, A1, B1, C1，3个master，3个sl*e，还有一个client，Z1。

发生网络分区之后，形成了2个区，A, C, A1, B1, C1 和 B Z1。

这时 Z1 还是可以向 B 写入的，如果短时间内分区就恢复了，那就没问题，整个集群继续正常工作，但如果时间一长，B1 就会成为所在分区的 master，Z1 写入 B 的数据就丢了。

Quicktools Background Remover

Picsart推出的图片背景移除工具

31 查看详情

maximum window（最大时间窗口） 可以减少数据损失，可以控制 Z1 向 B 写入的总数：

过去一定时间后，分区的多数边就会进行选举，sl*e 成为 master，这时分区少数边的 master 就会拒绝接收写请求。

这个时间量是非常重要的，称为节点过期时间。

一个 master 在达到过期时间后，就被认为是故障的，进入 error 状态，停止接收写请求，可以被 sl*e 取代。

小结

Redis Cluster 不保证强一致性，存在丢失数据的场景：

• 异步复制

在 master 写成功，但 sl*e 同步完成之前，master 宕机了，sl*e 变为 master，数据丢失。

wait 命令可以给为同步复制，但也无法完全保证数据不丢，而且影响性能。

• 网络分区

分区后一个 master 继续接收写请求，分区恢复后这个 master 可能会变为 sl*e，那么之前写入的数据就丢了。

可以设置节点过期时间，减少 master 在分区期间接收的写入数量，降低数据丢失的损失。

推荐学习：《redis教程》

以上就是Redis Cluster到底会不会丢数据？的详细内容，更多请关注其它相关文章！