image.png 理论上讲，上面这种结构是可行的，但实际应用中，要考虑的因素会更多： 1、1个机房变3个机房，这成本就得翻好几倍了，回想一下mysql之类的解决方案，master-slave架构顶多放...2、如果3个机房分属异地，比如：上海、广州、北京，三个城市间数据传输必然增加延时，要降低延时一般是拉专线，这样一方面成本还会继续增加，而且这么长距离传输，网络抖动是难免的，抖动期间，会增加选举"误切换"...解决了双机房ES"读"的问题，再来看“写”的问题，可能有同学说了，这还不简单，直接双写就行了吧，一份数据，向A、B机房的ES集群各写一份。...听想来貌似可行，但是有一些细节问题 ： 1、双写并非原子操作，如果A机房的ES集群写成功了，B机房的ES集群没写成功，该怎么办？...当然，这个方案的提前是MQ本身是高可用的，不过这个不难做到，已经有一些rocket mq双机房多活的案例，不在本文讨论范围，大家可以自行搜索。
高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。...其他的高可用方案还可以参考各类数据库的多种部署模式，比如mysql的主从、双主多从、MHA；redis的主从，哨兵，cluster等等。 同城双活 前面讲到的几种方案，基本都是在一个局域网内进行的。...所以大多数的互联网公司采用了异地双活的方案。 上图是一个简单的异地双活的示意图。...实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。...因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 根据异地双活的思路，我们可以画出异地多活的一种示意图。每个节点的出度和入度都是4，在这种情况下，任何节点下线都不会对业务有影响。
最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。...业务以及基础组件异地双活方案 业务实例异地双活 业务实例的异地双活。这个相对来说要简单一些，只要做到无状态，再如果通过docker这些容器结束，基本上是相对来说容易一些。...同步可以通过客户端双写，或者服务端复制。双写更加容易。 Redis的异地双活 Redis 的异地双活。就是分别在每个机房搭建一套Redis集群。...异步双活思维误区： 1、所有业务异地多活！...，延迟的问题会彻底放大； 3 、跨机房的专线很大概率会出问题，要做好运维或者程序层面的容错； 4 、不能依赖MySQL双写，必须有适应自身业务的跨机房消息同步方案； 5 、MySQL或者其他存储的数据同步问题
服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。...2、数据双活 MySQL：采用MHA部署方案，主从半同步方案保证数据一致性。读写分离、读就近路由到机房内数据节点、写路由到master节点所在机房。...架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。...架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。...同城双活和两地三中心建设方案建设复杂度都不高，两地三中心相比同城双活有效解决了异地数据灾备问题，但是依然不能解决同城双活存在的多处缺点，想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题
本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。 什么是异地双活 多活容灾MSHA是在阿⾥巴巴电商业务环境演进出来的多活容灾架构解决⽅案，可以将业务恢复和故障恢复解耦。...异地双活功能不仅解决了容灾本身问题，还提升了业务连续性，并且实现了资源的异地扩展。 消息队列RocketMQ版的异地双活具体实现如下： 杭州单元和上海单元分别部署了一套完整的业务系统。...使用限制 实例类型限制：异地双活功能仅企业铂金版实例支持，标准版实例不支持。...计费说明 异地双活为消息队列RocketMQ版的高级功能。若您开通了异地双活功能，消息队列RocketMQ版会按照包年包月方式进行收费；未开通则不收取异地双活功能费用。...功能优势 可用性 和传统容灾方案相比，异地双活方案中所有生产中心数据实现双向同步，并且均可对外提供服务，各中心分担业务流量，提高了资源使用率。 故障快速恢复 异地双活功能够有效保障业务连续性。
这样Topic命名过程会导致在Active – Active双活时造成无限的消息循环。
而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。...准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。...既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。...一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。...现实情况，比我写的要复杂的多的多，推荐大家看两个成功案例，一个是毕玄的异地多活数据中心，一个是饿了么异地多活，几个关键字google一下就有了，里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助
保证核心业务的异地多活 思维误区：要保证所有业务都能异地多活。...解决的方法就是：优先实现核心业务的异地多活。...存储系统本身就有强大的同步功能，例如 mysql redis 都可以很好的实现同步，但某些场景下是无法满足需要的，所以要使用多种手段配合，例如： 消息队列 创建账号后，将账号数据通过消息队列同步到其他业务中心...只保证绝大部分用户的异地多活 思维误区：要保证业务 100% 可用。 物理规律决定了异地多活无法保证100%的业务可用。...所以，无法做到实时转账的异地多活，需要通过特殊业务受到实现。
以MySQL为例，MySQL 5.1版本的复制是单线程的复制，在网络抖动或者大量数据同步时，经常发生延迟较长的问题，短则延迟十几秒，长则可能达到十几分钟。...而且即使我们通过监控的手段知道了MySQL同步时延较长，也难以采取什么措施，只能干等。...MySQL同步这种方式作为备份。...这样针对用户账号数据同步，系统就有两种同步方式：MySQL主从同步和消息队列同步。...例如，双同步通道有可能同时出现故障、日志记录方案本身日志也可能丢失。因此，无论多么完美的方案，故障的场景下总是可能有一小部分用户业务上出问题，系统无法弥补这部分用户的损失。
前面我们讲了同城双活，那异地双活是不是直接「照搬」同城双活的模式去部署就可以了呢？事情没你想的那么简单。...看到了么，虽然我们只是简单的把机房部署在了「异地」，但「同城双活」的架构模型，在这里就不适用了，还是按照这种方式部署，这是「伪异地双活」！那如何做到真正的异地双活呢？...怎么实现这种「双主」架构呢？它们之间如何互相同步数据？如果你对 MySQL 有所了解，MySQL 本身就提供了双主架构，它支持双向复制数据，但平时用的并不多。...12 异地多活理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。...值得提醒你的是，只有真正理解了「异地双活」，才能彻底理解「异地多活」。
在此基础之上，通过系统级的异地双活，可以更好地保障业务服务连续性，保证系统在灾难场景下的可用性，实现跨地域的容灾能力，减少单地域灾难带来的影响。 ?...1 技术介绍 呼叫中心异地双活功能基于携程联络中心呼叫中心、统一登录平台来实现，可以提供包括计划内冗灾切换（按系统、按城市区域、按技能组）、计划外冗灾切换（覆盖PBX故障、CTI故障、统一登录故障）。...，则向异地统一登录重新发起登录请求。...3 技术特点 支持故障情况下在线座席的自动双活切换、计划内维护的手工切换； 支持按系统、按地域、按座席技能组等不同维度进行计划内的手工切换； 支持1000+在线座席异地双活自动切换； ?...4 拓展 结合携程呼叫中心CTI平台网呼功能上线和统一登录平台整合，异地双活功能可以实现PBX、CTI、统一登录的云端管理，真正实现四海一家，使座席不再按地域划分，一点接入，服务全球。
为了保障业务稳定不间断运行，我们构建了JDHBase集群的异地多活系统。主要介绍在我们在异地多活系统的实践。...JDHBase异地多活架构 JDHBase服务端与客户端交互主要包含三个组件：Client、JDHBase集群、Fox Manager。...数据持久化目前为可选的Mysql或Zookeeper。...我们对可靠性要求比较高的业务做了异地多活备份。 ? Active Cluster：正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster，同时保证数据不丢失，但是会有延迟。...PolicyServer 是对外提供查询和修改策略的服务，它所有策略数据会存储在MySQL中。可以通过加节点的方式动态扩展形成一个服务集群，避免单点问题。
为了做到真正的数据异地多活，实现MySQL同机房就近读写，机房故障时无需进行数据库DR操作，只进行流量切换，就需要引入数据实时双向（多向）复制组件。 ?...Replicate Center）是携程框架架构研发部推出的用于数据双向或多向复制的数据库中间件，在公司G2（高品质Great Service、全球化Globalization）战略的背景下，服务于异地多活项目...MySQL 5.6.5版本新增了一种基于GTID的复制方式，强化了数据库的主备一致性，故障恢复以及容错能力，取代传统的基于file和position主从复制，使得在MySQL主备切换时，仍能准确定位到Binlog...1）网络层 Replicator采用GTID复制方式，实现了MySQL复制协议，伪装成源MySQL的Slave拉取Binlog。...针对网络故障，Replicator对MySQL添加了读空闲检测，启动时设置MySQL空闲时间隔10s发送一次heartbeat_event，如果30s没有收到MySQL任何事件，则认为MySQL出现问题
---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地多活 系统可用性 让我们从最基础的开始往上垒。...---- 异地双活 按照上面的思路，只要把 “同城双活” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗？ 因为是异地，两个机房之间的专线也将升级为 跨域专线 了。...MySQL 本身就提供了双主架构，它支持双向复制数据，但平时用的并不多。而 Redis、MongoDB 等数据库并没有提供这个功能，所以，你必须开发对应的「数据同步中间件」来实现双向同步的功能。...例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。 == 双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。...== ---- 异地多活 理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
或者基于高可用 / 高性能的需求，需要做异地多活。...异地多活容灾 很多巨型互联网产品发展到一定规模之后，其可用性往往造成很大经济损失，比如微信，支付宝这些用户规模巨大的产品，如果可用性有一点的降级，都会对大规模的用户影响，所以微信，支付宝这些产品早已做了异地多活...传统灾备方案 传统数据中心的灾备方案，一般是同城两个互备数据中心，异地建设一个灾备中心，三个数据中心平时只能一个提供在线服务，故障时将业务流量切到其他数据中心。
数据库的集群架构都不陌生了，最熟悉也是应用最广泛的就是咱们熟知的主从，今天大概的回味下： 主从复制 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。...则不需要这么高的数据安全，完全可以将sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率 3、使用比主库更好的硬件设备作为slave 4、使用mysql5.7...参看 《MySQL 5.7 并行复制实现原理与调优》 5、分库分表 http://www.cnblogs.com/hackxhao/p/5496254.html 这两篇文章写的很好，需要好好拜读！！
网络双活核心技术 网络双活核心技术分析： 网络层双活主要通过SDN技术实现网络自动化部署，通过VXLAN构建跨数据中心大二层网络、通过EVPN技术实现跨数据中心互联，三大技术相辅相成共同实现网络层双活...网络安全层技术 网络双活核心技术分析： 双活数据中心网络安全防护建议最新等级保护2.0相关要求部署相关的安全设备进行整体安全防护。
高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。...其他的高可用方案还可以参考各类数据库的多种部署模式，比如 MySQL 的主从、双主多从、MHA；Redis 的主从，哨兵，Cluster 等等。...所以大多数的互联网公司采用了异地双活的方案： 图 3：简单的异地双活示意图 上图是一个简单的异地双活的示意图。...实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover 等操作即可。 但其实双活只是一个临时的步骤，最终的目的是切换到多活。...因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。 异地多活 图 4：异地多活的示意图 根据异地双活的思路，我们可以画出异地多活的一种示意图。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
