2001年的“911事件”中，没有远程备份的企业都遭受了巨大损失，甚至部分公司因为核心业务部署在公司大楼而又没有远程备份，导致公司业务无法继续运营而倒闭。美国“911事件”后，全球用户提升了对灾备的重视程度，异地灾备建设一时成为趋势。
当前，市场上常见的容灾模式可分为本地容灾、同城容灾、异地容灾、双活数据中心、两地三中心几种。
数据中心运行突发故障(如：天灾不可避免的灾难)是无法预测的，计算机里的数据就像扫雷游戏一样，十面埋伏充满雷区，随时都有可能Game Over，容灾备份就是数据安全的最后防线，但是你可以避免由数据中心发生故障而丢失数据引发的数据丢失的局面。
当前，市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中心、两地三中心几种。
国际标准SHARE 78将容灾系统定义成七个层次，这七个层次对应的容灾方案在功能、适用范围等方面都有所不同，所以用户选型应分清层次。
灾备： 是指容灾和备份。容灾是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务7*24小时连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。
为了保障系统可用性， 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害， 发生的频率一次降低。
容灾半径是衡量容灾方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的，而距离也会影响到容灾技术的选择。容灾中心的架构按照源备端之间的距离，可分为本地容灾、同城双活、两地三中心。
在互联网大厂，有个普遍的现象：某种程度上，只要是比较重要的系统，都需要考虑系统的容灾问题。
容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。
当前市场上常见的容灾模式可分为同城容灾、异地容灾、双活 数据中心、两地 三中心几种。
接着上篇《做容灾，双活、多活、同城、异地、多云，到底应该怎么选？》，这篇聊聊公有云上应该如何建容灾，跟我们自建机房有什么区别，没看过的同学，建议先从上篇文章看一下。
Zookeeper 我想大家都不陌生，在很多场合都听到它的名字。它是 Apache 的一个顶级项目，为分布式应用提供一致性高性能协调服务。可以用来做：配置维护、域名服务、分布式锁等。有很多开源组件，尤其是中间件领域，使用 Zookeeper 作为配置中心或者注册中心。例如，它是 Hadoop 和 HBase 的重要组件，是 Kafka 的管理和协调服务，是 Dubbo 等服务框架的注册中心等。
Zookeeper 我想大家都不陌生，在很多场合都听到它的名字。它是 Apache 的一个顶级项目，为分布式应用提供一致性高性能协调服务。可以用来做：配置维护、域名服务、分布式锁等。有很多开源组件，尤其是中间件领域，使用 Zookeeper 作为配置中心或者注册中心。它是 Hadoop 和 HBase 的重要组件，是 Kafka 的管理和协调服务，是 Dubbo 等服务框架的注册中心等。
冷备或者主备并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。
对于金融企业来说，尤其是银行、证券、保险这些行业，在一个 IT 系统运行支撑业务的过程当中，考虑到硬件的故障、网络的故障，等一切可能会对业务产生影响的突发故障。那么，在过去漫长的 IT 发展的过程当中，大量的技术被应用在关于如何解决组件级的高可用，整个服务的容灾和灾备，包括如何保证整体业务的连续性。
去年写过一篇《做容灾，冷备是不是个好方案？》，当时提出来，冷备或者主备，其实并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。
灾难备份是指为了减少灾难发生的概率，以及减少灾难发生时或发生后造成的损失而采取的各种防范措施。
如上图，两地三中心的架构，是为了提高系统的容错、容灾的能力。当一个数据中心不可用时，能够将关键业务的流量切换到其他数据中心，可以抵御城市级的自然灾害。
采用高可用系统架构支持重要系统，为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
本文介绍了蚂蚁金服异地多活单元化架构的原理，以及微服务体系在此架构下的关键技术实现。
异地多活看字面意思 ：不通的地方部署服务。前段时间发生的B站挂掉的事情，网上众说纷纭，有的说是有机房着火了，导致服务宕机。那对于这种突发的情况，我们应该如何应对呢？包括说有些地方地震了导致机房宕机等等。
热备的情况下，只有主数据中心承担用户的业务，此时备数据中心对主数据中心进行实时的备份，当主数据中心挂掉以后，备数据中心可以自动接管主数据中心的业务，用户的业务不会中断，所以也感觉不到数据中心的切换。
说起容灾，很多同学脑子冒出来熟悉字眼，”同城双活”，“两地三中心”，“单元化”，“set化”等等。其实这些名词背后均隐射一层含义，面对一些灾难时候，业务如何做冗余来快速恢复业务。
相对于过去单体或 SOA 架构，建设微服务架构所依赖的组件发生了改变，因此分析与设计高可用容灾架构方案的思路也随之改变，本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行。
支付宝的会员ID系统采用OceanBase“三地五中心”部署方式，建立了城市级故障自动容灾能力。
OpenStack已经成为一种趋势，但发行版OpenStack尚不完美，企业要建成私有云必须预先充分了解发行版OpenStack的缺点，并寻求专业OpenStack提供商的帮助与合作，才能扬长避短，真正发挥OpenStack的优势，建成最大化企业竞争优势的私有云。
在云时代，大部分中小型企业都奔跑在云上或是服务器托管公司。任何规模的数据中心服务中断都会让你的企业踩雷。据统计，80%的数据中心服务中断都是由服务器硬件造成的。
依托于阿里云高速通道专线、事件总线EventBridge和MSHA（Multi-Site High Availability）多活容灾平台，消息队列RocketMQ版提供异地双活功能，通过跨实例间数据的双向同步和业务切流能力，实现业务恢复和故障恢复解耦，保障故障场景下的业务连续性。本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。
互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等，今天主要是一起聊下，多机房部署的灾备架构模式，来确保服务的高可用。
随着业务对持续性要求越来越高，云上不少企业对跨AZ或多地域的容灾建设有强烈的诉求。当企业内部经过评估选定容灾建设整体方向，即同城双活；需要对方案进行验证，包括组件容灾能力建设，数据同步以及切换验证等。通常对组件容灾能力建设和验证会花费大量时间，如果测试不符合预期，对之前调研、部署以及测试人力和时间成本带来较大耗费。因此借助云平台能力“一站式”提升系统容灾能力，助力企业降本增效。
越来越多的企业在数字化转型和上云进程中选择混合云的形态（云+自建 IDC 或云+其他厂商云）来进行容灾建设，一方面不会过度依赖单一云厂商，另一方面还能充分利用已有的线下 IDC 资源。
你知道吗？自然灾害、设备故障、人为因素等都会造成业务中断。如今数字化时代，IT系统故障更会对公司业务造成难以估量的巨大经济损失。
灾备，是企业中一项重要的技术应用，对于企业数据安全起到了很大的作用。 一般来说，灾备的级别可以分为数据级、应用级和业务级三个级别。
一年前，中国还笼罩在疫情的阴影之下。 全国各地相继沦陷，感染人数与日俱增。面对未知的病毒，骤然间，举国禁足闭户，生产暂时停摆。 北京，中国的首都。 由于是政治经济交通枢纽，随着各种人员的往来出入，初期疫情逐渐蔓延，有些社区防疫措施也不尽完善，出入证、登记表、核酸检测，每次进出都要花时间登记，填写，费时费力。 同时，复工复产又成了另一个亟需解决的任务，被逐渐提上日程。 如何才能在有效控制疫情的情况下，尽快让这座沉寂的城市焕发生机，安全有序地复工复产呢？ “北京健康宝”诞生了。 北京健康宝”是一个方便个人查
2022年8月25日，杭州市数据资源管理局发布《2022年8月政府采购意向》公告。 项目名称：杭州市政务云容灾备份项目 采购需求： 1、同城应用级容灾备份 在杭州市已有云资源生产中心基础上，新购买1个可独立承担关键系统运行的云资源容灾中心服务，双中心具备基本同等业务处理能力，并通过高速链路实现数据实时同步和业务流量分担，生产中心灾难发生时可进行应急切换容灾中心，保障业务连续运行和数据不丢失。目标将29个重要应用系统分别部署到两中心，在不改变现有业务架构的情况下，充分利用现有政务云能力实现同城应用级容灾备
同城双中心+异地灾备中心， “两地三中心”的灾备模式，方案兼具高可用性和灾难备份的能力。
容灾（Disaster Tolerance）：就是在上述的灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。
数据库作为企业数据的管理软件，是企业的核心资产，需要避免单点灾难，因此数据库灾备需求应运而生。
网络属于基础设施部分，网络容灾建设作为一个数据中心验收重要指标。试想一个数据中心的网络链路存在单点，就如一个城市道路都是单行道，一旦出现交通事故，小则导致道路拥堵，大则导致整个城市交通瘫痪。IDC时代，业务对网络容灾参与较少，主要依赖数据中心网络容灾建设程度；当到了云的时代，云服务商将底层网络能力产品化后，云上客户更多参与网络容灾建设，提升业务稳定性。本文从云网络概述，云网络容灾复杂度以及典型案例来介绍云网络容灾建设。
在上一期《数据掘金者》中，主要介绍的是有别于传统日志的腾讯专有云日志平台。本期给大家带来是专有云中不可或缺的保险机制——容灾管理系统。
企鹅电竞登录鉴权系统是企鹅电竞电竞所有写请求的前置关键路径，需要具备高可靠性。其核心存储依靠 CMEM，为保证服务的稳定运行，搭建一套同构 CMEM 存储，热备 Login 数据，在 CMEM 发生存储或网络故障时保证登录鉴权服务正常运行。
今天跟大家分享的题目为《CKV+异地容灾探索和实践》。CKV+是一个兼容redis协议的内存数据库，现在大部分用户对内存数据库的要求越来越高，对一致性、异地容灾等方面也提出更高的要求。下面从过往经验教训、可用性&一致性、CKV+架构演进、CKV+单活多可用区和CKV+多活架构探索等方面跟分享一些关于容灾的实践和思考。
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里
腾讯云Status Page（Tencent Cloud Health Dashborad ），作为腾讯云官方的产品可用信息对外窗口，需要保障在极端的故障情形下，还能及时且正确地对外呈现关键信息，这要求在架构设计和部署上做到多地域级别的容灾效果。为了达到目标，我们除实施针对性的架构设计和部署外，还对各类故障场景做了故障演练验证。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
