异地多活:构建高可用服务和容灾能力的关键

在数字化和互联网技术不断发展的今天,企业和系统的可用性及对灾难的应对能力显得尤为关键。异地多活技术,作为分布式系统架构设计的一座高峰,提供了有效的解决方案。

系统可用性的重要性

要理解异地多活,首先需要明确高可用系统的含义。一个高可用系统遵循三大原则:高性能、高可用和易扩展。其中,高可用性是通过两个关键指标衡量的:平均故障间隔时间(MTBF)和故障恢复时间(MTTR)。只有当系统能够在故障后快速恢复,才能真正称之为高可用。

  • 平均故障间隔 MTBF(Mean Time Between Failure):表示两次故障的间隔时间,也就是系统「正常运行」的平均时间,这个时间越长,说明系统稳定性越高
  • 故障恢复时间 MTTR(Mean Time To Repair):表示系统发生故障后「恢复的时间」,这个值越小,故障对用户的影响越小

这个公式得出的结果是一个「比例」,通常我们会用「N 个 9」来描述一个系统的可用性。

系统可用性 年故障时间 日故障时间
90%(1个9) 36.5天 2.4小时
99%(2个9) 3.65天 14分钟
99.9%(3个9) 8小时 86秒
99.99%(4个9) 52分钟 8.6秒
99.999%(5个9) 5分钟 0.86秒
99.9999%(6个9) 32秒 86毫秒

通常情况下,系统发生故障是很难避免的,有诸如机器故障、机房故障、自然灾害等。系统可用性的关键点则在于系统的最快恢复速度

蚂蚁金服的实践案例
蚂蚁金服在异地多活领域的实践提供了深刻的行业洞察。2015年,支付宝因市政施工导致数据中心光缆被挖断,影响了部分用户服务。尽管单元化架构容灾已基本成型,但突发事件仍暴露出实际问题。527事件成为蚂蚁金服技术人的警醒,推动技术不断革新。

到2018年,蚂蚁金服在云栖大会上演示了“三地五中心金融级高可用方案”。在模拟转账系统的演示中,杭州的两个数据中心网络被断开,仅用26秒完成容灾切换,所有受影响用户服务恢复正常,展示了强大的系统容灾能力。

异地多活

异地多活的目的

异地多活的主要目的是解决系统的容灾问题,包括机器故障、机房故障、自然灾害等。通过在不同城市建立独立的数据中心,异地多活确保了即使在极端情况下,系统也能持续提供服务。

从单机到异地多活的演进

  • 单机架构:在业务起步阶段,单机架构通常能满足需求。
  • 主从副本:单机架构存在数据丢失的风险,因此衍变为需要通过数据备份和主从副本来提高数据的安全性。通过在不同机器上部署数据库的主从副本,实现实时数据同步,从而提高了系统的抗故障能力和读性能。
  • 同城灾备:为了应对机房级别的故障,引入了同城灾备的概念,包括冷备和热备。冷备只做数据备份,而热备则实时同步数据并准备随时接管业务。
  • 同城双活:在两个同城机房中都部署应用和存储,实现真正意义上的双活架构。这种架构不仅提高了系统的可用性,还提升了整体性能。
  • 两地三中心:为了进一步提高系统的可用性,尤其是在面对城市级别灾难时,采用两地三中心的架构,在不同城市部署备份中心。
  • 异地双活和多活:真正的异地双活要求在不同城市的机房中部署应用,实现存储的双向同步。异地多活是在此基础上,扩展到多个地理位置,提供更高的系统可用性和更好的灾难恢复能力。

异地多活的实施和挑战

  • 路由层的设计:为了有效实施异地多活,需要在最上层设计路由规则,确保用户请求被正确地分发到各个机房。
  • 存储层的同步:在异地多活架构中,关键在于实现存储层的数据双向同步。这通常需要借助强大的同步中间件来实现。
  • 数据冲突的处理:处理数据冲突是异地多活中的一个重要问题。这通常涉及到复杂的合并逻辑或从源头避免数据冲突的策略。
  • 业务单元化:实现异地多活还需要对业务进行单元化划分,确保业务操作在一个机房内闭环完成,避免跨机房访问。

问题及解决方案

  • 数据回环问题:通过给同步log打标签,例如标注机房信息,避免同步回原始机房。
  • 数据冲突问题:使用全局时间戳或版本号解决冲突,或在业务层面通过状态机保证数据一致性。
  • 数据一致性校验问题:采用双写数据校验、冲突数据校验和风险数据校验。

异地多活的核心要素

  • 业务分片: 为了有效地实施异地多活,我们需要采用业务分片的策略。这意味着,根据业务需求和用户行为,将不同的业务模块或用户群体分配到不同的地理位置。例如,根据用户地理位置将他们的数据存储在最近的数据中心。
  • 数据同步策略: 数据同步是实现异地多活架构的核心。这涉及选择合适的同步机制,例如异步复制或实时复制,以及处理数据冲突和确保数据一致性的策略。
  • 容灾与故障转移: 异地多活架构的另一个关键要素是高效的容灾和故障转移机制。这包括自动故障检测、快速故障响应和数据恢复能力。
  • 性能和延迟的优化: 在跨地理位置部署的环境中,优化网络性能和减少延迟至关重要。这可能涉及选择最优的网络路由、使用CDN服务以及优化应用程序以减少对远程资源的依赖。
  • 运维管理: 高效的运维管理对于维持异地多活架构至关重要。这包括监控系统健康状况、性能优化、故障诊断和及时更新。

异地多活的设计原则

  • 选取分区维度:选择合适的数据维度进行数据切片,实现业务分布式部署。
  • 确定改造范围:先确定最小改造集,逐步扩展到相关业务。
  • 单元封闭:减少跨数据中心调用,提高用户体验和服务稳定性。
  • 单点写入:对于无法接受最终一致性的数据,采用单点写入策略。

异地多活不适用场景

  • 实时异地多活:由于物理限制导致的数据延迟,不适用于实时性要求极高的服务。
  • 所有用户异地多活:部分用户数据可能因延迟而无法及时同步。
  • 所有业务异地多活:考虑到成本和运维复杂性,需要根据业务需求决定。
  • 通用异地多活:根据业务类型差异,可能需要定制化的多活方案。

结论

通过从单机架构逐步演进到异地多活,我们不仅可以提高系统的可用性和灾难恢复能力,还能应对更大规模的业务需求。虽然实现异地多活的成本和技术难度较高,但对于确保关键业务的连续性和数据的安全性来说,这是一种值得投资的架构策略。