前文提到异地多活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库（MySQL）实现异地多活时要考虑的点。本文不讨论为什么做异地多活，可以参考末尾的文章。
当谈到架构的高可用时，无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是一天。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。
无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是12小时。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。
随着企业规模的扩大，对数据库可用性要求越来越高，更多企业采用两地三中心、异地多活的架构，以提高数据库的异常事件应对能力。 在数据库领域，我们常听的“两地三中心”、“异地多活”到底是什么呢？ “两地三中心”就是生产数据中心、同城灾备中心、异地灾备中心。这种模式下，两个地域的三个数据中心互联互通，当一个数据中心发生异常，其他数据中心可以正常运行并进行业务接管。 “异地多活”就是在多个地域建设多个数据中心， 业务数据能够在三个及以上的数据中心之间进行双向同步。异地多活架构具有更高的可用性，抗风险能力极强。 不
异地多活相对于异地热备，最大不同点在于应用在不同地域都承载流量，从业务流量调度，数据同步以及业务性能等方面技术复杂度会大幅度的提升。同时业务异地多活有一个前提，就是业务支持单元化部署，这里对存量有历史技术债业务也存在非常大的挑战。因此本篇幅讨论异地多活前提是，业务已经具备单元化部署的能力。
导读：《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第七部分，主要介绍异地多活，异地多活缩短了时延，提高可用性，但是带来复杂度和成本无疑是巨大的，不是一般公司可以承受的，只有在对可用性要求特别高的业务场景才建议使用。
随着业务对持续性要求越来越高，云上不少企业对跨AZ或多地域的容灾建设有强烈的诉求。当企业内部经过评估选定容灾建设整体方向，即同城双活；需要对方案进行验证，包括组件容灾能力建设，数据同步以及切换验证等。通常对组件容灾能力建设和验证会花费大量时间，如果测试不符合预期，对之前调研、部署以及测试人力和时间成本带来较大耗费。因此借助云平台能力“一站式”提升系统容灾能力，助力企业降本增效。
异地多活看字面意思 ：不通的地方部署服务。前段时间发生的B站挂掉的事情，网上众说纷纭，有的说是有机房着火了，导致服务宕机。那对于这种突发的情况，我们应该如何应对呢？包括说有些地方地震了导致机房宕机等等。
企业业务敏感程度差异，对容灾指标RPO&RTO要求也不同。之前两篇文章主要介绍数据冷备，主要特点是数据备份存储非实时，备份系统存储数据通常昨天的数据，当灾难真正来临的时候，今天新产生的数据会丢失情况。对于企业核心业务来讲，业务恢复（RTO）可以接受小时级别，但是对于数据无法接受丢失，即RPO接近为“零”。结合腾讯云数据备份能力，本文重点介绍数据热备解决方案，旨在让客户上好云，用好云，管好云。
2001年的“911事件”中，没有远程备份的企业都遭受了巨大损失，甚至部分公司因为核心业务部署在公司大楼而又没有远程备份，导致公司业务无法继续运营而倒闭。美国“911事件”后，全球用户提升了对灾备的重视程度，异地灾备建设一时成为趋势。
冷备或者主备并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。
最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。
最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。而异地双（多）活，却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类： 1、必须同步型。（比如数据库） 2、无须同步型。比如缓存，仅仅是当做缓存，就可以这样做（这个有待商榷，其实缓存也需要同步的，严格来说的话）。 3、只能单活（对全局原
去年写过一篇《做容灾，冷备是不是个好方案？》，当时提出来，冷备或者主备，其实并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里
MySQL技术专家，现任爱可生技术服务总监，负责MySQL数据库在传统行业客户的应用推广与技术咨询，曾为运营商、银行、证券、保险、航空等行业内数家大型企业提供MySQL技术咨询服务。
灾备： 是指容灾和备份。容灾是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务7*24小时连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。
来源：https://blog.dogchao.cn/?p=299 前言 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过 F5 或者任何代理
采用高可用系统架构支持重要系统，为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
孙伟：腾讯云高级技术工程师，主要负责腾讯云存储和中间件产品的技术支持专项工作。有8年以上的云存储技术支持、数据迁移和架构方案经验。曾任职于其他云友商公司，担任过研发、产品改进、售后等多项工作岗位。
点击上方蓝色“程序猿DD”，选择“设为星标” 回复“资源”获取独家整理的学习资料！ 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存，比如MySQL数据库，redis等内存数据库。除了这两种类型的维护方式，还有jvm的内存的状态维持，但jvm的状态生命周期通常很短。 高可用的一些解决方案 高可用，从发展来看，大致经过了这几个
很多产品发展到一定规模之后，可能会走出国门，技术架构要做到国际化。或者基于高可用 / 高性能的需求，需要做异地多活。
为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。
做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。
在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。
随着业务发展越来越快，数据量越来越多，用户也越来越多，业务出现故障的几率也越来越大，而可用性是衡量一个系统的关键指标，application 由于是无状态的，可用性很好保证，当一个应用挂掉，直接切到另一个即可，最关键的是数据库的高可用，则是最复杂的。
上篇文章讲到了Ceph在灾备方面有三大神兵利器：故障域、RBD异地灾备、RGW异地灾备。那么本文讲述下剩下的两大利器RBD异地灾备和RGW异地灾备
在软件开发领域，异地多活是分布式系统架构设计的一座高峰，很多人经常听到过他，但很少人理解其中的原理;
互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等，今天主要是一起聊下，多机房部署的灾备架构模式，来确保服务的高可用。
2022年6月，腾讯云Redis全新升级，发布高性能版本，单节点可提供50W+吞吐，性能是原生Redis的4倍。同时，腾讯云Redis推出全球复制功能，解决原生Redis诸多痛点问题，可用性升级高达99.999%，助力企业实现降本增效。 Redis作为全球最受欢迎的NoSQL数据库之一，凭借着极高的吞吐、极低的响应延迟和丰富的功能特性，成为企业在缓存场景中的首选方案。但在突发、热点访问及异地多活场景下，原生Redis方案会出现主从复制延迟、数据同步不连续、多地写入等问题，无法解决海量数据在规模、成本、数据
在互联网大厂，有个普遍的现象：某种程度上，只要是比较重要的系统，都需要考虑系统的容灾问题。
本文由公众号“水滴与银弹”号主Kaito原创分享，原题“搞懂异地多活，看这篇就够了”，为使文章更好理解，有修订。
本来这个公众号的交流消息中间件相关的技术的。这周去上海参加了QCon，第一次参加这样的技术会议，感受挺多的，所以整理一下自己的一些想法接公众号和大家交流一下。
在2021年2月7日，中国人民银行发布了《金融信息系统多活技术规范》，将其作为指导金融行业标准。可以说金融业关系国计民生，维护金融信息系统安全是国家信息安全的重点，因发生灾难导致金融服务中断，可能对企业内部管理、公民、法人和其他组织的金融权益甚至国家金融稳定和秩序产生影响。为规范和引导在金融信息系统合理运用多活技术实现业务承载和灾难恢复，有效防范金融信息系统风险，保护金融机构客户的合法权益，特编制这一标准。本文针对这一标准并结合外部实践经验进行探讨。
在这场天灾面前，人类能做的极其有限。失去的已经失去，能做的就是想好预防办法和灾后重建。相信借全国人民之手，众志成城，一定可以帮助河南度过此次难关。
说起容灾，很多同学脑子冒出来熟悉字眼，”同城双活”，“两地三中心”，“单元化”，“set化”等等。其实这些名词背后均隐射一层含义，面对一些灾难时候，业务如何做冗余来快速恢复业务。
依托于阿里云高速通道专线、事件总线EventBridge和MSHA（Multi-Site High Availability）多活容灾平台，消息队列RocketMQ版提供异地双活功能，通过跨实例间数据的双向同步和业务切流能力，实现业务恢复和故障恢复解耦，保障故障场景下的业务连续性。本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。
TiDB的存储用的TiKV, TiKV是基于RocksDB实现了分布式（可水平扩展，支持主从），RocksDB是对单机版LevelDB的封装。
腾讯云数据库【国产数据库专题线上技术沙龙】正在火热进行中，4月28日陈爱声的分享已经结束，没来得及参与的小伙伴不用担心，以下就是直播的视频和文字回顾。
总第249篇 2018年 第41篇 引言 在任何一家互联网公司，不管其主营业务是什么，都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产，它可以用来衡量业务指标，例如日活、月活、留存等，同时也给不同业务线提供了大量潜在用户，业务可以基于账号来做用户画像，制定各自的发展路径。因此，账号服务的重要性不言而喻，同时美团业务飞速发展，对账号业务的可用性要求也越来越高。本文将分享一些我们在高可用探索中的实践。 衡量一个系统的可用性有两个指标： 1. MTBF （Mean Time Between
同城异区两个机房距离一般就是几十千米，网络传输速度几乎和同一个机房相同，降低了系统复杂度、成本。
2、确保应用高可用性，消除计划外的停机时间，减少计划外的停机时间，提高业务连续性。
当前市场上常见的容灾模式可分为同城容灾、异地容灾、双活 数据中心、两地 三中心几种。
在当今互联网行业，大多数人互联网从业者对"单元化"、"异地多活"这些词汇已经耳熟能详。而数据同步是异地多活的基础，所有具备数据存储能力的组件如：数据库、缓存、MQ等，数据都可以进行同步，形成一个庞大而复杂的数据同步拓扑。
为了保障系统可用性， 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害， 发生的频率一次降低。
备注：当你再一个cluster钟使用了federation插件，所有在集群中的 nodes都需要安装federation插件
数据时代，企业对技术创新和服务水准的要求不断提高，数据已成为企业极其重要的资产，数据同步也成为企业数据开发和使用一个绕不过去的技术需求。那么，什么时候我们需要进行数据同步，甚至是实时同步呢？目前又有什么实时同步方案？
随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行。
在前几期，我们介绍了对象存储的对外接口规范、内部存储池分配以及快速根据标签查找到对象的实现。但是，这对于实现企业级和运营级SLA，还需要跨越一道鸿沟……
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
