服务器主从制度并没有单一定式，更准确的说法是围绕主从复制延伸出的多种架构模式，按数据同步方式和故障处理逻辑区分，常见的服务器主从制度有异步复制、半同步复制、全同步复制、主备自动切换和双主互备几大类，实际生产环境中还常常混合使用。
服务器主从复制有哪几种模式
异步复制：默认方案，性能优先
异步复制是MySQL、Redis等中间件默认支持的主从方式，主库执行完写操作、写入binlog后立刻返回成功，不关心从库是否已经收到这些变更记录。
这种模式的好处非常直接：主库的性能损耗极小，吞吐量能跑满，坏处也摆在那里主库一旦发生断电、崩溃等极端情况，还没来得及传给从库的那部分数据就会丢，对于订单、支付这类强一致业务，单靠异步复制风险不小，多数场景下需要业务层做补偿或用其他机制兜底。
- 主库提交事务并写入binlog
- 从库通过网络拉取binlog并写入本地relay log
- 从库的SQL线程串行回放relay log
- 主库无需等待从库任何反馈
半同步复制：一致性和性能之间的折中
半同步复制解决了异步复制丢数据的痛点,主库在提交事务后，会等待至少一个从库确认已经收到binlog才告诉客户端“写成功了”。
这里有个容易被忽略的细节：半同步等待的是从库接收完binlog，不是从库回放完，也就是说从库可能还没执行完那条更新，但数据已经安全落地在从库的relay log里，只要从库不丢文件，主库宕机后把binlog补齐，数据就能找回来。
行业内对半同步的评价比较一致：性能损失大概在10%到20%之间（受网络延迟影响），换来的是主库单点故障后几乎不丢数据的保障，对于大部分互联网业务，这个代价完全值得。
全同步复制：强一致场景的必选项
全同步复制要求所有从库都确认完成操作,主库才返回成功，任何一台从库网络抖动，整个写入链路就会被拖慢，Percona XtraDB Cluster和MySQL Group Replication用的就是这种思路。
全同步复制最适合对数据一致性要求极高、并发写入量不大的场景，比如账务系统、库存扣减，运维圈有一个共识：不到万不得已，不要在生产环境上全同步，因为集群吞吐量会被最慢的那台从库卡死，节点越多，整体性能越差。
主从架构和集群的区别是什么
很多刚接触服务器架构的运维同事容易把这两个概念混在一起,主从架构和集群的区别是什么，用一句话讲透：主从解决的是读写不均和备份冗余，集群解决的是单点瓶颈和水平扩展。
定位差异
| 对比维度 | 主从架构 | 集群架构 |
|---|---|---|
| 写入方式 | 只有主库可写 | 多节点可写或分片写入 |
| 扩展方向 | 加从库扛读流量 | 加分片节点扛总流量 |
| 数据一致性 | 主从可能有短暂延迟 | 节点间强一致或最终一致 |
| 故障切换 | 提升从库为新的主库 | 集群自愈或重新选举 |
| 适用规模 | 中小规模读写分离 | 大规模高并发系统 |
真实场景中的组合拳
生产环境很少只用主从或只用集群,最常见的做法是分片集群的每个分片内部做主从复制，既享受集群的扩展能力，又享受主从的故障兜底，比如一个用户库按用户ID哈希分成8个分片，每个分片一主两从负责各自的读写流量。
常见误区：加了从库就算集群吗
不算,集群强调多节点协同处理同一份业务流量，而主从架构中真正干活的只有主库，从库几乎只充当备份和读流量的配角，判断标准很简单：杀掉一台从库，写服务是否完全不受影响，不受影响的就是标准主从，会影响的那就是集群里藏着状态同步的问题。
主从模式的切换方案怎么选
自建方案：省钱但考验运维功力
国内相当一部分中小团队还停留在自建主从的阶段,用Keepalived搭配虚拟IP做故障转移，主库挂了，Keepalived把虚拟IP漂移到备库，业务端无感知，只是IP指向变了。
这个方案便宜,两台云服务器加一个浮动IP就能跑起来，但维护成本并不低，需要定期手动检查主从延迟、relay log积压、半同步状态，一场中小规模故障演练就能把新手运维逼疯。
进阶一点的方案是使用MHA,它比Keepalived更懂MySQL，MHA能够自动识别主库故障、找到数据最完整的从库、补齐缺失的binlog再提升为主库，整个过程通常在30秒以内完成，但MHA的项目维护已经接近停滞，新版MySQL兼容性需要自己踩坑，适合从库数量不算多的场景。
云数据库托管：贵有贵的道理
如果不想折腾,云厂商的RDS是更省心的选择，简米云RDS MySQL的高可用版自带主备切换，备库不可见、不可查询，切换时间大约在30秒到1分钟之间，应用几乎感知不到。
价格维度上看,本地买两台自建服务器和云上购买一年高可用版本的费用差距并不算大，真正拉开差距的是人力运维成本，云数据库的主从健康检查、延迟告警、备份恢复全都后台托管，出了问题提工单即可。
业内专家指出,选自建还是上云，核心不只是一个价格问题，团队有没有专职DBA决定了最终体验，没有专职DBA，老老实实买云数据库高可用版本，省下的时间够多做很多事情了。
MySQL主从复制延迟怎么解决
延迟从哪里来
主从延迟几乎是MySQL高并发场景的必修课,常见原因归结为四类：
- 主库写入并发高,binlog产生的速度远超从库SQL线程回放的速度
- SQL线程单线程回放,无法充分利用从库的多核CPU
- 大事务长时间占用锁资源,回放时间被拉长
- 从库硬件配置低于主库,磁盘IO或CPU成为瓶颈
据统计,相当一部分生产环境的延迟问题出在单线程回放上，换个思路就能缓解大半。
实操优化路径
MySQL从5.6开始支持基于库的并行复制，5.7和8.0逐步演进到基于提交冲突检测的并行复制，实际调优步骤如下：
- 确认MySQL版本,至少5.7以上才能体验完整的并行复制能力
- 修改从库参数
slave_parallel_type为LOGICAL_CLOCK - 设置
slave_parallel_workers为4到8之间，具体看CPU核数 - 重启复制线程,观察
Seconds_Behind_Master指标变化
对于大事务导致的延迟,从业务端拆批处理更有效果，一个删除千万行数据的操作，拆成每批1000行的小事务，从库延迟能从几分钟降到几秒，改代码的成本比调参数高，但收益也是最明显的。
延迟监控命令要熟练
主从延迟监控的常用命令并不复杂：
SHOW SLAVE STATUS\G
关注Seconds_Behind_Master字段，数值为0表示实时同步，但这个值在某些场景下会失真，比如主库长时间没有写入时它可能显示为0，实际上从库早就在空转，更可靠的判断方式是对比主从库上同一张表的MAX(id)，或者直接看Master_Log_File和Relay_Master_Log_File是否一致。
关于服务器主从制度的常见问题
服务器主从制度有哪些最常用的实施方式？
最常用的是MySQL一主多从加半同步复制,搭配MHA或云数据库高可用版做自动切换，Redis领域则普遍采用主从复制加哨兵机制，哨兵负责监控主节点状态并在故障时推举新的主节点，还有一类是MongoDB副本集，它天然内置了主从选举机制，无需额外部署故障转移组件。
主从复制延迟会导致数据丢失吗？
不会直接导致数据丢失,但会导致数据不一致，主库写入成功但从库还没追上时，去从库读数据可能会读到旧值，如果主库在此时宕机且未开启半同步，那么从库缺失的那部分binlog数据确实会永久丢失，所以对数据零容忍的业务一定要开半同步。
自建主从时，主库和从库的硬件配置必须一致吗？
从库配置可以低于主库,但会显著增加延迟和复制失败的概率，从库不仅承担binlog回放任务，还要扛起读流量，最直接的配置建议是：如果预算有限，从库的CPU可以比主库差一档，但磁盘必须用同等级的SSD，磁盘IO是binlog回放的最大瓶颈，这块省不了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771526.html
