• 起因：实现减少甚至消除正常和非正常的停机对业务可用性造成的影响
  • 同城双活（提高容灾能力）
  • 异地只读业务和冷备（同城还是具有风险）
  • 只读业务在异地起用（冷备成本高）
  • 异地多活 （只读业务实际效果不理想）
    Paste_Image.png

异地多活做了什么？

  1. 多个跨地域的数据中心
  2. 每个数据中心都要承担用户的读和写流量
  3. 多点写。全国多个点
  4. 其他点对任意点的急救速度快

异地多活的挑战

  1. 距离带来的延时问题
  2. 用户写入的数据是否是在正确的地方，另外看到的是否是一致的

解决思路：没有必要把所有的业务都在全国部署---单元化，单元封闭

保障整个数据写入的正确性以及一致性

  1. 写入数据库之前都会做保护动作
  2. 有实时数据校验系统检查
  3. 保证在整个流量切换过程中数据是绝对一致的（阿里保密）
  4. 自研的数据同步产品（MySQL自己的主备是没有办法满足要求）

总结

  1. 把异地多活变成了阿里电商架构级的能力，意味着在整个架构中具备异地多活的能力
  2. 过程平滑，因为不能对业务产生太大影响，分了三年的时间去完成
  3. 2013年同城双活是为了避免异地双活未完善导致的页面延迟、打不开。
  4. 2014年较近城市单元化双活，访问被两个城市承担，下单由同个城市承担。

异地多活的优势

  1. 有极强的水平伸缩能力

  2. 异地多活怎么去应对故障


    Paste_Image.png

异地多活基本完成之后

  1. 希望整个异地多活的能力能逐渐演变成业界的
  2. 阿里把自己异地多活的能力分配给多个子产品同时启用
    参考
    明天再度这篇