- 综合排序
- 最热优先
- 最新优先
- 来自专栏开元说说
容灾系列（八）——同城数据冷备容灾建设
为了让企业能更好用好云平台的数据安全能力，本文重点云平台数据备份冷备能力，以腾讯云为例，主要从以下两个维度介绍：同城数据冷备能解决企业什么问题，达到怎么样业务容灾效果？ 同城数据冷备方案2.1 同城冷备平台能力介绍 同城数据冷备，云平台主要提供以下几个能力：备份安全级别为地域粒度，例如广州一共有3个可用区，其中一个可用区不可用，不会对数据备份造成危险，只有这三个可用去完全不可用时 ，对现有业务架构没有任何改造，方案架构如下：图片该方案核心要点说明：数据备份：云侧数据库mysql和redis在控制台设置数据备份参数，数据备份存储在COS，具备地域级别容灾，RPO依赖于数据库备份周期以及时间 本文小结同城冷备方案，在云平台的协助下，企业几乎0成本并拥有同城数据冷备能力来保障业务生命线。指标详细说明容灾能力具备同地域（不同可用区）数据备份能力，不具备不同地域的能力。 3.容灾演练能力建设，增加平时运维成本以及自动化工具开发功能。
8.5K113编辑于 2022-09-15 - 来自专栏数通
同城容灾和异地容灾的区别，你知道多少？
同城双活的数据同步 同城双活数据中心通常在几十公里距离内，通过高质量、低延迟的专用网络线路（如光纤专线） 连接。这种低延迟网络允许采用同步或半同步的数据复制方式。 共享存储或数据库主从模式 单元化架构（按用户/业务分片） 成本 专线成本较高，但存储配置可能更简单 异步复制带宽成本相对较低，但架构复杂度和改造成本高 主要优势 高可用、数据零丢失（RPO=0）、故障切换迅速 城市级容灾 、更好的用户体验（异地用户就近访问） 主要挑战 距离限制（同城）、脑裂风险、专线成本 数据延迟、一致性难度、架构复杂性 如何选择 选择同城还是异地双活，需综合考量： 1、业务需求与数据一致性要求：若业务要求数据强一致性 （如核心交易系统），同城双活更合适。 2、容灾等级要求：同城双活可应对机房级故障。若需防范城市级灾难（如地震、大规模停电），则需异地双活。 3、成本预算：同城双活专线成本较高，但架构相对简单。
51010编辑于 2025-10-11 - 来自专栏深度学习与python
同城容灾+异地多活是全球化容灾处理的最好模式吗？
字节容灾架构的演进路径 容灾整体的演进过程与大家所理解的基本一致。我们从单一机房开始，逐步发展到同城双机房，再到同城的多个机房。随着业务的快速发展以及部署需求的调整，我们进一步演进到异地多活模式。 与同城容灾不同，异地容灾会有一个选择过程：先判断同城资源，如果同城资源不够，再考虑区域间的容灾策略。 字节海外容灾 由于海外业务的特殊性，我们的容灾架构首先采用了异地模式，然后发展成为异地加同城的双重容灾模式。 因此，在海外，先同城后异地不一定是最佳默认策略，我们可以考虑利用海外的天然特点，例如时区来做容灾的第一判断依据，根据事故发生时的时区特点来决策，第一优先级是同城容灾，或者是异地切流，因为容量是我们容灾首要考虑的因素 在国内容灾和海外容灾方面，我们目前都在采用同城容灾加异地多活的模式，并且我们正在持续不断地完善整体的容灾能力建设。
1.3K10编辑于 2024-07-26 - 来自专栏腾讯云中间件专家服务
客户容灾案例—zookeeper容灾迁移方案
在至少有一个Leader存在的前提下，进行Zookeeper的在线增量、在线减量、在线迁移 在全过程中ZooKeeper不停止服务
2.4K51发布于 2021-07-26 - 来自专栏开元说说
容灾系列（六）——数据存储容灾建设
数据存储容灾建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢？
4.9K73发布于 2021-11-18 - 来自专栏SRE运维实践
同城异地灾备
序言 同城异地灾备，主要是用来进行备份容灾的，从而当一个数据中心挂了，另外一个数据中心经过切换之后，能让服务迅速的恢复。 同城双活，则是基于多机房的情况下，流量经过双机房，一个机房挂掉，完全不影响业务。 随着业务的进一步发展，需要提供高可用水平，从而需要从单机房扩展为多机房，从而也就有了同城容灾。。。 对于运维来说，多一次升级，多一次变更，就会多一个故障，多一个锅。。。 热升级了解一下，不可预知的中断了解一下 同城异地最关键的点在于存储，存储如何跨机房使用，从而分为几个方面进行探讨： 1、 DNS解析 在业务大量使用DNS解耦的时候，而且使用双机房的时候
5.3K31发布于 2019-07-08 - 来自专栏云容灾云灾备
什么是云容灾？与传统容灾灾备有何不同？
云容灾不仅提供数据备份功能，还结合计算、存储、网络等云服务能力，允许企业在云端快速部署容灾环境，并进行自动化业务恢复。二、传统容灾 vs. 云容灾在云容灾出现之前，企业通常采用传统容灾方案，如自建异地灾备中心或租用灾备机房。 相比之下，云容灾基于云计算技术，充分利用云平台的弹性和智能化能力，提供了一种更灵活、高效的灾备解决方案：对比项传统容灾云容灾基础设施自建或租用物理灾备中心依赖云服务，无需额外硬件成本投入高昂的硬件、机房 当业务负载增加时，容灾环境可以根据需求自动扩展计算能力，实现无缝升级。此外，云容灾还支持按需付费，避免了传统灾备方案中资源闲置的问题。3. 自动化灾备演练（Automated Disaster Recovery Testing）传统容灾演练通常需要人工干预，操作复杂且成本高昂，而云容灾可支持自动化灾备演练，不影响生产业务。
54110编辑于 2025-08-06 - 来自专栏开元说说
容灾系列（三）——云网络容灾建设
IDC时代，业务对网络容灾参与较少，主要依赖数据中心网络容灾建设程度；当到了云的时代，云服务商将底层网络能力产品化后，云上客户更多参与网络容灾建设，提升业务稳定性。 以腾讯云为例，在同地域选择机房地址的时候，距离大于60公里，要求不同可用区延时小于3ms，来满足云上客户同城容灾建设基本需求。 1.2 云网络产品 对于云上网络产品，从业务流量维度主要分为： 流量走向 对应产品 容灾建设 南北向流量 负载均衡(CLB)、NAT网关、弹性公网IP（EIP）、anycast IP 1.同城多活，避免跨可用区的流量 2.网络容灾复杂度 同城或者异地容灾建设，网络层面因素主要有三个： 1）跨区或者跨地域网络延时，对上层业务影响。 网络延时，通过优化基础设施手段是非常有限的，毕竟受限于实际物理距离和光速。 image.png 3.2 混合云网络容灾 混合云网络容灾分为两个部分： 1）idc和云机房之间线路容灾，主要线路分为专线和VPN。
6.1K93发布于 2021-08-09 - 来自专栏Forrest随想录
做容灾，双活、多活、同城、异地、多云，到底应该怎么选？
去年写过一篇《做容灾，冷备是不是个好方案？》，当时提出来，冷备或者主备，其实并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。 最近，公有云又出了些大故障，各大群和朋友圈又开始沸沸扬扬，但是整体看下来，声音无非两种： 单站点不靠谱，要有容灾，出现这种情况就得马上切，所以回去赶紧建设容灾站点； 鸡蛋不能放在一个篮子里，单云不靠谱， 既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。 我们可以得出的几个结论： 不管怎么选择容灾方案，我们自己的业务系统，从自身架构上，一定要支持单元化，一定要支持数据同步才行，如果这都不支持，讲双活和多活，就是特么的扯淡。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
3.5K41发布于 2019-03-18 - 来自专栏云计算文章
容灾的架构分析和容灾选择策略
1.传统容灾中心的架构 容灾半径是衡量容灾方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的，而距离也会影响到容灾技术的选择。 容灾中心的架构按照源备端之间的距离，可分为本地容灾、同城双活、两地三中心。 1.1本地容灾 本地容灾一般指主机集群，当某台主机出现故障，不能正常工作时，其他的主机可以替代该主机，继续正常对外提供服务。 1.2同城双活 同城双活属于本地容灾，但根据运营模式可以分为主备和双活两种形式： 主备模式即生产中心正常对外提供服务时，同步将数据单项复制到备端数据中心，且备端不对外提供服务。 远端的备份机房能更大的提供灾备能力，能更好的抵抗地震，恐袭等情况。双活的机器必须部署到同城，距离更远的城市作为灾备机房。 2.容灾级别与能力 容灾系统按保护级别可分为：数据级容灾、应用级容灾、业务级容灾。
4.1K30编辑于 2022-04-29 - 来自专栏开元说说
容灾系列（九）——异地数据冷备容灾建设
异地数据备份挑战相对同城数据备份，异地数据冷备主要挑战是成本，主要是跨地域之数据传输带宽成本。 对于同城数据备份，对企业来说“零”成本，企业可以把所有数据都进行备份；而跨地域数据备份，需要对业务进行梳理，尤其数据量比较大的业务，来决策哪些业务需要异地数据备份。 如果涉及到一个库只需要同步其中几张表，可能还会涉及到业务改造；由此可见相当于“零”成本，“零”投入同城数据备份而言，异地数据备份会带来一些复杂度。2. 2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案，具备实时增量备份以及快速的数据恢复能力，同时具备异地容灾能力。
10.8K164编辑于 2022-09-19 - 来自专栏纯洁的微笑
做容灾，双活、多活、同城、异地、多云，到底应该怎么选？
冷备或者主备并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。 原因我就不重复了，大家如果有兴趣可以直接看那篇文章。 最近，公有云又出了些大故障，各大群和朋友圈又开始沸沸扬扬，但是整体看下来，声音无非两种： 单站点不靠谱，要有容灾，出现这种情况就得马上切，所以回去赶紧建设容灾站点； 鸡蛋不能放在一个篮子里，单云不靠谱， 既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。 我们可以得出的几个结论： 不管怎么选择容灾方案，我们自己的业务系统，从自身架构上，一定要支持单元化，一定要支持数据同步才行，如果这都不支持，讲双活和多活，就是特么的扯淡。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
3.4K31发布于 2019-06-03 灾备知识总结：容灾与备份区别、灾备技术、容灾体系规划
灾难恢复（Disaster Recovery）阶段定位：灾难发生后的系统重建与容灾关系：现代容灾系统集成恢复功能二、容灾与备份的协同关系1. 功能互补性2. 典型故障应对案例1：数据库误删操作容灾系统同步删除→需从备份恢复案例2：机房级火灾容灾系统接管业务→备份用于数据追溯三、企业灾备体系规划策略1. 风险评估矩阵2. 典型建设路径初级阶段：本地备份+双机热备（中科热备HA方案）进阶阶段：同城双活+异地备份成熟阶段：多云容灾+区块链存证四、灾备技术体系详解1. 医疗行业应用三甲医院HIS系统：容灾中心部署中科热备CDP技术实现诊疗业务零中断切换3. 建议企业根据业务特性选择"备份+容灾+恢复"的三维防护策略，定期开展灾备演练，真正实现业务连续性保障。
1K10编辑于 2025-09-16- 来自专栏民工哥技术之路
灾备知识总结：容灾与备份区别、灾备技术、容灾体系规划
容灾系统在企业中给与数据安全系数相当高的保障，但是容灾系统倒是是什么，他们是什么意思？恐怕连正在使用容灾备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释容灾备份到底是什么。 容灾不可少 那么建设了备份系统，是否就不需要容灾备份系统？ 容灾不能替换备份 容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的 用户信息表也会被完整地删除。 如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份，来恢复被错误删除的信息。 备份系统＋异地容灾系统 这是一个较为理想化的容灾系统一体化解决方案，能够在很大程度上避免各种可能的错误。 容灾恢复等级 ? 灾难恢复层次 ? 灾备技术层次 ? 1.1 磁盘阵列灾备技术 ?
13.7K21发布于 2021-01-12 - 来自专栏开元说说
容灾系列（七）——混合云公网出口容灾建设
本文结合云平台公网能力，从网络平台角度来分析容灾建设可行性。 2.公网出口容灾方案 2.1 IDC和云平台出口互为主备 正常情况下，IDC和云平台公网出口流量是烟囱式，互不交叉；当IDC公网出口异常，流量切换到云平台，同样云平台公网出口异常，流量切换到IDC。 整体公网出口容灾方案如下： image.png 2.1.1 云平台切换方案。 正常情况下，业务流量通过NAT访问公网，如上路绿色线条标识。 2.1.2 IDC容灾切换方案 正常情况下，IDC业务流量通过NAT访问公网，如上路绿色线条标识。 IDC公网出口容灾方案 (推荐) 1.方案简单，更多依赖云平台能力 2.方案落地快捷。 3.人力成本低，不需要自建系统。 4.维护成本低，不需要后续维护系统稳定性。
4.4K124编辑于 2021-12-29 - 来自专栏开元说说
容灾系列（四）——业务应用层容灾建设
综上所述，本文从云平台视角出发阐述应用层业务容灾建设，主要分为方案设计考虑纬度、复杂度以及云上客户案例三个方面。 1.应用容灾概述 1.1 应用部署 应用是否满足跨地域/可用区部署？ 应用层调用链是否能接受跨区延时，如果业务无法接受跨区，该业务做容灾只能set化部署，这里需要强大中间件团队开发数据同步系统。 应用层调用链能接受跨区延时，一般以试点业务先观察，小步迭代方式逐步构建容灾能力。 容灾切换强依赖于调度系统以及配置系统稳定性。这里稳定性主要包括系统容灾能力和性能；遇到大规模故障，大量信息配置变更请求调度系统和配置系统要能扛住洪峰，是保障这个容灾方案的根基。 2.应用容灾复杂度 计算应用层容灾，主要考虑以下两个方面： 哪些节点执行任务。 这里要区分清楚哪些节点执行核心业务，这里会引入不同的复杂度。
4.5K72发布于 2021-09-04 - 来自专栏开发者
「腾讯云顾问GameDay实践」如何有效进行同城双活容灾验证
GameDay目标：验证业务同城双活容灾架构的有效性 Step 1.使用云顾问绘制业务云上架构图（图1） Step 2.使用云顾问-混沌演练实施故障注入（图2） 场景1：CLB健康检查可用性验证 结论：
33010编辑于 2025-06-09 - 来自专栏ICT售前新说
容灾知识知多少
为什么要做容灾？ 你知道吗？自然灾害、设备故障、人为因素等都会造成业务中断。如今数字化时代，IT系统故障更会对公司业务造成难以估量的巨大经济损失。 容灾体系介绍 1 数据中心 集团公司通过两地建立三个数据中心，通过双活、冷备等方式，实现两地三中心容灾架构。 2 体系建设 系统类型 --- 容灾策略 核心业务系统 --- 两地三活 关键平台系统 --- 同城双活 非关键系统 --- 异地冷备 3 技术方案 异地冷备 恢复能力 RTP≤1h RPO≤5min 选取异地数据中心搭建灾备环境，通过公司统一平台工具实现应用配置同步，生产库与同城库可进行实时同步，同城库与异地灾备库可进行异步同步。 容灾演习要求 每年进行容灾演练，所有核心业务与平台系统均要参演。 异地灾备恢复、同城双活切换、一键式自动化启停等恢复方式不断创新，要求演习规模逐年扩大和恢复效率逐年提升。 - End - ----
1.9K20发布于 2021-04-30 - 来自专栏采云轩
前端接口容灾
容我细细细细分析。 原因就是接口挂了，拿不到数据了。那把数据储存起来就可以解决问题。 思考 存哪里? 第一时间反应浏览器本地存储，想起了四兄弟。 接口容灾我们也是刚弄不久，有许多细节与不足，欢迎沟通交流。 接口容灾本意是预防发生接口服务挂了的场景，我们不会很被动。原来是P0的故障，能被它降低为 P2、P3，甚至在某些场景下都不会有用户反馈。
99310编辑于 2023-11-30 - 来自专栏开元说说
容灾系列（十）——数据热备容灾能力建设【基础篇】
异地明确数据热备容灾能力，实时明确RPO指标接近于“零”。尤其是实时，对于RPO指标提升，为此需要企业投入更多的成本。 2）灾备实例，建议采用云平台的PAAS服务，更好的兼容DTS同步服务。2.2 平台热备方案2.2.1 数据库灾备方案目前数据库对于异地容灾备份能力进行封装，来简化云上客户操作成本，提升RTO。 2.2.3 中间见实时备份方案ckafka云平台在数据同步已支持跨地域容灾，但是对于ckafka版本有要求，为专业版本。 方案关键因素详细说明容灾范围地域级别容灾RPO/RTORPO几乎接近为零；RTO为小时级别，进行1:1业务部署，依赖于业务部署和数据恢复自动化能力。 3.容灾演练能力建设，增加平时运维成本以及自动化工具开发功能。
6.1K143编辑于 2022-09-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号