服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。...架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。...三、两地三中心架构 所谓两地三中心是指 同城双中心 + 异地灾备中心。...架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。...同城双活和两地三中心建设方案建设复杂度都不高，两地三中心相比同城双活有效解决了异地数据灾备问题，但是依然不能解决同城双活存在的多处缺点，想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题
image.png 理论上讲，上面这种结构是可行的，但实际应用中，要考虑的因素会更多： 1、1个机房变3个机房，这成本就得翻好几倍了，回想一下mysql之类的解决方案，master-slave架构顶多放...2、如果3个机房分属异地，比如：上海、广州、北京，三个城市间数据传输必然增加延时，要降低延时一般是拉专线，这样一方面成本还会继续增加，而且这么长距离传输，网络抖动是难免的，抖动期间，会增加选举"误切换"...解决了双机房ES"读"的问题，再来看“写”的问题，可能有同学说了，这还不简单，直接双写就行了吧，一份数据，向A、B机房的ES集群各写一份。...听想来貌似可行，但是有一些细节问题 ： 1、双写并非原子操作，如果A机房的ES集群写成功了，B机房的ES集群没写成功，该怎么办？...当然，这个方案的提前是MQ本身是高可用的，不过这个不难做到，已经有一些rocket mq双机房多活的案例，不在本文讨论范围，大家可以自行搜索。
高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。...所以大多数的互联网公司采用了异地双活的方案。 上图是一个简单的异地双活的示意图。...实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。...因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 根据异地双活的思路，我们可以画出异地多活的一种示意图。每个节点的出度和入度都是4，在这种情况下，任何节点下线都不会对业务有影响。...按照业务进行单元切分，已经需要对代码和架构进行彻底的改造了（可能这也是为什么阿里要先从双活再切到多活，历时3年）。比如，业务拆分，依赖拆分，网状改星状，分布式事务，缓存失效等。
最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。...业务以及基础组件异地双活方案 业务实例异地双活 业务实例的异地双活。这个相对来说要简单一些，只要做到无状态，再如果通过docker这些容器结束，基本上是相对来说容易一些。...同步可以通过客户端双写，或者服务端复制。双写更加容易。 Redis的异地双活 Redis 的异地双活。就是分别在每个机房搭建一套Redis集群。...，同时为了提升用户体验，整个机房的架构为双A，两边均可写，由此诞生了otter这样一个产品。...，延迟的问题会彻底放大； 3 、跨机房的专线很大概率会出问题，要做好运维或者程序层面的容错； 4 、不能依赖MySQL双写，必须有适应自身业务的跨机房消息同步方案； 5 、MySQL或者其他存储的数据同步问题
异地多活的代价： 系统复杂度会有质的变化。 成本大大增加。 架构模式 1. 同城异区 部署在同一个城市不同区的机房，用专用网络连接。...这就出事儿了，所以这类数据不会做跨城异地多活，只能用同城异区架构，因为同城的网络环境要好很多，可以搭建多条互联通道，成本也不会太高。...保证核心业务的异地多活 思维误区：要保证所有业务都能异地多活。...存储系统本身就有强大的同步功能，例如 mysql redis 都可以很好的实现同步，但某些场景下是无法满足需要的，所以要使用多种手段配合，例如： 消息队列 创建账号后，将账号数据通过消息队列同步到其他业务中心...内容整理自《从0开始学架构》
应用场景 顾名思义，异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动...单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？...其实不然，因为实现异地多活架构不是没有代价的，相反其代价很高，具体表现为： 系统复杂度会发生质的变化，需要设计复杂的异地多活架构。...架构模式 根据地理位置上的距离来划分，异地多活架构可以分为同城异区、跨城异地、跨国异地。接下来我详细解释一下每一种架构的细节与优缺点。...基于这个分析，跨城异地多活是架构设计复杂度最高的一种，接下来将介绍跨城异地多活架构设计的一些技巧 技巧1：保证核心业务的异地多活 “异地多活”是为了保证业务的高可用，但很多架构师在考虑这个“业务”时
分布式系统架构-----异地多活架构 背景 最近公司在搞异地多活，特来写篇文章来学习和回顾一下。 异地多活看字面意思 ：不通的地方部署服务。...这些自然灾害我们是不可避免的所以我们得从架构层面解决这种突发问题。 异地多活架构 1. 什么是异地多活架构？ 异地：不同的地理位置，多活：不同的地理位置的服务都能独立提供服务。...大概服务的物理架构图如下： 从上面架构图可知： mysql 采用主从机制 redis 使用两个集群，通过双写实时同步 quee采用的主备用 job 和 服务就是两个异地集群 遇到的问题 服务数据一致性问题...启动好后数据一致性问题： 因为还有就是数据库mysql的数据是实时在变化的所有这个时候redis的数据和mysql的数据就会有可能不一致，通过架构图可知。...我们是通过双写redis达到的，虽然redis也有自己的同步机制，但是出于性能考虑采用业务层中间件实现双写。 也就是说15集群写redsi的数据也同时会写入16集群，16集群的数据也会写入15集群。
如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。 今天我来聊聊异地多活架构，以及异地多活架构的设计技巧和流程。...单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？...架构模式 根据地理位置上的距离来划分，异地多活架构可以分为同城异区、跨城异地、跨国异地。接下来我详细解释一下每一种架构的细节与优缺点。...设计跨城异地多活架构 我们讲完了异地多活设计的核心要点，下面我们谈一下如何设计跨城异地多活架构。...总结 今天我们谈了异地多活架构的应用场景和常见架构模式，结合CAP、BASE等理论讲了异地多活的设计技巧，并详细讲述了如何设计异地多活架构，希望对你有所帮助。
---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地多活 系统可用性 让我们从最基础的开始往上垒。...---- 异地双活 按照上面的思路，只要把 “同城双活” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗？ 因为是异地，两个机房之间的专线也将升级为 跨域专线 了。...这时候就不能再采取原先的 “主从架构”了，因为两地的服务器都要提供读写功能，且要保持数据的一致性。 MySQL 本身就提供了双主架构，它支持双向复制数据，但平时用的并不多。...例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。 == 双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。...== ---- 异地多活 理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。 什么是异地双活 多活容灾MSHA是在阿⾥巴巴电商业务环境演进出来的多活容灾架构解决⽅案，可以将业务恢复和故障恢复解耦。...异地双活功能不仅解决了容灾本身问题，还提升了业务连续性，并且实现了资源的异地扩展。 消息队列RocketMQ版的异地双活具体实现如下： 杭州单元和上海单元分别部署了一套完整的业务系统。...使用限制 实例类型限制：异地双活功能仅企业铂金版实例支持，标准版实例不支持。...计费说明 异地双活为消息队列RocketMQ版的高级功能。若您开通了异地双活功能，消息队列RocketMQ版会按照包年包月方式进行收费；未开通则不收取异地双活功能费用。...功能优势 可用性 和传统容灾方案相比，异地双活方案中所有生产中心数据实现双向同步，并且均可对外提供服务，各中心分担业务流量，提高了资源使用率。 故障快速恢复 异地双活功能够有效保障业务连续性。
MirrorMaker2架构 01 MM V2的核心架构基于Kafka Connect框架，可以抽象的理解为是一个Kafka Connect 里的Source Connector和Sink Connector...这样Topic命名过程会导致在Active – Active双活时造成无限的消息循环。
而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。...准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。...既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。...我们可以得出的几个结论： 不管怎么选择容灾方案，我们自己的业务系统，从自身架构上，一定要支持单元化，一定要支持数据同步才行，如果这都不支持，讲双活和多活，就是特么的扯淡。...一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里、腾讯、百度、网易、新浪等等都已经完成了异地多活的技术重构。...所以大多数的互联网公司采用了异地双活的方案： 图 3：简单的异地双活示意图 上图是一个简单的异地双活的示意图。...实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover 等操作即可。 但其实双活只是一个临时的步骤，最终的目的是切换到多活。...因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 图 4：异地多活的示意图 根据异地双活的思路，我们可以画出异地多活的一种示意图。.../eleme-arch 《阿里异地多活与同城双活的架构演进》 https://www.sohu.com/a/158859741_444159 《阿里云 数据库异地多活解决方案》 https://help.aliyun.com
高可用 1、高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。...所以大多数的互联网公司采用了异地双活的方案。 图3 简单的异地双活示意图 上图是一个简单的异地双活的示意图。...实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。...因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 图4 异地多活的示意图 根据异地双活的思路，我们可以画出异地多活的一种示意图。...淘宝的解决方式和我们切分微服务的方式有点类似： 淘宝按照单元切分的异地多活架构 注意看图中的数据同步箭头。
所以，要想真正的抵御城市级别的故障，越来越多的互联网公司，开始实施「异地双活」。09 伪异地多活这里，我们还是分析 2 个机房的架构情况。...如果还是按照同城双活的架构来部署，那异地双活的架构就是这样的：图片注意看，两个机房的网络是通过「跨城专线」连通的。...看到了么，虽然我们只是简单的把机房部署在了「异地」，但「同城双活」的架构模型，在这里就不适用了，还是按照这种方式部署，这是「伪异地双活」！那如何做到真正的异地双活呢？...怎么实现这种「双主」架构呢？它们之间如何互相同步数据？如果你对 MySQL 有所了解，MySQL 本身就提供了双主架构，它支持双向复制数据，但平时用的并不多。...12 异地多活理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
随着业务量的不断上升，呼叫中心已经从单纯的大容量单中心逐渐向多地多中心演化，在这种架构下，多地呼叫中心的统一协作成为整合资源、提升可用性、提高效率的重要手段。...在此基础之上，通过系统级的异地双活，可以更好地保障业务服务连续性，保证系统在灾难场景下的可用性，实现跨地域的容灾能力，减少单地域灾难带来的影响。 ?...1 技术介绍 呼叫中心异地双活功能基于携程联络中心呼叫中心、统一登录平台来实现，可以提供包括计划内冗灾切换（按系统、按城市区域、按技能组）、计划外冗灾切换（覆盖PBX故障、CTI故障、统一登录故障）。...3 技术特点 支持故障情况下在线座席的自动双活切换、计划内维护的手工切换； 支持按系统、按地域、按座席技能组等不同维度进行计划内的手工切换； 支持1000+在线座席异地双活自动切换； ?...4 拓展 结合携程呼叫中心CTI平台网呼功能上线和统一登录平台整合，异地双活功能可以实现PBX、CTI、统一登录的云端管理，真正实现四海一家，使座席不再按地域划分，一点接入，服务全球。
跨机房的作用是为了备份，一个机房的数据放在另一个机房是异地多活。上面是数据容灾，下面的是业务容灾，第三个是让服务离用户最近。这是荔枝 FM 做跨机房的原因。 做过数据备份的各位一定知道CAP理论。...比如MySQL Cluster集群，内部还是可以用的，MySQL集群提供两阶段提交事务方式，保证各节点数据强一致性。...MySQL的集群无法忍受脱离集群独立工作，一旦和集群脱离了心跳，节点出问题，导致分布式事务操作到那个节点后，整个就会失败，这是MySQL的牺牲。 CP模型，一致性+分区容忍，牺牲了可用性。...最麻烦的是老链问题，两头是活的，中间链断了，南北之间IDC链路，不管是专线还是公网都有可能会抽风，心跳检测出问题后，两边会独立写。DS代理认为这边服挂了，Slave认为主挂了，直接把数据往这边写。...分享人：刘耀华，荔枝FM架构师，负责荔枝FM服务端系统架构设计与实施，以及数据中心异地多活方案的设计。对服务端系统架构进行分布式集群、高可用、负载均衡等有多年经验与心得。
异地多活是近几年比较热门的一种系统架构。一般来讲，要做到异地多活，是一个系统性的事情，需要接入层、应用层、数据层都做一些事情。...同时有一些场合我们可能会把两地三中心等容灾架构也算作了异地多活（单纯的应用层多活），本文所讲的异地多活，是指所有数据中心的数据库都会承担写流量的"真·异地多活"。...今天我们这篇文章重点来说一下，对于一个分布式数据库，在异地多活架构中，起到了一个什么样的角色；对于其中的问题，解法是什么。...因此我们依然要遵循异地多活架构下应用本身需要做流量的分区的原则，确保数据库的请求不会高频率的飘来飘去。...总结 异地多活，是一个非常吸引人的架构。真正的实现异地多活，对系统的整体设计是一个很大的挑战，涉及的领域方方面面。选择合适的数据库层方案，能让整个过程事半功倍。
为了保障业务稳定不间断运行，我们构建了JDHBase集群的异地多活系统。主要介绍在我们在异地多活系统的实践。...JDHBase异地多活架构 JDHBase服务端与客户端交互主要包含三个组件：Client、JDHBase集群、Fox Manager。...数据持久化目前为可选的Mysql或Zookeeper。...我们对可靠性要求比较高的业务做了异地多活备份。 ? Active Cluster：正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster，同时保证数据不丢失，但是会有延迟。...PolicyServer 是对外提供查询和修改策略的服务，它所有策略数据会存储在MySQL中。可以通过加节点的方式动态扩展形成一个服务集群，避免单点问题。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
