- 综合排序
- 最热优先
- 最新优先
- 来自专栏性能与架构
异地多活架构
物理距离必然导致数据不一致，这就得从“数据”特性来解决，如果是强一致性要求的数据（如存款余额），就无法做异地多活。 保证核心业务的异地多活 思维误区：要保证所有业务都能异地多活。 解决的方法就是：优先实现核心业务的异地多活。 4. 只保证绝大部分用户的异地多活 思维误区：要保证业务 100% 可用。 物理规律决定了异地多活无法保证100%的业务可用。 所以，无法做到实时转账的异地多活，需要通过特殊业务受到实现。
3.6K21发布于 2019-05-07 - 来自专栏devops_k8s
异地多活演变流程
1 简介 在软件开发领域，异地多活是分布式系统架构设计的一座高峰，很多人经常听到过他，但很少人理解其中的原理; 异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？ 这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。 认真读完这篇文章，我相信你会对异地多活架构，有更加深刻的理解。 12 异地多活理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。 3、提升高可用的核心是「冗余」，备份、主从副本、同城灾备、同城双活、两地三中心、异地双活，异地多活都是在做冗余4、同城灾备分为「冷备」和「热备」，冷备只备份数据，不提供服务，热备实时同步数据，并做好随时切换的准备 值得提醒你的是，只有真正理解了「异地双活」，才能彻底理解「异地多活」。
94522编辑于 2023-06-06 - 来自专栏运维之美
谈谈异地多活架构
应用场景 顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动 单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？ 因此，异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多活。 基于这个分析，跨城异地多活是架构设计复杂度最高的一种，接下来将介绍跨城异地多活架构设计的一些技巧 技巧1：保证核心业务的异地多活 “异地多活”是为了保证业务的高可用，但很多架构师在考虑这个“业务”时 综合上述的各种措施，最后“用户子系统”同步方式整体如下： 技巧4：只保证绝大部分用户的异地多活 前面在给出每个思维误区对应的解决方案时，留下了几个小尾巴：某些场景下我们无法保证100%的业务可用性，
3.7K42发布于 2019-06-02 - 来自专栏大数据技术架构
京东JDHBase异地多活实践
为了保障业务稳定不间断运行，我们构建了JDHBase集群的异地多活系统。主要介绍在我们在异地多活系统的实践。 JDHBase异地多活架构 JDHBase服务端与客户端交互主要包含三个组件：Client、JDHBase集群、Fox Manager。 我们对可靠性要求比较高的业务做了异地多活备份。 ? Active Cluster：正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster，同时保证数据不丢失，但是会有延迟。 实际生产中，我们根据两个建群间的Replication，构建了多集群间的Replication拓扑，使得集群互为主备。 mapr.com/blog/in-depth-look-hbase-architecture/ 3、hhttps://issues.apache.org/jira/browse/HBASE-20360 4、
1.6K42发布于 2020-03-11 - 来自专栏vivo互联网技术
同城双活与异地多活架构分析
服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。 例如，企业内部的 IT 系统、管理系统、博客站点等，如果无法承受异地多活带来的复杂度和成本，是可以不做异地多活的，而对于重要的业务例如核心金融、支付、交易等有必要做多活。 2、多活方案 常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案，不同多活方案技术要求、建设成本、运维成本都不一样，下面我们会逐步介绍这几种多活方案并给出每种方案的优点和缺点。 四、异地多活 异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。 这类数据部署情况像下面这样 6、方案评估 优势 容灾能力大幅度提高，服务异地多活，数据异地多活。 理论上系统服务可以水平扩展，异地多机房突破大幅度提升整体容量，理论上不会有性能担忧。
14.6K65发布于 2020-09-14 - 来自专栏程序猿DD
高可用解决方案：同城双活？异地双活？异地多活？怎么实现？
高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。 实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。 因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 根据异地双活的思路，我们可以画出异地多活的一种示意图。每个节点的出度和入度都是4，在这种情况下，任何节点下线都不会对业务有影响。 相对而言，饿了么的多活方案可能更适合大多数的企业。 本文只是通过画图的方式进行了简单的描述，其实异地多活是需要很多很强大的基础能力的。 假设买家在多个城市交汇的地方，比如，十字路口的四个位置分别是4个城市，那么如何处理才能让他拉到比较正常的数据？ 你们现在的业务模块中，哪些业务是可以做多活的，哪些无法做多活？ 所有的业务都要做多活吗？
4.9K22编辑于 2023-04-04 - 来自专栏CSDN搜“看，未来”
从 单体架构 到 异地多活
异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？ ---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地多活 系统可用性 让我们从最基础的开始往上垒。 ---- 异地双活 按照上面的思路，只要把 “同城双活” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗？ 因为是异地，两个机房之间的专线也将升级为 跨域专线 了。 例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。 == 双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。 == ---- 异地多活 理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
1.3K31编辑于 2022-05-06 - 来自专栏架构狂人
高可用架构之异地多活
应用场景 顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、 单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？ 因此，异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多活。 综合上述的各种措施，最后“用户子系统”同步方式整体如下： 技巧4：只保证绝大部分用户的异地多活 某些场景下我们无法保证100%的业务可用性，总是会有一定的损失。 设计跨城异地多活架构 我们讲完了异地多活设计的核心要点，下面我们谈一下如何设计跨城异地多活架构。
90821编辑于 2023-08-16 双活、异地多活架构怎么设计才不翻车？
2.2 多活架构分类 这张图清晰地展示了不同多活架构的特点。同城双活就像在同一个小区的不同栋楼里放设备，网络延迟很小；而异地多活则像在不同城市开分公司，距离远了但覆盖面更广。 3. 3.2 流量分配策略 在同城双活中，流量分配有几种策略： 主备模式：平时机房A承担所有流量，机房B待机。这种方式简单但有点浪费资源。 负载分担模式：两个机房按比例承担流量，比如7:3或6:4。 4. 异地多活架构设计 异地多活是多活架构的高级版本，复杂度会有质的提升。就像从骑自行车升级到开飞机，需要掌握更多技能。 4.1 整体架构设计 这个架构图展示了典型的异地三活架构。 避坑指南：常见问题及解决方案 多活架构虽然强大，但也有很多坑等着你。下面是一些常见的问题和解决方案，可以让你少走弯路。 7.1 数据一致性陷阱 问题：异地多活最大的坑就是数据一致性。 解决方案： 分阶段建设，先同城双活再异地多活 非核心业务可以使用冷备方案 充分利用云厂商的多活产品 8. 总结 多活架构设计是一个复杂的系统工程，需要考虑业务特点、技术实现、成本控制等多个方面。
78610编辑于 2025-11-06怎样做YashanDB支持异地多活部署
本文将深入探讨YashanDB异地多活部署的必要组件、架构设计和实施方案，确保数据安全和高可用性，从而提升系统的整体稳定性和业务连续性。 架构设计异地多活部署的架构设计必须可靠且高效，以确保在不同地理位置的数据中心之间能够实时处理数据，并保持一致性和可用性。1. 4. 网络优化与安全防护网络是确保异地多活部署在地理分布情况下性能和安全的重中之重，应采取以下方案：- 网络冗余：对重要的网络链路进行冗余配置，确保数据传输的稳定性。 数据一致性管理在异地多活部署中，数据一致性至关重要，YashanDB通过以下几种策略维护数据一致性：1. 本文提供的技术方案和实施步骤，旨在帮助工程师快速实现YashanDB的异地多活部署，并通过不断的监控和优化，最终实现高效的数据管理。实现有效的异地多活部署将为企业带来更大的竞争优势以及持续的业务保障。
20700编辑于 2025-07-24- 来自专栏云数据库技术
通过NineData实现MySQL异地多活场景
这就是我今天想聊的话题，单一机房内的高可用并不能算真正意义上的高可用，而「跨机房容灾」甚至「异地容灾」才算。异地容灾？异地多活？ 而异地多活则是异地容灾的一种升级方案，单元节点如果仅仅是作为灾备实例，那也太浪费了，不如和中心节点一起，同步处理业务流量，这样一来，不仅可以提高资源利用率，也能保证在任意一个节点失效时，其他节点可以平稳接管流量 上图就是一个异地多活的解决方案，其核心是在所有节点间建立实时的数据同步机制，以确保各个节点的数据一致性。 3.单击数据源 ID 进入数据源详情页面，单击展开，找到多活标记，配置多活标记名称。该步骤所有参与复制的数据源都需要执行，以防止发生数据循环复制。 至此，你的异地多活架构已经全部配置完成，所有节点都可以提供业务读写，得益于实时的数据同步机制，任何一个节点发生故障时，其他节点均能够无缝接管中心节点的流量，由于所有单元节点本身就在处理业务，因此无需担心单元节点能否胜任
8710编辑于 2026-04-14 - 来自专栏服务端技术杂谈
拆解交易系统--异地多活
或者基于高可用 / 高性能的需求，需要做异地多活。 异地多活容灾 很多巨型互联网产品发展到一定规模之后，其可用性往往造成很大经济损失，比如微信，支付宝这些用户规模巨大的产品，如果可用性有一点的降级，都会对大规模的用户影响，所以微信，支付宝这些产品早已做了异地多活 传统灾备方案 传统数据中心的灾备方案，一般是同城两个互备数据中心，异地建设一个灾备中心，三个数据中心平时只能一个提供在线服务，故障时将业务流量切到其他数据中心。
95920发布于 2020-01-16 - 来自专栏技术那些事
详解：淘宝高可用异地多活架构
p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里、腾讯、百度、网易、新浪等等都已经完成了异地多活的技术重构。 可以说，异地多活是互联网公司业务规模扩大后所必然要经历的阶段。那么如何解决高可用异地多活呢？ 有状态服务 后台服务可以划分为两类，有状态和无状态。 高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。 因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 图 4：异地多活的示意图 根据异地双活的思路，我们可以画出异地多活的一种示意图。 假设买家在多个城市交汇的地方，比如，十字路口的四个位置分别是 4 个城市，那么如何处理才能让他拉到比较正常的数据？ 你们现在的业务模块中，哪些业务是可以做多活的，哪些无法做多活？
3.2K12发布于 2020-11-30 - 来自专栏水滴与银弹
搞懂异地多活，看这篇就够了
在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。 异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？ 这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。 有幸，我曾经深度参与过一个中等互联网公司，建设异地多活系统的设计与实施过程。所以今天，我就来和你聊一聊异地多活背后的的实现原理。 11 异地多活 理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。 3、提升高可用的核心是「冗余」，备份、主从副本、同城灾备、同城双活、两地三中心、异地双活，异地多活都是在做冗余 4、同城灾备分为「冷备」和「热备」，冷备只备份数据，不提供服务，热备实时同步数据，并做好随时切换的准备 在写这篇文章时，我又仔细阅读了阿里、饿了么、微博等公司，关于异地多活架构设计的相关资料，如果你想更深入地学习异地多活架构，可以在我的公众号后台回复「异地多活」获取。
3.4K53发布于 2021-10-20 - 来自专栏码洞
分布式系统技术难题--异地多活
什么是异地多活？ 为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。 事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。 异地多活常见的解决方案有哪些？ 请求如何路由,如何实现会话保持对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,并且可以实现流量分发策略控制,根据IP会话保持。 在常见的解决方案中有多机房单集群,和多机房多集群部署两种.数据的同步可以分为，数据库,缓存,消息队列,session等。在多机房单集群中如何部署？ 4. 当某个机房不可用时,需将该机房的流量切入另一个机房,那么每个机房要预留多少存储与计算资源？ 一般经过测试评估,每个机房预留S级服务承载的流量资源。 5.
1.4K51发布于 2019-03-11 YashanDB支持的异地多活部署方案详解
如何设计和实现一个高效的异地多活部署方案，是当今数据库行业亟待解决的技术问题。本文将深入探讨YashanDB支持的异地多活部署方案的核心技术点、架构和优势，帮助读者更好地理解其实现机制和应用价值。 通过全局资源管理机制，支持在多实例环境中对数据变化的实时同步，从而实现了异地多活的目标。分布式部署分布式部署采用了多管理节点（MN）、协调节点（CN）和数据节点（DN）的组合架构。 数据一致性与同步机制在异地多活部署中，数据一致性至关重要。YashanDB通过多版本并发控制（MVCC）和事务日志机制来提供保障。 异地数据备份与恢复在异地多活部署中，数据备份与恢复机制也是不可避免的关键问题。YashanDB提供了备份与恢复工具，用户可以通过执行备份策略，将数据定期备份至异地域的存储中。 4. 安全性与权限管理安全性在异地多活部署中同样不可忽视，YashanDB采用基于角色的访问控制，结合SSL/TLS加密传输，确保数据在传输过程中的安全。
16600编辑于 2025-07-02- 来自专栏用户4352451的专栏
分布式系统架构-----异地多活架构
分布式系统架构-----异地多活架构 背景 最近公司在搞异地多活，特来写篇文章来学习和回顾一下。 异地多活看字面意思 ：不通的地方部署服务。 异地多活架构 1. 什么是异地多活架构？ 异地：不同的地理位置，多活：不同的地理位置的服务都能独立提供服务。 异地多活的目的也就是容灾，容灾的话我们也可以理解为某个地方服务出现了灾难性故障，而服务仍然能正常提供服务。 2. 像我们现在比较流行的夸奖电商的那些服务，岂不是都是这种跨国异地机构呢？ 应用 在背景也讲了我们公司也做了异地多活，多活的方式数据跨城异区。一个集群部署在广州南沙，一个部署在广东佛山。 延时问题 整个服务搭建好后总共耗时多了2-4ms 对于我们服务来讲还是可以接受的。
2.2K11编辑于 2022-05-05 - 来自专栏杨建荣的学习笔记
异地多活场景下的数据同步之道
作者：田守枝 来源：田守枝的技术博客订阅号（ID：tianshouzhi_blog） 在当今互联网行业，大多数人互联网从业者对"单元化"、"异地多活"这些词汇已经耳熟能详。 而数据同步是异地多活的基础，所有具备数据存储能力的组件如：数据库、缓存、MQ等，数据都可以进行同步，形成一个庞大而复杂的数据同步拓扑。 本文将先从概念上介绍单元化、异地多活、就近访问等基本概念。 不同单元的之间数据实时进行同步，相互备份对方的数据，才能做到真正意义上"异地多活”。 通常一个MySQL集群有一主多从构成。用户的数据都是写入主库Master，Master将数据写入到本地二进制日志binary log中。 4、如何解决唯一索引冲突 由于两边的库都存在数据插入，如果都使用了同一个唯一索引，那么在同步到对端时，将会产生唯一索引冲突。
2.8K31发布于 2019-09-25 - 来自专栏涤生的博客
异地多活场景下的数据同步之道
在当今互联网行业，大多数人互联网从业者对"单元化"、"异地多活"这些词汇已经耳熟能详。 而数据同步是异地多活的基础，所有具备数据存储能力的组件如：数据库、缓存、MQ等，数据都可以进行同步，形成一个庞大而复杂的数据同步拓扑。 本文将先从概念上介绍单元化、异地多活、就近访问等基本概念。 不同单元的之间数据实时进行同步，相互备份对方的数据，才能做到真正意义上"异地多活”。 通常一个mysql集群有一主多从构成。用户的数据都是写入主库Master，Master将数据写入到本地二进制日志binary log中。 4 开源组件介绍canal/otter 前面深入讲解了单元化场景下数据同步的基础知识。读者可能比较感兴趣的是，哪些开源组件在这些方面做的比较好。笔者建议的首选，是canal/otter组合。
4.5K41发布于 2019-05-10 - 来自专栏云技术支持团队
简述异地多活方案以及腾讯云实践
国家标准化管理委员会发布的容灾恢复RTO/RPO各等级对应关系如下:灾难恢复能力登记RTO RPO1 2天以上1至7天224小时以上1至7天312小时以上数小时至1天4数小时至2天数小时至1天5数分钟至两天 对于延时敏感的系统跨机房写会给用户带来不好的体验伪异地双活(应用层双活)这种架构与同城双活有很多相似之处，唯一的区别在于备数据中心的读写进行了分离，读操作直接读备数据中心，而写操作为了保证数据一致性，将打到主数据中心的数据库上 缺点: 业务系统需要能够接受一定的跨机房网络延；业务需要进行一定程度的改造, 将操作分位读操作和写操作两类；容灾距离依然受到非常大的限制(主要受限于跨机房写)异地双(多)活异地双活可以接受两个机房之间的距离大于 云上容灾架构分析案例一腾讯云上云基础架构云上基础容灾架构如下(数据层采取同城双活):图片主要产品:CDN 加速WAF应用防火墙+DDOS防护CLB 负载均衡(多可用区)多可用区云主机数据库(多可用区主备 +异地灾备)
4K94编辑于 2022-08-29
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号