第7章 高可用三部曲:复制哨兵集群 章节摘要:本章跟着一次主库宕机走。复制让数据有副本,哨兵让故障有裁判,集群让容量与写入有水平扩展。三部曲层层递进,每一步解决上一步遗留的问题,理解这条问题链比背架构图重要。 一条主线 凌晨两点,主库所在宿主机断电。第一步,从库还活着但没人指挥——引出哨兵;第二步,哨兵把从库提成主库,服务恢复,但单机写容量天花板还在——引出集群。复盘这条事故链,正好把复制的数据流、哨兵的裁决算法、集群的槽位路由串成一条主线:副本是资产,裁决是大脑,分片是天花板破解器。 沿途站点 7.1 主从复制:全量 RDB 同步加增量命令流,以及复制积压缓冲的作用。 7.2 Sentinel 哨兵:多哨兵互监、法定人数裁决、故障转移的完整流程。 7.
章节摘要:本章跟着一次主库宕机走。复制让数据有副本,哨兵让故障有裁判,集群让容量与写入有水平扩展。三部曲层层递进,每一步解决上一步遗留的问题,理解这条问题链比背架构图重要。
凌晨两点,主库所在宿主机断电。第一步,从库还活着但没人指挥——引出哨兵;第二步,哨兵把从库提成主库,服务恢复,但单机写容量天花板还在——引出集群。复盘这条事故链,正好把复制的数据流、哨兵的裁决算法、集群的槽位路由串成一条主线:副本是资产,裁决是大脑,分片是天花板破解器。
三个方案的演进关系:
两个必须点破的真相。其一,复制是异步的:主库不等从库确认就回客户端,故障切换瞬间可能丢最后一批写入——这解释了第 6 章末尾"Redis 到不了零丢失"的另一半原因。其二,集群的分片单位是槽不是键:16384 个槽把键空间切块分配到节点,多键操作必须同槽,这是所有"集群模式下命令报错"问题的总根源。
三个方案的能力与代价对照,选型时按行核对:
| 维度 | 主从复制 | 哨兵 | 集群 |
|---|---|---|---|
| 解决什么 | 数据有副本、读可扩展 | 主库故障自动切换 | 容量与写入水平扩展 |
| 自动故障转移 | 无 | 有,秒级 | 有,按槽位 |
| 写容量上限 | 单主 | 单主 | 随主节点数扩展 |
| 客户端复杂度 | 低 | 要支持哨兵寻址 | 要支持槽位路由 |
| 主要代价 | 异步复制丢窗口 | 切换期间写中断 | 多键操作受槽约束 |
演进不是"越靠右越好":读多写少的业务停在主从加哨兵就够,为不存在的写入瓶颈上集群,反而先撞上多键命令的槽约束。按需求停在第够用的那一档,是本章想教的真实判断力。
动手实验的主线是同一条事故链的逐步修复:先搭一主一从看复制、再断主库体会"没人指挥"的僵局、然后加哨兵看自动切换掐表计时、最后压测单主写上限引出集群。每一环都是上一环留下的具体痛点,架构选择不再是名词,而是一次次被问题逼出来的答案。
做实验时给自己留一份"切换时间线"记录:从故障注入到哨兵定性、从定性到新主可写、从新主可写到客户端全部恢复,三段各自耗时。这三个数字是给业务方谈可用性承诺的全部依据,也是对比"要不要上集群"时最硬的论据。
架构稳了,最后一章回到日常:监控哪些指标、怎么排查慢与阻塞、安全怎么加固,并用三个实战案例把全书的结构知识兑换成业务方案。