京公网安备11010502063487号选 Sentinel 还是 Cluster,很多文章给的是「数据小用 Sentinel,数据大用 Cluster」这类经验话。这篇不新增实验,把前面各篇已经实测的数字并排放在一起,看两者在故障转移、扩容、多 key 命令和数据安全上到底差在哪里。数字来自第 70–95 篇。
下面所有数字都引用自本系列前面的实验(条件:本机、回环网络、3000 ms 超时),两个系统的对比条件并不完全一致:Cluster 用的是 3 主 3 从、kill -9 一个主库,Sentinel 用的是 1 主 2 从 + 3 个 sentinel、kill -9 主库。
Cluster(第 75 篇):PFAIL → FAIL → 从库升主,写入恢复中位约 5.4 s。Sentinel(第 89 篇):s_down → o_down → 选领导者 → 提升,写入恢复约 4.3 s。量级相同,都由检测超时主导。差别在语义:Cluster 每个分片独立切换,一个分片的故障只影响它负责的槽;Sentinel 的主库故障影响全部数据。
Sentinel 只有一个主库,数据和写入都受单机限制。Cluster 加一个空主库后 rebalance,4096 个槽搬迁用时 3.0 s,期间吞吐几乎不变(第 79 篇)。
Sentinel 下的 Redis 是普通的单机 Redis:任意多 key 命令、事务、Lua 都可以。Cluster 要求同一命令里的 key 在同一个槽(第 73 篇,连「同节点不同槽」都不行),需要 hash tag(第 72 篇),而 tag 会造成热点。
两者都是异步复制。Sentinel 分区实验里被确认的写入丢了 1226/1540(第 91 篇);Cluster 里被隔离的旧主库在 node-timeout 之内仍接受写入,之后拒绝(第 83 篇)。min-replicas-to-write 对两者都适用(第 94、95 篇)。