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