- 综合排序
- 最热优先
- 最新优先
- 来自专栏性能与架构
异地多活架构
跨城异地多活设计技巧 1. 保证核心业务的异地多活 思维误区：要保证所有业务都能异地多活。 如果想要保证注册业务多活，可能会有问题，例如，A中心注册了用户，数据还未同步到B中心时A宕了，为了支持多活，需要可以让用户到B中心重新注册，但一个手机号只能注册一个账号，A恢复后就有冲突了。 解决的方法就是：优先实现核心业务的异地多活。 只保证绝大部分用户的异地多活 思维误区：要保证业务 100% 可用。 物理规律决定了异地多活无法保证100%的业务可用。 所以，无法做到实时转账的异地多活，需要通过特殊业务受到实现。
3.7K21发布于 2019-05-07 - 来自专栏vivo互联网技术
同城双活与异地多活架构分析
服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。 1、多活场景 多活架构的关键点就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是指实时提供服务的意思。 因此，多活虽然功能很强大，但也不是每个业务都要上多活。 2、多活方案 常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案，不同多活方案技术要求、建设成本、运维成本都不一样，下面我们会逐步介绍这几种多活方案并给出每种方案的优点和缺点。 四、异地多活 异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。
14.7K65发布于 2020-09-14 - 来自专栏devops_k8s
异地多活演变流程
1 简介 在软件开发领域，异地多活是分布式系统架构设计的一座高峰，很多人经常听到过他，但很少人理解其中的原理; 异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？ 这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。 认真读完这篇文章，我相信你会对异地多活架构，有更加深刻的理解。 这篇文章要讲的「异地多活」架构，就是为了解决这个问题，而提出的高效解决方案。下面，我会从一个最简单的系统出发，带你一步步演化出一个支持「异地多活」的系统架构。 12 异地多活理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。 值得提醒你的是，只有真正理解了「异地双活」，才能彻底理解「异地多活」。
1K22编辑于 2023-06-06 - 来自专栏运维之美
谈谈异地多活架构
应用场景 顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动 单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？ 因此，异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多活。 因此，跨国异地的“多活”，和跨城异地的“多活”，实际的含义并不完全一致。 基于这个分析，跨城异地多活是架构设计复杂度最高的一种，接下来将介绍跨城异地多活架构设计的一些技巧 技巧1：保证核心业务的异地多活 “异地多活”是为了保证业务的高可用，但很多架构师在考虑这个“业务”时
3.8K42发布于 2019-06-02 - 来自专栏服务端技术杂谈
作业帮多活架构
今天分享下作业帮的多活架构，整体方案还是比较简单的，对于大家理解多活架构的设计和多活架构带来的价值应该是有帮助的。 多活模式 多活模式，是通过DNS的流量分配，将不同比例的流量分配到不同的云机房，在云机房里面，实现了所有服务的流量闭环。 当某个云出现故障时，通过DNS切换，将用户流量调走。 多活模式是最理想的方案。 但单云服务等量的部署以及服务闭环还是很难实现的事情。 多云架构全貌 最底层是资源层，包含计算、存储、网络。 以上就是作业帮的多活架构设计，整体设计方案还是非常简单的，对于想做的多活架构的业务来说，上手还是比较简单的。
87720编辑于 2023-08-08 - 来自专栏架构师之路
多机房多活架构，究竟怎么玩？
多机房多活架构，什么是理想状态下的“同机房连接”？ ? 多机房多活架构，做不到理想状态下的“同机房连接”，有没有折中方案？ 如果完全避免跨机房调用的理想状态做不到，就尽量做到“最小化”跨机房调用。 ? 该多机房多活架构，并没有做到100%的“同机房连接”，通常称作伪多机房多活架构。 伪多机房多活架构，有“主机房”和“从机房”的差别。 （2）跨机房写，会多10毫秒延时； 小结： （1）理想多机房多活架构，是纯粹的“同机房连接”，仅有异步数据同步会跨机房； （2）理想多机房多活架构，会有较严重数据一致性问题，仅适用于具备数据聚集效应的业务场景 ，例如：滴滴，快狗打车； （3）伪多机房多活架构，思路是“最小化跨机房连接”，机房区分主次，落地性强，对原有架构冲击较小，强烈推荐； 临时性多机房多活架构，是机房迁移过程中的一个过渡状态，机房迁移步骤又该如何
1.7K21发布于 2020-03-23 - 来自专栏大数据技术架构
京东JDHBase异地多活实践
JDHBase上承载了大量核心业务，遍布全球多个Data Center。为了保障业务稳定不间断运行，我们构建了JDHBase集群的异地多活系统。主要介绍在我们在异地多活系统的实践。 JDHBase异地多活架构 JDHBase服务端与客户端交互主要包含三个组件：Client、JDHBase集群、Fox Manager。 我们对可靠性要求比较高的业务做了异地多活备份。 ? Active Cluster：正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster，同时保证数据不丢失，但是会有延迟。 实际生产中，我们根据两个建群间的Replication，构建了多集群间的Replication拓扑，使得集群互为主备。 一个集群上会承载多个业务，不同的业务的备份也会散落在不同的集群上，形成多集群间的拓扑结构。 ? 3 Client ?
1.6K42发布于 2020-03-11 双活、异地多活架构怎么设计才不翻车？
引言：为什么要做多活架构 说到多活架构，很多同学第一反应可能是"这玩意好高大上啊"。确实，多活架构听起来就像是互联网大厂的专利，但随着业务的发展，越来越多的公司都会面临这个问题。 2.2 多活架构分类 这张图清晰地展示了不同多活架构的特点。同城双活就像在同一个小区的不同栋楼里放设备，网络延迟很小；而异地多活则像在不同城市开分公司，距离远了但覆盖面更广。 3. 异地多活架构设计 异地多活是多活架构的高级版本，复杂度会有质的提升。就像从骑自行车升级到开飞机，需要掌握更多技能。 4.1 整体架构设计 这个架构图展示了典型的异地三活架构。 解决方案： 分阶段建设，先同城双活再异地多活 非核心业务可以使用冷备方案 充分利用云厂商的多活产品 8. 总结 多活架构设计是一个复杂的系统工程，需要考虑业务特点、技术实现、成本控制等多个方面。 最后，多活架构的成功实施需要整个团队的配合，从开发到运维，从产品到测试，每个人都需要理解多活架构的特点和要求。只有这样，才能真正做到"多活不翻车"。
97310编辑于 2025-11-06双活&多活的高可用架构，以及伪双活的陷阱规避
近期收到客户关于 XGuard 产品异地双活部署的咨询。本文以此为契机，给大家深入浅出地介绍双活、多活以及假双活。欢迎大家提出宝贵意见。 多活架构（Multi-Active） 多活架构是双活的扩展，指的是多个站点（通常≥3）同时处于活跃状态，共同承担业务负载。每个站点都具备完整的业务处理能力和数据存储，且相互之间实时同步数据。 多活特点： 更高可用性：多个站点冗余，单点故障不影响整体服务。 地域扩展性：支持跨区域甚至全球化部署（如跨城市、跨国家）。 就近访问：用户可访问最近的站点，降低延迟。 与双活相比，多活需要更复杂的流量调度、负载均衡和故障恢复机制，数据同步难度更大。应用场景比如大型互联网公司的全球多活数据中心（如 AWS 的多区域部署），以及金融行业的多中心架构。 这里也要告诉大家，我们的XGuard产品对多活也是支持的，在多个金融行业客户有实际应用落地。
22010编辑于 2026-04-21- 来自专栏程序猿DD
高可用解决方案：同城双活？异地双活？异地多活？怎么实现？
高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。 然后，以前我们的停机冷备是在凌晨没有人使用的时候进行，但是现在很多的互联网应用已经是面向全球了，所以，任何时候都是有人在使用的。 数据丢失。 实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。 相对而言，饿了么的多活方案可能更适合大多数的企业。 本文只是通过画图的方式进行了简单的描述，其实异地多活是需要很多很强大的基础能力的。 你们现在的业务模块中，哪些业务是可以做多活的，哪些无法做多活？ 所有的业务都要做多活吗？还是只需要核心业务做多活？ 来源 | https://blog.dogchao.cn/?
5K22编辑于 2023-04-04 - 来自专栏CSDN搜“看，未来”
从 单体架构 到 异地多活
异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？ ---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地多活 系统可用性 让我们从最基础的开始往上垒。 ---- 异地双活 按照上面的思路，只要把 “同城双活” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗？ 因为是异地，两个机房之间的专线也将升级为 跨域专线 了。 例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。 == 双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。 == ---- 异地多活 理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
1.4K31编辑于 2022-05-06 - 来自专栏杨建荣的学习笔记
MySQL机房多活的初步设想
首先需要明确下概念的边界，我们初步的共识是：同城双活，异地灾备。 而要实现同城双活，在整个方案中则是重中之重，同时要实现双活，必然需要和业务架构结合起来，而找到一个适中的平衡点。 我们可以在行业里看到很多的伪双活的设计，从设计上来说也没有问题，但是会存在一些局限性。 我们主要从数据延迟和数据冲突来展开，如下是一个多IDC架构的设计方案，可以把两个不同的业务整合起来，做到schema级别的隔离，然后业务侧可以实现多写。 ?
1.5K40发布于 2019-07-22 - 来自专栏架构狂人
高可用架构之异地多活
应用场景 顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、 单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？ 因此，异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多活。 因此，跨国异地的“多活”，和跨城异地的“多活”，实际的含义并不完全一致。 设计跨城异地多活架构 我们讲完了异地多活设计的核心要点，下面我们谈一下如何设计跨城异地多活架构。
96921编辑于 2023-08-16 - 来自专栏深度学习与python
同城容灾+异地多活是全球化容灾处理的最好模式吗？
随着业务的快速发展以及部署需求的调整，我们进一步演进到异地多活模式。目前，业界内一些领先的大公司已经实现了相当成熟的异地多活部署模式。 在海外，我们首先采取了跨区域的异地多活模式，随后根据区域化业务发展的需要，进一步调整为异地多活和同城容灾的结合模式。 国内容灾建设 字节国内的容灾架构主要经历了三个发展阶段：单机房、同城多机房，以及目前的异地多活模式。 对于这种读取密集型场景，我们会基于读取场景进行异地多活的建设。这就是基于业务的差异性灵活调整的特殊异地多活模式了。对于电商类业务，我们的解决方案与业界的基本解决方案相似，我在这里就不详细展开了。 这一融合过程之后，我们在 2019 年开始实施异地多活以及多区域的异地容灾模式。 我们的演进可以大致分为两个阶段。
1.2K10编辑于 2024-07-26 - 来自专栏腾讯云数据库(TencentDB)
TBase-手工创建数据多活
今天这篇文章主要是实操，给大家演示如何利用SQL语句手工创建数据多活。 实验描述： 利用数据多活同步mc.public.test_repl到postgres.public.test_repl的数据。 x.relname = 't1' and c.relnamespace = n.oid) and (indisunique = true or indisprimary = true )) 原因： --数据多活使用的是逻辑复制原理
1K30发布于 2020-12-07 - 来自专栏深度学习与python
混合云的多活架构指南
一文中介绍了混合云（广义的多云）的诸多架构以及各自的优势，本篇会重点来介绍下混合云下的多活架构。 但是，更彻底的方案还是不同云各自进行服务等量部署，做到真正的多活，随时可以做到流量和容量的调度。 挑 战 多活架构的优势很明显，但背后面临的挑战也是巨大的。 设计目标 讲了这么多，该如何设计多云多活的方案。作业帮在线业务坚定地选择多活多云的策略，只有这样才能带来理想的稳定性和成本收益。 生活在云原生的时代，我们是幸运的。 下面介绍下作业帮各层多活建设的概要，后面每一个方向还会有单独的文章再进行详细介绍。 上述为作业帮混合云多活架构的综述，后续文章会逐渐为大家介绍多活架构中 IaaS、PaaS、SaaS 的技术细节以及迁移新云的 SOP，请大家持续关注。
1.1K30编辑于 2022-06-13 - 来自专栏服务端技术杂谈
多活架构需要考虑哪些问题？
只为核心业务系统设计多活方案，降低方案实施的成本和复杂度。 比如通过价值链看核心系统，流量高的系统往往是核心系统。 核心业务强依赖的系统是核心系统。 产生收入的业务系统是核心系统。 基于这几个角度，盘清需要做双活改造的核心系统。 其次，做好数据分类治理。 盘好核心系统分级之后，接下来就是要看系统背后的数据了。 主要是考虑，一旦出现系统问题，背后的这些数据应该如何处理。 因为双活或者异地多活，涉及到数据在多个可用区的同步，梳理好哪些数据需要跨区复制同步，对于降低复杂度，节省成本，减少延迟都很有帮助。
36230编辑于 2023-08-08 - 来自专栏Forrest随想录
做容灾，双活、多活、同城、异地、多云，到底应该怎么选？
而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。 准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。 讲到这里，我想多活就不用讲了，时延这个问题解决不了，多活就是扯淡，至于同城和异地，我想看明白的读者，也知道怎么选择了，其实一样，还是取决于时延。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。 现实情况，比我写的要复杂的多的多，推荐大家看两个成功案例，一个是毕玄的异地多活数据中心，一个是饿了么异地多活，几个关键字google一下就有了，里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助
3.5K41发布于 2019-03-18 怎样做YashanDB支持异地多活部署
随着业务的全球化和数字化转型，异地多活部署成为了数据管理的一种关键策略。如何实现这一部署方式以支持YashanDB，在技术实现和架构设计上都提出了挑战。 本文将深入探讨YashanDB异地多活部署的必要组件、架构设计和实施方案，确保数据安全和高可用性，从而提升系统的整体稳定性和业务连续性。 架构设计异地多活部署的架构设计必须可靠且高效，以确保在不同地理位置的数据中心之间能够实时处理数据，并保持一致性和可用性。1. 数据一致性管理在异地多活部署中，数据一致性至关重要，YashanDB通过以下几种策略维护数据一致性：1. 本文提供的技术方案和实施步骤，旨在帮助工程师快速实现YashanDB的异地多活部署，并通过不断的监控和优化，最终实现高效的数据管理。实现有效的异地多活部署将为企业带来更大的竞争优势以及持续的业务保障。
22900编辑于 2025-07-24- 来自专栏服务端技术杂谈
拆解交易系统--异地多活
或者基于高可用 / 高性能的需求，需要做异地多活。 异地多活容灾 很多巨型互联网产品发展到一定规模之后，其可用性往往造成很大经济损失，比如微信，支付宝这些用户规模巨大的产品，如果可用性有一点的降级，都会对大规模的用户影响，所以微信，支付宝这些产品早已做了异地多活
99120发布于 2020-01-16
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号