主从复制、延迟与读写分离

复制副本可以分担读请求并提供故障恢复候选，但不会凭空增加写能力，也不保证刚写完就能从副本读到。读写分离首先是一致性产品设计问题。

Open Table of contents

复制链路

源库提交 → Binlog → 网络传输 → 副本接收日志 → 回放变更 → 副本可见

任何环节积压都会产生复制延迟。延迟指标不能只看秒数，还要看待回放事务量、字节量、最旧未应用位置和业务允许窗口。一个大事务可能在很长时间内看似“只差一件事”。

用户创建订单后立即刷新，若查询被路由到尚未回放的副本，就会看到“订单消失”。这叫缺少 read-your-writes（读己之写）保证。

常用策略包括：写后短时间粘到主库；关键流程始终读主库；携带提交位点并等待副本追上；只把可容忍陈旧的列表、报表路由到副本。没有一种策略对所有接口最好，必须为读模型标注最大陈旧时间。

切换前要判断候选副本是否追平、是否可能丢已确认事务；切换中要阻止双主写入；切换后要重建复制拓扑、回收旧主写权限并校验数据。网络分区时同时有两个可写主库会产生脑裂。

应用侧还要处理失效连接、事务重试和连接池 DNS/地址缓存。演练应包含真实写流量、延迟副本和回切，而不仅是关闭空闲主库。