半同步复制对网络延迟极其敏感，延迟每增加一毫秒，事务提交就可能多等一毫秒，主库必须等从库确认收到binlog才返回提交成功，这个“等”字，就是半同步复制在网络不佳时最让人头疼的地方。
半同步复制网络延迟多少正常？先看延迟从哪来
半同步复制的核心逻辑，一句话就能说清楚：主库提交事务时，先把binlog发给从库，从库写入relay log并返回ACK，主库收到ACK后才向客户端返回成功，这个机制保证至少一个从库有数据，但代价是主库的提交延迟直接取决于网络往返时间（RTT）。
正常情况下，同机房内网延迟在5ms以内，跨机柜约1-2ms，同城跨机房大约3-10ms，跨地域则可能飙到30-100ms甚至更高，行业共识认为，半同步复制环境下，主库事务提交的额外延迟约等于一个完整RTT,多数情况下不会超过两倍。
判断延迟是否正常的标准很简单：用SHOW STATUS LIKE 'Rpl_semi_sync%'查看状态，重点看Rpl_semi_sync_master_tx_wait_time（事务等待ACK的总耗时）和Rpl_semi_sync_master_tx_avg_wait_time（平均等待耗时），如果平均等待时间接近你的网络RTT，说明机制运转正常；如果远超RTT，那就要检查从库的磁盘写入速度、relay log刷盘策略或者主库的负载情况了。
网络延迟对半同步复制性能的影响
延迟带来的影响，远不止“慢一点”这么简单，它直接改变主库的吞吐量和并发行为。
延迟如何拖慢事务提交
- 串行等待：每个事务提交都要等ACK，在单线程提交场景下，延迟直接变成额外开销，假设RTT是30ms，原本1ms就能提交的事务,现在需要31ms。
- 并发堆积：高并发场景下，多个事务同时等待ACK，连接池和线程资源被占满，新事务排队等待,整体吞吐量断崖式下跌。
- 锁持有时间变长：事务在等待ACK时，行锁和间隙锁不会释放，其他事务被迫等待,连锁反应放大延迟。
半同步复制和异步复制区别：延迟如何影响选择
很多团队纠结半同步和异步怎么选，本质上是在数据安全和性能之间做权衡。
| 对比维度 | 半同步复制 | 异步复制 |
|---|---|---|
| 数据丢失风险 | 主库崩溃时最多丢一个事务 | 主库崩溃时可能丢大量事务 |
| 提交延迟 | 增加约一个RTT | 几乎无额外延迟 |
| 吞吐量 | 受网络RTT制约 | 不受从库影响 |
| 适用场景 | 金融交易、订单系统 | 日志、报表、缓存等弱一致场景 |
延迟超过50ms时，半同步复制的性能劣势会非常明显，业内专家指出，当RTT超过主库事务执行时间的数倍时，半同步复制带来的安全收益可能不足以抵消性能损失，此时应考虑调整策略，比如跨地域灾备场景，主备机房相距上千公里，RTT可能达到40-60ms，如果业务对写入延迟敏感,纯半同步复制会让主库性能惨不忍睹。
半同步复制延迟高怎么解决：参数调优实操
如果延迟确实高，且业务不能接受，优先从参数层面找突破口，MySQL的半同步复制插件提供两个关键参数，调好它们,大部分问题能解决一半。
rpl_semi_sync_master_timeout超时设置的度
这个参数控制主库等待ACK的最长时间，默认值是10000ms（10秒），超过这个时间，主库自动降级为异步复制,不再等待从库确认。
- 设置太短（比如100ms），网络稍微抖动就频繁降级为异步,失去半同步保护意义。
- 设置太长（比如10秒），网络故障时主库事务阻塞时间过长,业务直接卡死。
推荐设置为1000ms到3000ms,具体操作：
SET GLOBAL rpl_semi_sync_master_timeout = 1000;
持久化到配置文件：
[mysqld] rpl_semi_sync_master_timeout = 1000
这样配置的好处是：正常网络波动下，等待1秒内大概率能收到ACK；若从库彻底挂了，1秒后自动降级为异步，主库恢复可用,兼顾安全性和可用性。
wait_point参数怎么选
MySQL 5.7及以上版本提供rpl_semi_sync_master_wait_point参数,有两个值：
- AFTER_SYNC（默认）：主库把binlog写入磁盘后、提交事务前，等待从库ACK，从库确认后，主库才提交并返回成功，这个模式保证主库和从库数据一致,但延迟更高。
- AFTER_COMMIT：主库提交事务后再等ACK，从库没收到ACK时，主库已提交，但客户端可能收到失败（因为主库还没返回成功）,会导致数据不一致的假象。
追求数据一致性就选AFTER_SYNC，这也是MySQL官方推荐的默认值，如果业务能接受极端情况下的数据差异，选AFTER_COMMIT能稍微降低延迟,但不建议在核心业务上使用。
从库侧优化
从库收到binlog后，写入relay log的速度也会影响ACK返回时间，检查从库的sync_relay_log参数：
SET GLOBAL sync_relay_log = 1;
每次写入relay log都刷盘，虽然增加从库磁盘IO，但能加快ACK返回，从库磁盘用SSD，RAID卡开启写缓存，都能有效降低relay log写入耗时。
网络层面的优化方向
参数调完还不够,网络本身的质量决定半同步复制的上限。
- 降低RTT：同机房部署是首选，机房间用专线而不是公网，跨地域场景，优先选择云厂商提供的内部高速通道,而不是普通公网IP。
- 保证带宽和稳定性：半同步复制对带宽要求不算高，但对丢包和抖动非常敏感，TCP重传一次，RTT直接翻倍，ACK等待时间跟着上涨，用
ping -f和mtr工具持续监测主从之间的网络质量，丢包率长期高于0.1%就需要排查链路问题。 - 启用TCP_NODELAY：MySQL默认启用，但有些代理或中间件会关闭它，禁用Nagle算法能避免小包延迟,减少ACK返回的等待时间。
- 多从库并行：如果有多个从库，半同步复制默认等所有从库返回ACK，可以设置
rpl_semi_sync_master_wait_for_slave_count参数，比如配置为1，表示只要任意一个从库返回ACK即可，延迟不随从库数量线性增长,操作方式：
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1;
跨地域部署的取舍方案
当主从必须跨地域部署时，硬扛半同步复制不太现实，业界常见的做法是分层妥协。
- 主库同城双机房
：主库和半同步从库放在同城两个机房，RTT控制在5ms以内，灾备从库放在异地，用异步复制同步，这样主库延迟可控,异地数据作为兜底。
- 半同步降级为异步的自动切换：利用
rpl_semi_sync_master_timeout的自动降级机制，网络抖动时自动退化为异步，恢复后自动回到半同步，关键是监控降级事件，持续降级说明网络长期不达标,需要调整部署架构。 - 业务层补偿：主库写入用半同步保证关键数据不丢，非关键数据走异步复制，比如订单表用半同步，日志表用异步,在业务代码里区分对待。
半同步复制主从网络延迟常见问题
问：半同步复制下，主库每个事务都会增加一个RTT的延迟吗？
是的，半同步复制的机制决定了主库必须等待从库ACK，这个等待时间至少是一个RTT，但要注意，AFTER_SYNC模式下，等待发生在事务提交前，所以延迟是完整叠加在事务执行时间上的，如果RTT是2ms，事务原本耗时5ms，现在变成7ms；如果RTT是50ms，事务就变成55ms,这也是为什么半同步复制不适合跨地域部署。
问：半同步复制降级为异步后，还能自动恢复吗？
能，当rpl_semi_sync_master_timeout超时触发降级后，MySQL会持续尝试重新建立半同步复制，从库恢复并返回ACK后，主库自动重新进入半同步模式，可以通过SHOW STATUS LIKE 'Rpl_semi_sync_master_status'查看当前状态，ON表示半同步生效，OFF表示已降级，建议监控这个状态变化，如果频繁在ON和OFF之间切换，说明网络质量不稳定，需要优先解决网络问题,而不是依赖自动恢复机制。
问：半同步复制对从库硬件有什么要求？
从库的relay log写入速度直接影响ACK返回时间，如果从库磁盘是机械硬盘，写入延迟可能达到5-10ms，比网络延迟还高，推荐从库使用SSD，并且把innodb_flush_log_at_trx_commit和sync_relay_log设为1，保证每次写入都刷盘，避免从库崩溃时relay log丢失，从库的CPU和内存不用和主库完全对等，但磁盘IO能力必须足够强,否则半同步复制会把从库的短板放大到主库的提交路径上。