前文提到异地多活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库（MySQL）实现异地多活时要考虑的点。本文不讨论为什么做异地多活，可以参考末尾的文章。
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里
采用高可用系统架构支持重要系统，为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
来源：https://blog.dogchao.cn/?p=299 前言 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过 F5 或者任何代理
点击上方蓝色“程序猿DD”，选择“设为星标” 回复“资源”获取独家整理的学习资料！ 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存，比如MySQL数据库，redis等内存数据库。除了这两种类型的维护方式，还有jvm的内存的状态维持，但jvm的状态生命周期通常很短。 高可用的一些解决方案 高可用，从发展来看，大致经过了这几个
异地多活看字面意思 ：不通的地方部署服务。前段时间发生的B站挂掉的事情，网上众说纷纭，有的说是有机房着火了，导致服务宕机。那对于这种突发的情况，我们应该如何应对呢？包括说有些地方地震了导致机房宕机等等。
随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行。
在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。
最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。而异地双（多）活，却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类： 1、必须同步型。（比如数据库） 2、无须同步型。比如缓存，仅仅是当做缓存，就可以这样做（这个有待商榷，其实缓存也需要同步的，严格来说的话）。 3、只能单活（对全局原
相对于过去单体或 SOA 架构，建设微服务架构所依赖的组件发生了改变，因此分析与设计高可用容灾架构方案的思路也随之改变，本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
本文由公众号“水滴与银弹”号主Kaito原创分享，原题“搞懂异地多活，看这篇就够了”，为使文章更好理解，有修订。
在软件开发领域，异地多活是分布式系统架构设计的一座高峰，很多人经常听到过他，但很少人理解其中的原理;
我很喜欢的一句话和大家分享一下：很多模式是不能直接复制的。当数量级直线上升的时候，其背后的难度是几何增长的。
多活成本比较高的，双活是两倍，三活可能成本会低一些，但三活的难度更大。因此没有办法对所有业务进行多活，只能对主线做多活。
本来这个公众号的交流消息中间件相关的技术的。这周去上海参加了QCon，第一次参加这样的技术会议，感受挺多的，所以整理一下自己的一些想法接公众号和大家交流一下。
互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等，今天主要是一起聊下，多机房部署的灾备架构模式，来确保服务的高可用。
越来越多的企业在数字化转型和上云进程中选择混合云的形态（云+自建 IDC 或云+其他厂商云）来进行容灾建设，一方面不会过度依赖单一云厂商，另一方面还能充分利用已有的线下 IDC 资源。
依托于阿里云高速通道专线、事件总线EventBridge和MSHA（Multi-Site High Availability）多活容灾平台，消息队列RocketMQ版提供异地双活功能，通过跨实例间数据的双向同步和业务切流能力，实现业务恢复和故障恢复解耦，保障故障场景下的业务连续性。本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。
采访嘉宾 | 金思宇、陈贞宝、胡强忠 编辑 | 辛晓亮 大型电商系统并非一开始就具有完整设计的高可用特性，而是随着用户的不断增加与业务的快速增长逐步演进与完善的。当前高可用架构体系是互联网企业系统架构的基础要求，随着公司的业务发展，尤其是对于电商平台，每次发生稳定性故障带来的影响越来越大，提供稳定的服务，保证系统的高可用已经变成了整个技术团队需要面对的挑战。 基于此，我们深度采访了得物技术团队核心成员，探索他们在高可用架构上的实践、演进，深入了解大促备战是如何进行的，异地多活体系是如何建设的，全链路
当前，市场上常见的容灾模式可分为本地容灾、同城容灾、异地容灾、双活数据中心、两地三中心几种。
同城双中心+异地灾备中心， “两地三中心”的灾备模式，方案兼具高可用性和灾难备份的能力。
今天和同事聊了下两地三中心的一些理解，后续会在MySQL和Redis方向的高可用架构方案上做一些东西。这算是一个讨论的开始吧。
当前，市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中心、两地三中心几种。
灾备： 是指容灾和备份。容灾是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务7*24小时连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。
随着医疗、大型企业行业上云步伐的加快，上云后的业务系统安全性如何保障成为客户关注的重点。对于医疗、大型企业客户，往往建有自己的数据中心，如何保障极端情况下业务系统的稳定运行？双活、灾备，能帮到我们！
说起容灾，很多同学脑子冒出来熟悉字眼，”同城双活”，“两地三中心”，“单元化”，“set化”等等。其实这些名词背后均隐射一层含义，面对一些灾难时候，业务如何做冗余来快速恢复业务。
做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。
冷备或者主备并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。
互联网公司发展到一定的规模，系统的高可用就变得极其重要。为了应对那些随时可能发生的意外，“多活”在如今互联网公司好像变得是必备的手段了。甚至一些公司发生一些 P0 事故之后，多活也会出现在 case study 的列表之内。
备注：当你再一个cluster钟使用了federation插件，所有在集群中的 nodes都需要安装federation插件
颜值高的，点上面！ 随着业务量的不断上升，呼叫中心已经从单纯的大容量单中心逐渐向多地多中心演化，在这种架构下，多地呼叫中心的统一协作成为整合资源、提升可用性、提高效率的重要手段。目前大容量呼叫中心主要
去年写过一篇《做容灾，冷备是不是个好方案？》，当时提出来，冷备或者主备，其实并不是一个理想的方案，而且绝大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。
本文根据吉翔老师在〖deeplus直播：甩掉技术债包袱，B站的SRE体系建设与转型实践〗线上分享演讲内容整理而成。
在异地多活项目整体推过程中的一些注意事项和设计点归纳和整理，抛砖引玉，其中一些点还有待深入探讨和优化。
为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。
接着上篇《做容灾，双活、多活、同城、异地、多云，到底应该怎么选？》，这篇聊聊公有云上应该如何建容灾，跟我们自建机房有什么区别，没看过的同学，建议先从上篇文章看一下。
当谈到架构的高可用时，无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是一天。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。
你知道吗？自然灾害、设备故障、人为因素等都会造成业务中断。如今数字化时代，IT系统故障更会对公司业务造成难以估量的巨大经济损失。
所谓Shovel就是我们可以把消息进行不同数据中心的复制工作，可以跨地域的让两个mq集群互联。
数据库作为企业数据的管理软件，是企业的核心资产，需要避免单点灾难，因此数据库灾备需求应运而生。
无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是12小时。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。
RabbitMQ集群架构模式 主备模式 实现RabbitMQ的高可用集群，一般在并发和数据量不高的情况下，这种模型非常的好用且简单。主备模式也称为Warren模式 HaProxy配置 listen rabbitmq_cluster bind 0.0.0.0:5672 # 配置TCP模式 mode tcp #简单的轮询 balance roundrobin #主节点 server bhz76 192.168.11.76:5672 check inter 5000 rise 2 fall 3 server bh
摘要：vSAN延伸集群的出现，不仅使VMware有了自己的存储双活技术，从成本角度来看，更使存储双活这项技术，从“天上”来到了“民间”。 通过vSAN延伸集群加上VMware已有的SRM和VR技术，一个全新的、高效低成本的两地三中心方案应运而生。 上一篇《VMware的灾备与双活----我在vForum 2015分会场的分享（1）》介绍了VMware灾备技术SRM，作为姊妹篇，本次将介绍VMware双活技术。 目前市场上常见的硬件厂商的双活方案通常指的是分布式存储双活，如EMC vPlex, HDS
2023腾讯全球数字生态大会已于9月7-8日完美落幕，40+专场活动展示了腾讯最新的前沿技术、核心产品、解决方案。
以上就是mysql两种事务类型，希望对大家有所帮助。更多mysql学习指路：Mysql
近日，互联港湾携手网银互联再次打造双活数据中心，分别将北京铁通IDC—T3中心和杭州下沙MDC数据中心作为合作机房，在全国布局上又添一笔，进一步实现南北互通。 传统灾备系统通常采取IOE架构，通过数据库的数据复制或存储的数据复制技术，在广域网上实现数据的复制，具有很强的通用性。但这种数据层面的备份强调的是数据安全，可能产生很大的RPO和RTO值，即丢失大量数据或灾难恢复时间过长，给企业造成巨大损失。因此，尽管投入了大量的日常维护成本，但为了避免数据丢失，企业只有在万不得已的情
自 2008 年双 11 以来，在每年双 11 超大规模流量的冲击上，蚂蚁金服都会不断突破现有技术的极限。2010 年双 11 的支付峰值为 2 万笔/分钟，到 2017 年双 11 时这个数字变为了 25.6 万笔/秒。
2001年的“911事件”中，没有远程备份的企业都遭受了巨大损失，甚至部分公司因为核心业务部署在公司大楼而又没有远程备份，导致公司业务无法继续运营而倒闭。美国“911事件”后，全球用户提升了对灾备的重视程度，异地灾备建设一时成为趋势。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
