- 起因：实现减少甚至消除正常和非正常的停机对业务可用性造成的影响
- 同城双活（提高容灾能力）
- 异地只读业务和冷备（同城还是具有风险）
- 只读业务在异地起用（冷备成本高）
-
异地多活 （只读业务实际效果不理想）
Paste_Image.png
异地多活做了什么？
- 多个跨地域的数据中心
- 每个数据中心都要承担用户的读和写流量
- 多点写。全国多个点
- 其他点对任意点的急救速度快
异地多活的挑战
- 距离带来的延时问题
- 用户写入的数据是否是在正确的地方，另外看到的是否是一致的
解决思路：没有必要把所有的业务都在全国部署---单元化，单元封闭
保障整个数据写入的正确性以及一致性
- 写入数据库之前都会做保护动作
- 有实时数据校验系统检查
- 保证在整个流量切换过程中数据是绝对一致的（阿里保密）
- 自研的数据同步产品（MySQL自己的主备是没有办法满足要求）
总结
- 把异地多活变成了阿里电商架构级的能力，意味着在整个架构中具备异地多活的能力
- 过程平滑，因为不能对业务产生太大影响，分了三年的时间去完成
- 2013年同城双活是为了避免异地双活未完善导致的页面延迟、打不开。
- 2014年较近城市单元化双活，访问被两个城市承担，下单由同个城市承担。
异地多活的优势
- 有极强的水平伸缩能力
-
异地多活怎么去应对故障
Paste_Image.png
