- 综合排序
- 最热优先
- 最新优先
- 来自专栏vivo互联网技术
同城双活与异地多活架构分析
二、同城双活 同城双活是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制 ，保证高度的数据完整性和数据零丢失。 3、同城双活方案评估 优势 服务同城双活，数据同城灾备，同城不丢失数据情况下跨机房级别容灾。 两地三中心方案评估 优势 服务同城双活，数据同城灾备，同城不丢失数据情况下跨机房级别容灾。 同城双活和两地三中心建设方案建设复杂度都不高，两地三中心相比同城双活有效解决了异地数据灾备问题，但是依然不能解决同城双活存在的多处缺点，想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题 3、非单元化应用和数据 对于无法单元化的业务和应用，会存在下面两种可能性： （1）延时不铭感但是对数据一致性非常铭感，这类应用只能按照同城双活方式部署。
14.5K65发布于 2020-09-14 - 来自专栏泛互云原生
使用ChatGPT实现同城双活部署
前言今天老板让我写一篇腾讯云云原生的微服务项目部署实践，还要实现同城双活。 听说ChatGPT已经“出圈”了，无所不能，还可以帮人写文章，刚好最近比较懒，看看他能否帮我写完这篇实践，并教会我实现同城双活部署。 图片同城双活改造基础资源的部署，可能对ChatGPT来说有些简单，接下来，给他一些挑战，给我们提供一个应用层的跨区高可用方案。 我们希望只用一套TKE集群实现同城双活，最大程度的节约成本。 从接入层、应用层到数据层，快速地搭建出云上同城双活架构，从而避免单可用区故障，可能导致的访问中断。Excellent！
3.8K190编辑于 2023-01-09 - 来自专栏高可用
TCM同城双活设计方案
，基于TKE集群本身的健康检查机制等，保证了进程的高可用 TCM详细资料参考：https://cloud.tencent.com/document/product/1261/62928 架构设计方案 同城双活需求分析 使用了TCM产品，只需要考虑数据面的高可用建设，即业务程序的同城双活。 这种架构模式下，有两个技术点需要解决： 接入层的流量负载均衡 逻辑层的set部署，即可用区内流量闭环 设计方案 适合上面同城双活的集群部署模式，如下图一、图二所示。 图二 建设要求 一个服务网格+一个TKE集群 一个服务网格+两个TKE集群 部署模式 承载双活业务的
99511编辑于 2023-10-15 - 来自专栏程序猿DD
高可用解决方案：同城双活？异地双活？异地多活？怎么实现？
高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。 其他的高可用方案还可以参考各类数据库的多种部署模式，比如mysql的主从、双主多从、MHA；redis的主从，哨兵，cluster等等。 同城双活 前面讲到的几种方案，基本都是在一个局域网内进行的。 同城双活其实和前文提到的双机热备没有本质的区别，只是“距离”更远了，基本上还是一样（同城专线网速还是很快的）。双机热备提供了灾备能力，双机互备避免了过多的资源浪费。 异地双活 同城双活可以应对大部分的灾备情况，但是碰到大面积停电，或者自然灾害的时候，服务依然会中断。 按照业务进行单元切分，已经需要对代码和架构进行彻底的改造了（可能这也是为什么阿里要先从双活再切到多活，历时3年）。比如，业务拆分，依赖拆分，网状改星状，分布式事务，缓存失效等。
4.9K22编辑于 2023-04-04 - 来自专栏架构之美
Elastic Job 从单点到高可用、同城主备、同城双活
网上关于Elastic Job的较高级的博文甚少，本文试图结合自身实践的一些经验，大致讲解其方案原理，并延伸至同城双机房的架构实践。 - 同城双活模式 - 以上这样改造后，针对定时任务就已经解决了两个问题： 1、定时任务能实现在两个机房下的高可用； 2、任务能优先调度到指定机房。 我们能否再进一步做到同城双活呢？也就是，B机房也会承担一部分的流量？例如10%？ 以上两种方案都能实现让A、B两个机房都有流量（有任务在被调度），从而实现所谓的双活。 以下针对上面抛出来的方案一，给出一个双活的示意代码和架构。 注：这里任意一个机房不可用了，任务均能在另外一个机房调度，这里增强的只是对于不同任务做针对性的优先调度实现双活： public class ActiveStandbyESJobStrategy extends
93220发布于 2021-07-06 - 来自专栏Forrest随想录
做容灾，双活、多活、同城、异地、多云，到底应该怎么选？
而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。 准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。 既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。 讲到这里，我想多活就不用讲了，时延这个问题解决不了，多活就是扯淡，至于同城和异地，我想看明白的读者，也知道怎么选择了，其实一样，还是取决于时延。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
3.4K41发布于 2019-03-18 - 来自专栏纯洁的微笑
做容灾，双活、多活、同城、异地、多云，到底应该怎么选？
而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。 准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。 既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。 讲到这里，我想多活就不用讲了，时延这个问题解决不了，多活就是扯淡，至于同城和异地，我想看明白的读者，也知道怎么选择了，其实一样，还是取决于时延。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
3.3K31发布于 2019-06-03 - 来自专栏冰河技术
高可用的巅峰技术：跨机房部署、同城双活、异地多活究竟怎么玩儿？
一、容灾介绍 同城双活和异地多活都是典型的系统容灾部署方案，对于企业来说，尤其是大型互联网公司，比较重要的系统一般都会做容灾，采用同城双活，甚至异地多活的架构方案进行部署。 （1）同城双机房专线延迟 一般情况下，同城双机房专线延迟在1ms~3ms之间。 四、同城双活 同城双活方案是将系统部署在同一个城市的不同机房中，这种方案能够做到机房级别的容灾，而不能做到城市级别的容灾。 五、异地多活 一般情况下，系统做同城双活容灾方案就够了，如果系统的业务发展到了淘宝级别，就需要考虑异地多活了。 还有一点需要说明的是：如果同城双活架构方案能够满足需求，就不要轻易尝试异地多活架构，实际上，异地多活架构过于复杂，很少有公司能够搭建出真正的异地多活架构。
3.5K23编辑于 2024-08-14 - 来自专栏腾讯云原生团队
GIAC 大会预告 | 揭秘腾讯云原生同城双活解决方案
针对上述挑战，在大厂有近十年存储架构设计经验的腾讯云高级解决方案架构师邱浩将于7月31日11:00-12:00，在深圳华侨城洲际酒店马德里2厅为您带来《腾讯云原生同城双活解决方案》的分享。 主题：腾讯云原生同城双活解决方案 时间：7月31日 11:00—12:00 讲师：腾讯云高级解决方案架构师邱浩 · 解决思路 · 腾讯云基于内部高可用架构的多年沉淀，推出云原生同城双活解决方案，在资源高效利用 、业务零改造、运维低代价的前提下，将部署在单个数据中心的业务，在线升级为同城双活架构，进而提升业务的连续性。 · 成果展现 · 1、业务零改造代价实现同城双活架构。 2、单数据中心故障恢复速度快，且不增加运维复杂度。 3、方案已协助数个电商平台在线升级为同城双活架构。 2、了解腾讯云云原生同城双活解决方案及价值。 3、了解常用数据库及中间件跨数据中心架构的实现原理。
2.8K51发布于 2021-07-28 - 来自专栏飞总聊IT
基于 RocketMQ 的同城双活架构在美菜网的挑战与实践
今天主要从三个方面进行分享： 美菜网消息队列的历史 基于 RocketMQ 我们做了那些事情 同城双活的选型和思考 美菜网消息队列的历史 ---- 美菜网历史上是多套 MQ 并存，Kafka 用于大数据团队 3、稳定性，保证整个平台的稳定可靠。 多语言的支持： ? 同城双活的选型和思考 ---- 背景： 1、保证数据可靠性，如果所有数据都在一个机房，一旦这个机房出了问题，数据有丢失的风险。 2、机房的扩容，单机房毕竟容量有限，多个机房可以分担流量。 方案选型： 1、同城冷备，备用一套服务存在但不对外提供服务，当另一套服务有问题时进行切换，但是真的出了问题，我们是否敢切流量呢？ 2、同城双活，平时就是双机房对外提供服务，出问题的时候切掉故障机房，真正实现容灾的目的。
1.2K10发布于 2019-09-17 - 来自专栏得物技术
同城双活：交易链路的稳定性与可靠性探索
画一幅简图来区分下我们这次同城双活的方案和业界异地双活方案的差异。 下面分别介绍：交易应用侧双活改造项目范围交易侧默认所有服务均参与同城双活改造，一方面内部应用之间的调用关系复杂，区分处理梳理工作量极高；另一方面快速的业务迭代也会改变互相之间的依赖关系，维护这套逻辑成本太高 交易依赖方应用双活改造仅仅依靠交易侧应用，无法完成所有的P0链路，如下单时依赖供应链侧时效。强依赖的外域服务同样纳入了同城双活改造范围。其改造点基本一致，不再赘述。 中间件RTO同城双活要求中间件在单个可用区出问题的时候，仍能对外提供服务。其设计目标的RTO为以下：主要组件双活改造方案DLB - 自研流量网关DLB是无状态组件，在两个可用区对等部署。 代理节点多分区部署，保障多可用区双活Sylas集群Raft节点3个分区部署，保障多可用区双活流量分配策略RPC流量双活的RPC的入口流量在DAG上进行调整，DAG会尽量根据用户ID进行流量分配。
1K23编辑于 2024-03-27 - 来自专栏开发者
「腾讯云顾问GameDay实践」如何有效进行同城双活容灾验证
GameDay目标：验证业务同城双活容灾架构的有效性 Step 1.使用云顾问绘制业务云上架构图（图1） Step 2.使用云顾问-混沌演练实施故障注入（图2） 场景1：CLB健康检查可用性验证 结论： CVM服务器宕机后，告警3min内生效；负载均衡CLB健康检查机制生效，成功将所有流量分配至备可用区服务器，用户请求整体不受影响 改进：由于备区服务器承载所有流量，导致系统性能下降，接口响应时间有所增加 ，需配置服务器自动扩展策略，避免单点过载风险 场景2：CVM服务器性能高可用验证 结论：CVM连续60sCPU负载达80%，告警3min内生效；系统接口响应时间变长，可能引起服务中断风险 改进：定期通过云顾问进行容量监测 ，对高负载风险实例提前扩容 场景3: MySQL主备高可用验证 结论：MySQL主节点故障后，备节点成功自动提为主节点，同时在原主区新拉起备节点。 主备切换总耗时15s，切换期间业务无明显感知，未出现故障异常，整体符合预期 Step 3.总结演练结论，导出演练报告（图3）
28210编辑于 2025-06-09 中粮信托基于 TencentOS 跨越 CentOS 停服危机，重塑同城双活基础设施
重构同城双活云底座： 构建由 SmartX 超融合集群 + TencentOS 操作系统 + 腾讯云 TDSQL 分布式数据库 组成的企业云方案。 在此基础上，率先建立本地同城双活数据中心，逐步实现 IT 基础设施的架构升级与国产化替代。
11810编辑于 2026-04-15- 来自专栏ICT售前新说
双活数据中心建设-网络&安全层双活设计
l建议使用波分设备来构建两数据中心的同城网络。l以太网交换机和FC交换机同时连接到波分设备，两个数据中心通过级联的方式互联。 网络双活核心技术 网络双活核心技术分析： 网络层双活主要通过SDN技术实现网络自动化部署，通过VXLAN构建跨数据中心大二层网络、通过EVPN技术实现跨数据中心互联，三大技术相辅相成共同实现网络层双活 网络安全层技术 网络双活核心技术分析： 双活数据中心网络安全防护建议最新等级保护2.0相关要求部署相关的安全设备进行整体安全防护。
6K20发布于 2021-03-29 - 来自专栏ICT售前新说
双活数据中心建设概览-part-3
本门课程就以华为双活数据中心建设为例，详细分析一下在双活数据中心建设过程中涉及到的端到端六层双活的实现方法。 这六层分别是存储层双活、计算层双活、应用层双活、网络层双活、传输层双活、安全层双活。 1、存储层双活：存储层主要依靠存储的双活特性来实现，2个数据中心都使用双活特性，当然也可以理解为集群特性，说白了它是通过跨数据中心的两套华为存储组建储集群的方式来实现双活。 【其实6层双活每一层都离不开集群这个词】 3、应用层双活：在物理机或虚机上都可以实现应用层双活，在物理机或者虚机里安装相关服务软件如web服务、APP服务，然后把多个应用拉到同一个集群里，当然这个操作需要借助集群软件来实现 可以通过以上6层双活实现技术为载体，根据用户要求建设出一套满足未来3-5年业务发展所需的双活数据中心.
1.2K30发布于 2021-03-29 - 来自专栏ImportSource
异地双活实践笔记
3、只能单活（对全局原子要求较高），不接受有一定时延的“不一致”窗口。 核心问题 数据同步、网络时延。 切换方式 1、自动切换。 3、所有的业务都适合做异地双活吗？ 异地多活效果看起来很诱人，但如果不假思索贪大求全的要求所有业务都实现异地多活的话，就会把自己带到坑里去。 （2）、客户端双写。 （3）、不去解决。不需要解决的前提是用户分区。分区后，从本质上说，其实是没有做到双活的。只是看起来一个业务确实被分到了多个机房而已。 6、读取问题。 在支付宝微博答复中，有一个新名词——“异地多活”。在传统了灾备方案中，一般提的都是同城灾备、异地灾备、两地三中心。 中国银行业，只有某国有大行在去年6月份实现了上海同城两个数据中心的双活，是“同城双活”，还没有实现“异地多活”，而且在灾难真正发生时，切换效果如何，还有待验证。
12.8K111发布于 2018-04-03 - 来自专栏菩提树下的杨过
ES异地双活方案
3、3个节点之间不断的数据同步，会使三地机房间的网络流量增加，特别是某个节点挂了，重新恢复后，会在短时间内从master上同步数据，有流量风暴的隐患。 解决了双机房ES"读"的问题，再来看“写”的问题，可能有同学说了，这还不简单，直接双写就行了吧，一份数据，向A、B机房的ES集群各写一份。 听想来貌似可行，但是有一些细节问题 ： 1、双写并非原子操作，如果A机房的ES集群写成功了，B机房的ES集群没写成功，该怎么办？ 2、当B机房的ES挂了，双写不进去时，过一段时间又恢复后，故障期间的数据，B机房的ES集群怎么补进去？如果手动事后补数据，虽然可行，但是毕竟麻烦。 当然，这个方案的提前是MQ本身是高可用的，不过这个不难做到，已经有一些rocket mq双机房多活的案例，不在本文讨论范围，大家可以自行搜索。
5.2K30发布于 2021-04-01 - 来自专栏ICT售前新说
双活数据中心建设-存储层双活设计（part-1）
存储层双活本质上是HyperMetro通过数据双写和DCL机制实现存储层数据的双活，两个数据中心同时对主机提供数据读写的能力。（即2端存储做集群、数据双写、数据一致性回滚）。 数据双写机制：应用服务器下发I/O请求时，可同时下发到本端Cache和远端Cache，从而保证本端Cache与远端Cache的变更数据一致性。 同时双活可以通过另一端存储系统的数据，对坏数据进行修复，保证两个数据中心的数据一致。
3.1K30发布于 2021-03-29 - 来自专栏冰河技术
超级加倍：互联网大厂的容灾架构设计与落地方案（跨机房部署、同城双活、异地多活）
一、容灾介绍 同城双活和异地多活都是典型的系统容灾部署方案，对于企业来说，尤其是大型互联网公司，比较重要的系统一般都会做容灾，采用同城双活，甚至异地多活的架构方案进行部署。 （1）同城双机房专线延迟 一般情况下，同城双机房专线延迟在1ms~3ms之间。 四、同城双活 同城双活方案是将系统部署在同一个城市的不同机房中，这种方案能够做到机房级别的容灾，而不能做到城市级别的容灾。 五、异地多活 一般情况下，系统做同城双活容灾方案就够了，如果系统的业务发展到了淘宝级别，就需要考虑异地多活了。 还有一点需要说明的是：如果同城双活架构方案能够满足需求，就不要轻易尝试异地多活架构，实际上，异地多活架构过于复杂，很少有公司能够搭建出真正的异地多活架构。
1.1K10编辑于 2024-07-25 - 来自专栏腾讯云混沌工程团队
【云顾问-混沌演练】乐元素 x 腾讯云混沌演练平台：游戏业务同城双活改造最佳实践
为了给用户提供更稳定可靠的使用体验，在2023年Q2开始，乐元素运维、业务团队联合腾讯云售后专家和技术专家，基于针对乐元素旗下休闲游戏产品《开心消消乐》展开同城双活改造项目，目的是了解并改善业务容灾部署状况 检验业务监控的全面性和有效性，如资源监控、业务指标监控的覆盖度是否全面等； 3. 检验业务告警触达的及时性、应急预案的有效性以及相关人员的应急处理能力。 在此次演练之前，乐元素已经对业务架构部署进行了全面优化，不仅完成了线上环境的全面容器化升级，还完成了双活改造，以确保系统在任一可用区或链路发生故障时，均具备可快速恢复的应急预案。 利用率高、内存利用率高、Pod删除、网络丢包、进程停止、进程杀死、网络乱序、网络延迟等故障演练场景 数据层 涉及多种数据库高可用演练，如验证主节点故障后，服务是否能自动切换，恢复时长是否符合预期等 3. 客户收益 乐元素在本次同城双活演练中，成功应对了一系列关键业务的容灾挑战，并对系统的整体可用性和可靠性进行了全面验证，达到演练目标。在此次演练中，客户主要取得了以下两方面收益： 1.
1K31编辑于 2024-03-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号