- 综合排序
- 最热优先
- 最新优先
- 来自专栏性能与架构
异地多活架构
异地多活的代价： 系统复杂度会有质的变化。 成本大大增加。 架构模式 1. 同城异区 部署在同一个城市不同区的机房，用专用网络连接。 这就出事儿了，所以这类数据不会做跨城异地多活，只能用同城异区架构，因为同城的网络环境要好很多，可以搭建多条互联通道，成本也不会太高。 跨城异地多活设计技巧 1. 保证核心业务的异地多活 思维误区：要保证所有业务都能异地多活。 只保证绝大部分用户的异地多活 思维误区：要保证业务 100% 可用。 物理规律决定了异地多活无法保证100%的业务可用。 内容整理自《从0开始学架构》
3.7K21发布于 2019-05-07 - 来自专栏运维之美
谈谈异地多活架构
应用场景 顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动 单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？ 其实不然，因为实现异地多活架构不是没有代价的，相反其代价很高，具体表现为： 系统复杂度会发生质的变化，需要设计复杂的异地多活架构。 架构模式 根据地理位置上的距离来划分，异地多活架构可以分为同城异区、跨城异地、跨国异地。接下来我详细解释一下每一种架构的细节与优缺点。 基于这个分析，跨城异地多活是架构设计复杂度最高的一种，接下来将介绍跨城异地多活架构设计的一些技巧 技巧1：保证核心业务的异地多活 “异地多活”是为了保证业务的高可用，但很多架构师在考虑这个“业务”时
3.8K42发布于 2019-06-02 - 来自专栏服务端技术杂谈
作业帮多活架构
今天分享下作业帮的多活架构，整体方案还是比较简单的，对于大家理解多活架构的设计和多活架构带来的价值应该是有帮助的。 多活模式 多活模式，是通过DNS的流量分配，将不同比例的流量分配到不同的云机房，在云机房里面，实现了所有服务的流量闭环。 当某个云出现故障时，通过DNS切换，将用户流量调走。 多活模式是最理想的方案。 但单云服务等量的部署以及服务闭环还是很难实现的事情。 多云架构全貌 最底层是资源层，包含计算、存储、网络。 定期演练 多云架构不能停留在方法论或者方案上，为了确保多云架构真正在出现问题时可用，务实的做法是需要进行定期断网演练。 比如半年进行一次，用于发现架构的隐患问题以及预案的执行流程流畅性。 以上就是作业帮的多活架构设计，整体设计方案还是非常简单的，对于想做的多活架构的业务来说，上手还是比较简单的。
87620编辑于 2023-08-08 - 来自专栏vivo互联网技术
同城双活与异地多活架构分析
服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。 1、多活场景 多活架构的关键点就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是指实时提供服务的意思。 单纯从描述来看多活很强大，能够保证在灾难的情况下业务都不受影响，是不是意味着不管什么业务，我们都要去实现多活架构呢？ 其实不是，实现多活架构都要付出一定的代价，具体表现为： 不同多活方案实现复杂度不一样，随着业务规模和容灾级别的提升，多活方案会给业务系统设计带来更大复杂度。 四、异地多活 异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。
14.7K65发布于 2020-09-14 - 来自专栏架构师之路
多机房多活架构，究竟怎么玩？
多机房多活架构，什么是理想状态下的“同机房连接”？ ? 该多机房多活架构，并没有做到100%的“同机房连接”，通常称作伪多机房多活架构。 伪多机房多活架构，有“主机房”和“从机房”的差别。 伪多机房多活架构，是一个实践性，落地性很强的架构，它对原有架构体系的冲击非常小，和单机房架构相比，仅仅是： （1）跨机房主从同步数据，会多10毫秒延时； 画外音：主从同步数据，本来就会有延时。 （2）跨机房写，会多10毫秒延时； 小结： （1）理想多机房多活架构，是纯粹的“同机房连接”，仅有异步数据同步会跨机房； （2）理想多机房多活架构，会有较严重数据一致性问题，仅适用于具备数据聚集效应的业务场景 ，例如：滴滴，快狗打车； （3）伪多机房多活架构，思路是“最小化跨机房连接”，机房区分主次，落地性强，对原有架构冲击较小，强烈推荐； 临时性多机房多活架构，是机房迁移过程中的一个过渡状态，机房迁移步骤又该如何
1.7K21发布于 2020-03-23 - 来自专栏CSDN搜“看，未来”
从 单体架构 到 异地多活
异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？ ---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地多活 系统可用性 让我们从最基础的开始往上垒。 单机架构 早期发展的架构模型，如果你的业务量比较少的话可以用这个。客户端请求进来，业务层读写数据库，返回结果。 不要看不上这个架构，我个人觉得目前这个架构在跨界领域还是应用面比较广的。 这种方案我们把它叫做「同城双活」。 ---- 两地三中心 我们的架构随着风险等级的提升在不断的升级，现在也该到了可接受的最高的风险等级了吧：天灾人祸。 == ---- 异地多活 理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
1.4K31编辑于 2022-05-06 - 来自专栏深度学习与python
混合云的多活架构指南
作者 | 董晓聪 吕亚霖 策划 | 褚杏娟 在之前的《如何正确选择多云架构？》一文中介绍了混合云（广义的多云）的诸多架构以及各自的优势，本篇会重点来介绍下混合云下的多活架构。 背 景 企业选择混合云的技术诉求中，主要因素还是稳定性和成本 & 服务，而对这两点的极致追求就是多活架构。 稳定性 业务探索阶段追求效率，技术上一般会选择单云单活的架构。 但是，更彻底的方案还是不同云各自进行服务等量部署，做到真正的多活，随时可以做到流量和容量的调度。 挑 战 多活架构的优势很明显，但背后面临的挑战也是巨大的。 编后语 一路走来，笔者对作业帮混合云多活架构的建设感受良多，其不单单是容器多集群的管理和流量调度，更是一整套贯穿资源和应用的企业架构整体解决方案。 上述为作业帮混合云多活架构的综述，后续文章会逐渐为大家介绍多活架构中 IaaS、PaaS、SaaS 的技术细节以及迁移新云的 SOP，请大家持续关注。
1.1K30编辑于 2022-06-13 - 来自专栏用户4352451的专栏
分布式系统架构-----异地多活架构
分布式系统架构-----异地多活架构 背景 最近公司在搞异地多活，特来写篇文章来学习和回顾一下。 异地多活看字面意思 ：不通的地方部署服务。 这些自然灾害我们是不可避免的所以我们得从架构层面解决这种突发问题。 异地多活架构 1. 什么是异地多活架构？ 异地：不同的地理位置，多活：不同的地理位置的服务都能独立提供服务。 异地多活的目的也就是容灾，容灾的话我们也可以理解为某个地方服务出现了灾难性故障，而服务仍然能正常提供服务。 2. 系统性能，因为异地多活会部署在不同的城市，所以距离就会带来延迟（距离越远，耗时越久）。 3. 常用的几种多活方案 同城异区 同城异区指的是将业务部署在同一个城市不同区的多个机房。 应用 在背景也讲了我们公司也做了异地多活，多活的方式数据跨城异区。一个集群部署在广州南沙，一个部署在广东佛山。
2.2K11编辑于 2022-05-05 - 来自专栏服务端技术杂谈
多活架构需要考虑哪些问题？
只为核心业务系统设计多活方案，降低方案实施的成本和复杂度。 比如通过价值链看核心系统，流量高的系统往往是核心系统。 核心业务强依赖的系统是核心系统。 产生收入的业务系统是核心系统。 基于这几个角度，盘清需要做双活改造的核心系统。 其次，做好数据分类治理。 盘好核心系统分级之后，接下来就是要看系统背后的数据了。 主要是考虑，一旦出现系统问题，背后的这些数据应该如何处理。 因为双活或者异地多活，涉及到数据在多个可用区的同步，梳理好哪些数据需要跨区复制同步，对于降低复杂度，节省成本，减少延迟都很有帮助。
36230编辑于 2023-08-08 - 来自专栏架构狂人
高可用架构之异地多活
如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。 今天我来聊聊异地多活架构，以及异地多活架构的设计技巧和流程。 单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？ 、 接下来我将介绍跨城异地多活架构设计的一些技巧和步骤 技巧1：保证核心业务的异地多活 “异地多活”是为了保证业务的高可用，但很多架构师在考虑这个“业务”时，会不自觉地陷入一个思维误区：我要保证所有业务都能 设计跨城异地多活架构 我们讲完了异地多活设计的核心要点，下面我们谈一下如何设计跨城异地多活架构。 总结 今天我们谈了异地多活架构的应用场景和常见架构模式，结合CAP、BASE等理论讲了异地多活的设计技巧，并详细讲述了如何设计异地多活架构，希望对你有所帮助。
96621编辑于 2023-08-16 双活、异地多活架构怎么设计才不翻车？
引言：为什么要做多活架构 说到多活架构，很多同学第一反应可能是"这玩意好高大上啊"。确实，多活架构听起来就像是互联网大厂的专利，但随着业务的发展，越来越多的公司都会面临这个问题。 2.2 多活架构分类 这张图清晰地展示了不同多活架构的特点。同城双活就像在同一个小区的不同栋楼里放设备，网络延迟很小；而异地多活则像在不同城市开分公司，距离远了但覆盖面更广。 3. 异地多活架构设计 异地多活是多活架构的高级版本，复杂度会有质的提升。就像从骑自行车升级到开飞机，需要掌握更多技能。 4.1 整体架构设计 这个架构图展示了典型的异地三活架构。 最佳实践建议 先业务后技术：多活架构要服务于业务需求，不要为了技术而技术 渐进式演进：从简单到复杂，从局部到整体 充分测试：多做故障演练，提前发现问题 持续优化：多活架构需要持续的监控、调优和改进 多活架构不是银弹 最后，多活架构的成功实施需要整个团队的配合，从开发到运维，从产品到测试，每个人都需要理解多活架构的特点和要求。只有这样，才能真正做到"多活不翻车"。
97210编辑于 2025-11-06双活&多活的高可用架构，以及伪双活的陷阱规避
近期收到客户关于 XGuard 产品异地双活部署的咨询。本文以此为契机，给大家深入浅出地介绍双活、多活以及假双活。欢迎大家提出宝贵意见。 双活架构（Active-Active） 双活架构指的是两个站点（或数据中心）同时处于活跃状态，共同处理业务流量和数据处理任务。 多活架构（Multi-Active） 多活架构是双活的扩展，指的是多个站点（通常≥3）同时处于活跃状态，共同承担业务负载。每个站点都具备完整的业务处理能力和数据存储，且相互之间实时同步数据。 与双活相比，多活需要更复杂的流量调度、负载均衡和故障恢复机制，数据同步难度更大。应用场景比如大型互联网公司的全球多活数据中心（如 AWS 的多区域部署），以及金融行业的多中心架构。 这里也要告诉大家，我们的XGuard产品对多活也是支持的，在多个金融行业客户有实际应用落地。
21910编辑于 2026-04-21- 来自专栏技术那些事
详解：淘宝高可用异地多活架构
p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里、腾讯、百度、网易、新浪等等都已经完成了异地多活的技术重构。 这种架构下，读写分离是很好的，单写多读，减少冲突又提高了效率。 实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover 等操作即可。 但其实双活只是一个临时的步骤，最终的目的是切换到多活。 淘宝的解决方式和我们切分微服务的方式有点类似： 淘宝按照单元切分的异地多活架构 注意看图中的数据同步箭头。 /eleme-arch 《阿里异地多活与同城双活的架构演进》 https://www.sohu.com/a/158859741_444159 《阿里云 数据库异地多活解决方案》 https://help.aliyun.com
3.2K12发布于 2020-11-30 YashanDB数据副本管理及多活架构实现
因此，深入理解YashanDB的数据副本管理机制及多活架构的实现原理，对于提升数据库整体稳定性和业务连续性具有重要意义。YashanDB数据副本管理机制1. 共享集群多活架构YashanDB的共享集群构建在Shared-Disk架构上，硬件依赖共享存储，软件引入崖山集群内核（YCK）实现聚合内存级别的多实例协同。 该多活架构在保持强一致性的同时，实现了读写的线性扩展和高可用保障。YashanDB多活架构技术优势1. 采用共享集群多活架构：对于高并发、海量访问场景，部署共享集群，提高系统并发处理能力和可扩展性，实现数据强一致的多实例读写。 共享集群架构突破了传统单主节点瓶颈，通过全局资源管理和文件系统保障多实例多活的强一致读写，满足了现代数据库高可用、高性能和高扩展的需求。
26510编辑于 2025-08-21YashanDB多活架构实现企业业务持续运营
传统的主备架构虽能一定程度保障高可用，但存在单点故障风险及切换延迟。为实现业务的持续稳定运行，多活架构逐渐成为主流选择。 本文将围绕YashanDB多活架构的技术实现，深入探讨其体系架构、关键技术和优势，为企业构建高可用、高性能的数据库解决方案提供技术指导。 该架构提供多实例并发读写能力，具备高可用、高扩展和短时切换的优势，符合高端核心交易场景需求。 结论随着企业级应用对数据库服务稳定性、可用性和扩展性的要求不断提升，YashanDB多活架构通过共享集群、分布式集群和单机主备部署等多样化部署方案，结合高效的存储引擎、强大的事务控制与优化机制，提供了可靠的企业数据库基础 未来，伴随数据规模激增和业务多样化，持续优化的多活架构将成为数据库系统核心竞争力，驱动企业业务持续稳定运营，促进数字化转型深入发展。
25810编辑于 2025-08-18- 来自专栏架构师之路
多机房多活，多机房平滑迁移架构方案全集（上+中+下）
放假前三天，写了三篇长文，关于多机房多活，多机房平滑迁移架构与方案的。可能是临近放假，又亦或疫情的影响，阅读都比较低，现将“上中下”汇总成全集，一窥全貌，欢迎错过的同学补课。 上篇 《多机房平滑迁移架构方案目标》，主要包含三块内容： （1）单机房架构的核心是什么？ （2）机房迁移架构方案的设计目标是什么？ （3）为什么说，想要平滑的实施机房迁移，临时性的多机房架构不可避免？ 中篇 《多机房多活，常见架构实践》，主要包含三块内容： （1）什么是理想多机房多活架构？ （2）理想多机房多活架构，存在什么问题，适用于什么业务场景？ （3）什么是伪多机房多活架构？适用于什么业务场景？ 希望通过这三篇，大家能够对多机房多活架构，多机房平滑迁移架构与方案，有一个初步的了解。 任何脱离业务的架构设计都是耍流氓。
1.4K41发布于 2020-03-23 YashanDB多活架构设计，提升系统抗灾能力
因此，构建全面的多活架构，提升系统的抗灾能力变得尤为重要。 YashanDB体系架构的多活设计YashanDB的多活架构设计采用了先进的分布式数据库技术，通过集群配置实现高可用和负载均衡，确保数据在不同节点上实现实时同步，从而提高系统的抗灾能力。1. 高可用性设计通过准备多种备份方案，YashanDB的多活架构确保了数据的高可用性，降低了因单点故障导致的数据丢失风险。 目标：具体可操作的技术建议针对提升系统抗灾能力，以下是基于YashanDB多活架构设计的具体技术建议：考虑实施多活架构，合理选择YashanDB的部署模式（单机、分布式或共享集群）来满足业务需求。 YashanDB的多活架构设计，通过合理的部署架构、主备复制、高可用性设计以及故障检测机制，为企业提供了可行的抗灾解决方案。
15000编辑于 2025-06-28- 来自专栏程序猿DD
聊聊高可用的“异地多活”架构设计
这种架构下，读写分离是很好的，单写多读，减少冲突又提高了效率。 实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。 阿里是这么思考的： 阿里理想中的异地多活架构 实际上我猜测很多业务也是按照上图去实现的，比如滴滴打车业务这种，所有的业务都是按城市划分开的。用户、车主、目的地，他们的经纬度通常都是在同一个城市的。 淘宝的解决方式和我们切分微服务的方式有点类似： 淘宝按照单元切分的异地多活架构 注意看图中的数据同步箭头。 按照业务进行单元切分，已经需要对代码和架构进行彻底的改造了（可能这也是为什么阿里要先从双活再切到多活，历时3年）。比如，业务拆分，依赖拆分，网状改星状，分布式事务，缓存失效等。
2.3K21编辑于 2022-10-11 - 来自专栏HHFCodeRv
云原生环境下对“多活”架构的思考
当公司规模较小时，一般情况下公司的架构会像下图所示。 当公司的业务达到了一定的规模，一般情况都会再选一个云服务商形成“多云多活”来保证系统的稳定性、高可用。有幸参与过某公司的双云方案的落地，这里聊聊这种多云多活的方案的一些思考。 多活为什么重要？ 特别当 B 站故障后，各路文章出来解读多活，如何实施多活（很多的文章当个乐子看即可）。像这种比较基础的服务故障，往往恢复时间都是不确定的，多活确实是解决问题的有效手段，能大大提高我们系统的容灾能力。 多活是高可用架构设计的保障，根据多活等级的要求不同，多活还有同城双活，异地双活，两地三中心，三地五中心等。对多活的要求越高，投入的资源也就会越高。这里就不再详细讲述这些名字背后的技术细节了。 结论 其实很多的公司的多活最终都因为各种原因沦为了“伪多活”。
1.6K31发布于 2021-11-04 - 来自专栏CSDN技术头条
荔枝FM架构师刘耀华：异地多活IDC机房架构
多机房架构存在的原因 单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不可用，所有的业务就都不可用。 大陆的网络和国外的网络有一定的隔离性，如果没有做多机房的连通性，数据的传输和实时性就会有问题。 跨机房的作用是为了备份，一个机房的数据放在另一个机房是异地多活。 而数据多版本，类似于乐观锁，导致其他人和我方数据冲突的机会并不是那么多，只要在提交的时候发现版本不一样，更新一下，汇总数据就可以了。 这让每一步都胆战心惊，错一个字母或者多一个空格都可能会出现不可预估的后果。 架构师相当于产品经理，用户相当于程序员，产品为用户服务。 分享人：刘耀华，荔枝FM架构师，负责荔枝FM服务端系统架构设计与实施，以及数据中心异地多活方案的设计。对服务端系统架构进行分布式集群、高可用、负载均衡等有多年经验与心得。
2K61发布于 2018-02-11
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号