双活&多活的高可用架构，以及伪双活的陷阱规避

近期收到客户关于 XGuard 产品异地双活部署的咨询。本文以此为契机，给大家深入浅出地介绍双活、多活以及假双活。欢迎大家提出宝贵意见。 双活架构（Active-Active） 双活架构指的是两个站点（或数据中心）同时处于活跃状态，共同处理业务流量和数据处理任务。 图 XGuard的双活架构 XGuard的双活是真正意义上的双活，同一个节点可以同时承担起所有对外访问的业务，可以做到真正的业务负载均衡同时故障可无缝切换，提升了整体对外服务能力，降低了客户运维成本。 假双活 假双活指的是表面上看起来是双活架构（两个站点同时运行），但实际上并未实现真正的双活特性（如数据一致性、故障自动切换、负载均衡等）。 假双活的典型特征 （1）主备模式伪装成双活 现象：两个站点同时运行，但只有一个站点真正处理业务流量，另一个站点仅作为热备，不承担负载。

高可用解决方案：同城双活？异地双活？异地多活？怎么实现？

高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。 异地双活 同城双活可以应对大部分的灾备情况，但是碰到大面积停电，或者自然灾害的时候，服务依然会中断。 所以大多数的互联网公司采用了异地双活的方案。 上图是一个简单的异地双活的示意图。 也就是说，在这个区域是不能进行双活的。采用主从而不是双写，自然解决了冲突的问题。 实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。

双活数据中心建设-网络&安全层双活设计

网络双活核心技术 网络双活核心技术分析： 网络层双活主要通过SDN技术实现网络自动化部署，通过VXLAN构建跨数据中心大二层网络、通过EVPN技术实现跨数据中心互联，三大技术相辅相成共同实现网络层双活 网络安全层技术 网络双活核心技术分析： 双活数据中心网络安全防护建议最新等级保护2.0相关要求部署相关的安全设备进行整体安全防护。

异地双活实践笔记

最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。 业务以及基础组件异地双活方案 业务实例异地双活 业务实例的异地双活。这个相对来说要简单一些，只要做到无状态，再如果通过docker这些容器结束，基本上是相对来说容易一些。 同步可以通过客户端双写，或者服务端复制。双写更加容易。 Redis的异地双活 Redis 的异地双活。就是分别在每个机房搭建一套Redis集群。 异步双活思维误区： 1、所有业务异地多活！ 中国银行业，只有某国有大行在去年6月份实现了上海同城两个数据中心的双活，是“同城双活”，还没有实现“异地多活”，而且在灾难真正发生时，切换效果如何，还有待验证。 　　

同城双活与异地多活架构分析

服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。 二、同城双活 同城双活是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制 ，保证高度的数据完整性和数据零丢失。 3、同城双活方案评估 优势 服务同城双活，数据同城灾备，同城不丢失数据情况下跨机房级别容灾。 同城双活和两地三中心建设方案建设复杂度都不高，两地三中心相比同城双活有效解决了异地数据灾备问题，但是依然不能解决同城双活存在的多处缺点，想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题 下图展示了RPC注册中心路由寻址过程，和同城双活有一定的差异性。

ES异地双活方案

解决了双机房ES"读"的问题，再来看“写”的问题，可能有同学说了，这还不简单，直接双写就行了吧，一份数据，向A、B机房的ES集群各写一份。 听想来貌似可行，但是有一些细节问题 ： 1、双写并非原子操作，如果A机房的ES集群写成功了，B机房的ES集群没写成功，该怎么办？ 2、当B机房的ES挂了，双写不进去时，过一段时间又恢复后，故障期间的数据，B机房的ES集群怎么补进去？如果手动事后补数据，虽然可行，但是毕竟麻烦。 当然，这个方案的提前是MQ本身是高可用的，不过这个不难做到，已经有一些rocket mq双机房多活的案例，不在本文讨论范围，大家可以自行搜索。

双活数据中心建设-存储层双活设计（part-1）

存储层双活本质上是HyperMetro通过数据双写和DCL机制实现存储层数据的双活，两个数据中心同时对主机提供数据读写的能力。（即2端存储做集群、数据双写、数据一致性回滚）。 数据双写机制：应用服务器下发I/O请求时，可同时下发到本端Cache和远端Cache，从而保证本端Cache与远端Cache的变更数据一致性。 同时双活可以通过另一端存储系统的数据，对坏数据进行修复，保证两个数据中心的数据一致。

双活数据中心建设-应用层双活设计（part-1）

根据应用的工作模式来划分将应用分为B/S类（浏览器/服务器模式）、C/S类（客户端/服务器模式）。

【Android 进程保活】应用进程拉活 ( 双进程守护保活 )

文章目录 一、 双进程守护保活原理 二、 双进程守护保活完整源码 1、AIDL 接口 2、本地前台服务 Service 3、远程前台服务 Service 4、清单配置 5、启动两个服务 5、执行效果 三、 源码资源 一、 双进程守护保活原理 ---- 双进程守护拉活 , 使用 JobScheduler 拉活 和 系统 Service 机制拉活 两种拉活方式 , 结合起来使用 ; 双进程机制拉活 , 比之前的 广播拉活 , 系统 Service 机制拉活 , 账户同步拉活 , JobScheduler 机制拉活 , 成功率都要高 , 可靠性比较高 , 但是也存在失败的情况 ; JobScheduler / 通信内容 } } " 本地前台进程 " LocalForegroundService 在 onCreate 方法中开启前台服务 , 提权 , 参考 【Android 进程保活】 android.permission.FOREGROUND_SERVICE 权限 : <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> 二、 双进程守护保活完整源码

双活数据中心建设-应用层双活设计（part-2）

在B/S应用中的双活设计一般考虑三个层次，分别是WEB层、APP层、DB层。 在APP层和DB层就需要部署跨数据中心集群软件，从而实现应用层双活。 数据库主要和应用服务器对接，数据库双活一般都是AA的，也可以是AS。

双活、异地多活架构怎么设计才不翻车？

双活：两个机房都在干活，就像左右手一起工作，任何一个出问题，另一个都能立即顶上。 多活：多个机房同时提供服务，流量按规则分配，是双活的升级版。 2.2 多活架构分类 这张图清晰地展示了不同多活架构的特点。同城双活就像在同一个小区的不同栋楼里放设备，网络延迟很小；而异地多活则像在不同城市开分公司，距离远了但覆盖面更广。 3. 同城双活架构设计 同城双活是多活架构的入门款，相对来说比较好实现，也是很多公司的首选。就像学游泳要从浅水区开始一样。 3.3 数据同步方案 数据同步是同城双活的关键，主要有以下几种方案： 这个时序图说明了两种主要的数据同步模式。 主从同步就像一个人说话，另一个人过一会儿重复；而双主同步则像两个人同时说话，需要协调好时机。 4. 异地多活架构设计 异地多活是多活架构的高级版本，复杂度会有质的提升。

使用ChatGPT实现同城双活部署

前言今天老板让我写一篇腾讯云云原生的微服务项目部署实践，还要实现同城双活。 听说ChatGPT已经“出圈”了，无所不能，还可以帮人写文章，刚好最近比较懒，看看他能否帮我写完这篇实践，并教会我实现同城双活部署。 图片同城双活改造基础资源的部署，可能对ChatGPT来说有些简单，接下来，给他一些挑战，给我们提供一个应用层的跨区高可用方案。 我们希望只用一套TKE集群实现同城双活，最大程度的节约成本。 从接入层、应用层到数据层，快速地搭建出云上同城双活架构，从而避免单可用区故障，可能导致的访问中断。Excellent！

TCM同城双活设计方案

基于TKE集群本身的健康检查机制等，保证了进程的高可用 TCM详细资料参考：https://cloud.tencent.com/document/product/1261/62928 架构设计方案 同城双活需求分析 使用了TCM产品，只需要考虑数据面的高可用建设，即业务程序的同城双活。 这种架构模式下，有两个技术点需要解决： 接入层的流量负载均衡 逻辑层的set部署，即可用区内流量闭环 设计方案 适合上面同城双活的集群部署模式，如下图一、图二所示。 图二 建设要求 一个服务网格+一个TKE集群 一个服务网格+两个TKE集群 部署模式 承载双活业务的

关于 Oracle 存储双活配置和实战

跨数据中心双活的，它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡和高可用性。 IO 性能做严格的测试，标准的 Oracle 双活方案架构如下。 2Oracle 存储双活安装配置 安装部署存储双活，需要至少6快盘，详细磁盘规划需求如下： AA 机房 BB 机房 仲裁 ZC 机房 任何机房均可 aaocr 盘 bbocr 盘 zcocr 盘 tmpocr Oracle 双活存储方案和存储厂商的双活方案（如 EMC 的 Vplex）对比有更大的灵活性，透明性，因为底层的存储磁盘对于 Oracle 来说完全可见，而且通过 Oracle 的 Normal 磁盘组的功能实现 无论是 Oracle 的双活存储还是存储厂商的双活解决方案，均适用于两个存储机房距离小于 50 公里的情况，而且最大的瓶颈在于远端的存储节点写入速度，因此在部署双活存储方案时，提前做好底层的磁盘写入速度测试

关于 Oracle 存储双活配置和实战

跨数据中心双活的，它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡和高可用性。 IO 性能做严格的测试，标准的 Oracle 双活方案架构如下。 2Oracle 存储双活安装配置 安装部署存储双活，需要至少6快盘，详细磁盘规划需求如下： AA 机房 BB 机房 仲裁 ZC 机房 任何机房均可 aaocr 盘 bbocr 盘 zcocr 盘 tmpocr Oracle 双活存储方案和存储厂商的双活方案（如 EMC 的 Vplex）对比有更大的灵活性，透明性，因为底层的存储磁盘对于 Oracle 来说完全可见，而且通过 Oracle 的 Normal 磁盘组的功能实现 无论是 Oracle 的双活存储还是存储厂商的双活解决方案，均适用于两个存储机房距离小于 50 公里的情况，而且最大的瓶颈在于远端的存储节点写入速度，因此在部署双活存储方案时，提前做好底层的磁盘写入速度测试

图解M-LAG双活故障场景

做容灾，双活、多活、同城、异地、多云，到底应该怎么选？

而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。 准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。 就以淘宝、天猫为例，按照之前了解的情况，基本也是杭州和上海这两个城市为主做双活，再远时延这个问题就绕不开了。 所以，打算搞双活，先从这里下手，当然牵出来就要涉及到分布式，还有很多大量细节技术问题。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。

做容灾，双活、多活、同城、异地、多云，到底应该怎么选？

而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。 下面我就谈谈我的理解： 首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。 准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。 就以淘宝、天猫为例，按照之前了解的情况，基本也是杭州和上海这两个城市为主做双活，再远时延这个问题就绕不开了。 所以，打算搞双活，先从这里下手，当然牵出来就要涉及到分布式，还有很多大量细节技术问题。 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。

双活数据中心解决方案剖析

今天来和大家聊聊双活数据中心解决方案，双活方案中2个数据中心站点之间均为双活特性，在双活数据中心中2个中心同时处于运行状态，同时承担生产业务，可大幅提升整体服务能力和资源利用率。 由于华为公司的产品线相当齐全，华为双活数据中心方案中可以做到6层端到端双活从而大大提升了双活数据中心的业务上线速度。目前在双活数据中心中有2类双活形态即AA双活和AP双活。 该方案在现网中也有很多应用但是假双活并非我们部署双活数据中心的真正目的，笔者也不看好AP形式的双活数据中心。 华为双活数据中心解决方案中采用AA双活以HM特性（存储双活特性）为基础同时结合其他计算和网络组件，组合起来为用户提供双活解决方案。 华为双活数据中心解决方案以以上6层双活实现端到端双活，该方案具有故障点少系统可靠性高的特点。

​业务双活的数据切换思路设计（下）

这是学习笔记的第 2132 篇文章 前几天写了一篇关于业务双活的数据切换思路设计，我今天把下半部分补充一下。 业务双活的数据切换思路设计（上） 首先整个业务的上游是流量入口，分为读流量和写流量，整体是分布式设计。 ? 而“已有数据服务”的写流量照样是写入，这样就达到了一种“理想”的双写状态。 ?