京公网安备11010502063487号本机实测 appendfsync 三种模式:单客户端同步 SET 的 p50 是 always 2.71 ms、everysec 31 µs、no 30 µs;管道吞吐 72k / 545k / 551k 条/秒;8 个客户端并发时 always 总吞吐放大 5.3 倍(多个写共用 fsync)。
在 200 万个 key 的实例上对比 no-appendfsync-on-rewrite:appendfsync always 且不跳过时,重写期间 SET p50 仍是 2.2 ms,重写要 6.6–8.6 s;设成 yes 后 p50 降到 30 µs、重写 1.1 s;everysec 下开关没有明显差别。
量 BGSAVE 的 fork 停顿:内存 17 MB / 159 MB / 498 MB 时 latest_fork_usec 分别是 1.3 / 6.5 / 21.1 ms(约 41 µs/MB),持续写入时 BGSAVE 期间 SET 的最大延迟几乎等于 fork 耗时,而 p50 与 p99 不受影响(约 30 µs / 50–70 µs)。
量 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 个。