这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
数据同步
场景
多地域部署后，遇到新问题。
问题分析
数据流向：
北京（主库） → 上海（从库）
│
└→ 广州（从库）
问题：
1. 主从延迟：几秒到几分钟
2. 网络不稳定：偶发中断
3. 数据一致性：用户期望实时解决方案
1. 优化主从复制
设计流程
1. 优化主从复制：运行配置
- 步骤 1：声明主从、集群或故障切换关系
- 步骤 2：配置超时、重试和阈值
- 步骤 3：配置日志、监控和告警输出
关注点：路由准确性、跨区延迟、一致性和故障切换。
2. 应用层路由优化
设计流程
2. 应用层路由优化
- 步骤 1：更新跨地域路由、复制进度或主备状态
- 步骤 2：准备地域拓扑、健康状态、路由规则和复制进度
- 步骤 3：获取共享依赖连接并检查可用性
- 步骤 4：同步跨节点数据并检查延迟
关注点：路由准确性、跨区延迟、一致性和故障切换。
3. 最终一致性方案
设计流程
3. 最终一致性方案
- 步骤 1：同步跨节点数据并检查延迟
- 步骤 2：准备地域拓扑、健康状态、路由规则和复制进度
- 步骤 3：同步跨节点数据并检查延迟
- 步骤 4：校验延迟、一致性和故障切换结果
关注点：路由准确性、跨区延迟、一致性和故障切换。
监控和告警
主从同步监控
设计流程
主从同步监控
- 步骤 1：检查健康状态并触发告警
- 步骤 2：采集健康状态并触发告警
- 步骤 3：确认用户来源、目标地域和可用区健康状态
- 步骤 4：根据延迟、健康状态和一致性要求调整地域策略
关注点：路由准确性、跨区延迟、一致性和故障切换。
上线前多想一步
- 谁负责写？ 如果北京和上海都能改同一份数据，就要提前说清楚谁说了算。
- 数据多久同步过去？ 用户能不能接受几秒延迟，不能接受的操作就不要读从库。
- 一个地域挂了怎么办？ 用户请求切到哪里，切过去后还能不能看到刚刚提交的数据。
练习
练习 1
用户在北京提交了一个配置修改，随后被路由到上海地域，结果看到的还是旧配置。这个问题应该靠“强制所有读都回北京”解决吗？
参考答案 (3 个标签)
多地域 数据同步 一致性
不一定。所有读都回北京可以保证更强的一致性，但会牺牲上海用户的延迟，也会让北京重新成为瓶颈。
更合理的做法是按业务重要性分层：
- 强一致操作：刚提交后的配置详情、支付状态、账号安全信息，可以短时间读主库或读写同地域。
- 最终一致操作：报表、列表、非关键展示，可以接受几秒延迟，继续读本地从库。
- 给用户明确反馈：提交后显示“配置已提交，正在同步”，不要让用户误以为操作失败。
- 监控复制延迟：如果延迟超过阈值，临时把关键读切回主地域。
系统设计不是一味追求强一致，而是判断哪些数据必须立刻一致，哪些数据可以慢一点。