京公网安备11010502063487号量 Redis 重启恢复耗时:10 万到 200 万个 key,RDB 约 0.48 s/百万 key,AOF(RDB base)相同,纯命令 AOF 约 0.87 s/百万 key(慢 82%);AOF 未重写、base 之后追加的增量每百万条命令多约 0.93 s(300 万条增量让 100 万 key 的重启从 0.47 s 变成 3.31 s)。
用 6 个本机节点建 3 主 3 从的 Redis Cluster:16384 个槽被均分为 5461 / 5462 / 5461;10 万个 key 落在三个主库上是 33359 / 33289 / 33352;每个槽平均 6.10 个 key(标准差 2.76);CLUSTER SLOTS 在从库健康状态为 loading 时不列出从库,online 后才列出。
验证 Redis Cluster 的槽位算法:自己实现 CRC16(XMODEM)算出的槽位与 CLUSTER KEYSLOT 在 20000 个随机 key 上全部一致;100 万个连续 key 落到 16384 个槽里标准差 6.74(比纯随机的 7.81 还均匀);并用伪造对端截获集群总线消息,证实每条消息带着一个 2048 字节(16384 位)的槽位位图,总长 2256 字节。
在本机 3 主 3 从集群上逐步复现 MOVED 与 ASK:把请求发给不负责的节点得到 MOVED(槽已永久归属别处,从库也一样,除非 READONLY);槽迁移中,源节点上不存在的 key 回 ASK(一次性),目标节点要先 ASKING 才处理,多 key 命令跨两端回 TRYAGAIN;SETSLOT NODE 完成迁移后源节点回 MOVED。
在 3 主集群上对比三种客户端重定向策略(各 30000 次 GET):不缓存槽位表 19987 次 MOVED、平均 47.7 µs;每次学一个槽 9507 次;启动时拉全表 0 次、28.8 µs;在线迁移 1000 个槽后,旧表客户端「只更新一个槽」触发 789 次 MOVED,「整表刷新」只要 1 次。
验证 Redis Cluster hash tag:{user1}:profile / :orders / :cart 都在槽 8106;12 种边界写法(空花括号、缺右括号、嵌套、多组)的槽位与「第一个 { 到第一个 }、内容非空才生效」的规则完全一致;10 万个 key 都用 {user1} 时全部落在一个主库(100000 / 0 / 0),拆成 64 个 tag 后分散为 28124 / 35937 / 35939。
实测 Redis Cluster 的 CROSSSLOT:多 key 命令(MSET、DEL、MGET、RENAME、SUNION、SINTERSTORE、MULTI/EXEC、EVAL)只要 key 不同槽就报错——哪怕两个 key 在同一个节点上;hash tag 让它们同槽后全部成功;Lua 里用 ARGV 绕过 KEYS 声明时,同节点不同槽的 key 竟然执行成功,只有非本节点的 key 才被拦。
从零观察 Redis Cluster 节点握手:CLUSTER MEET 后约 111 ms 双方互相认识(handshake/disconnected → handshake/connected → master/connected);第三个节点只 MEET 中间人,靠 gossip 在 1800 ms 内互相发现;分配槽位后 cluster_state 约 3.0 s 才变 ok;MEET 一个不存在的地址,handshake 记录 0.0 s 后被丢弃。
kill -9 一个 Redis Cluster 主库(cluster-node-timeout 3000 ms,3 次实验中位):kill 后 3652 ms 被标 PFAIL、4645 ms 升级 FAIL、5378 ms 从库升主;写入该主库槽位的客户端约 5.4 秒后恢复,其它槽几乎不受影响;1307 次已确认写入回读校验丢失 0 个。
三组真实故障转移看投票:3 主 3 从杀 1 个主库,从库发 5 条 auth-req,两个幸存主库各投 1 票(从库不投票)后升主;杀 2 个主库时只剩 1 个主库,被杀主库停在 PFAIL、没有任何从库发起选举,cluster_state 一直 fail;5 主 5 从杀 2 个仍有 3 个主库,两个从库都成功升主。
验证 Redis Cluster 的两种 epoch:新建 3 主 3 从集群 configEpoch 是 1/2/3、current_epoch 6;手工制造两个 configEpoch = 5 的冲突,握手后约 116 ms 内自动分开(一个变 6);冻结旧主库再解冻,新主库的 configEpoch 升到 7,旧主库解冻后仍接受了一次写入(3/3 次),随后 10–13 ms 变成从库,该次被 OK 的写入丢失。
本机真实起一主一从两个Redis实例，验证从库对过期key只在读取时屏蔽、不主动删除，只有主库发来DEL才会真实物理删除。