当下，随着数字化技术不断深入，愈来愈多企业将核心业务搬到线上。业务系统高可用、可扩展、容灾能力决定企业系统的连续性，中间件作为构建企业核心系统的重要组成部分，其高可用容灾能力也将决定应用系统的。本文结合腾讯云中间件各PaaS产品的容灾能力及实践，以一个行业头部客户业务容灾实践举例，来展开说明基于腾讯云中间件PaaS层相关产品的实践。

下面就分别对Ckafka、ES、Redis云产品在客户业务容灾场景中的相关案例。

Ckafka的容灾能力可以分为：跨可用区容灾及跨地域级容灾。

Ckafka跨可用区容灾

跨可用区容灾：指的是在同一个地域内部，一个Ckafka集群节点跨可用区部署，作为一个大集群。这个跨可用区部署大集群的方式是原生kafka所推荐支持的。可以大幅度提升集群的容灾能力，当单个可用区出现意外的网络不稳定、断电重启等不可抗力风险 时，仍能保证客户端在短时间等待重连后恢复消息的生产和消费。

同步迁移模式：

• 同步模式操作步骤：在腾讯云消息队列 CKafka 控制台，创建 CKafka 实例，并创建对应 Topic。
• 客户侧生产者继续将数据写入到自建kafka实例。
• 下载、安装并且搭建mirror-maker客户端。
• 配置mirror-maker生产&消费properties文件。
• 启动mirror-maker，开始执行消息数据同步操作。检查数据同步是否正常，如果出现异常，需要检查下相关配置文件。
• 修改kafka客户侧，根据某个时间点启动新的消费。

ES跨可用区容灾

ES的容灾部署模式可以分为：大集群节点跨区部署、跨区复制CCR 2种模式。

大集群节点跨区部署

ES集群包含多个节点，可以将这些节点跨区部署，结合ES主分片&副本分片切换的特性，可以实现当某个主分片挂了情况下，能将副本分片提升为主分片继续对外提供服务。

跨区部署说明：

• ES跨可用区集群：实例采用4个数据节点组成，其中：4区2个，6区2个节点。
• 专用主节点：在每个可用区部署一个专用主节点，从而保障任何一个可用区不可用时，依然能够选出 Master节点，确保整个集群的稳定。

高可用说明：

• VIP实现跨可用区(AZ)访问能力，ES具有故障跨可用区漂移能力。当4区与6区网络出现中断，部署在4区的应用可访问6区ES点。
• 当4、6区任意一个可用区出现故障：如果有一个可用区挂掉，如广州4区整体不可用，ES的Master节点依然可用，会将广州4区的节点剔除并且将广州6区各节点上副本分配提升为主分片，同时VIP会将6区的RS剔除掉，这样4区应用就不会请求到6区节点上了，这样整个集群依然能够对外提供服务，并且对客户侧是无感知的。当故障恢复之后，分片会自动均衡到2个可用区，整个集群自行恢复。
• 当4、6区之间网络抖动、断开之后：通过VIP切换，客户端可正常对ES集群上各节点进行读写。此时因为4区到6区的网络出现抖动等异常情况时： 1）如果Master在4区，Master会将6区节点剔除，留下4区节点，将4区上的副本分片提升为主分片，整体正常对外提供服务。整个过程小于3秒，采用重试规避。 2）如果Master在6区，Master会将4区节点剔除，留下6区节点，将6区上的副本分片提升为主分片，整体正常对外提供服务。整个过程小于3秒，采用重试规避。3. 如果网络恢复正常之后，分片会自动均衡到2个可用区，并且开始执行主分片与副分片数据同步。

CCR 跨区复制模式：

高可用部署说明

• 当四区不可用时，进行容灾切换，业务流量切换到六区1、 断开CCR同步2、 六区切换为普通单实例集群 3、业务手动将所有流量切换到六区(修改DNS等)。
• 当四区恢复后，建立CCR从六区同步数据到四区，六区成为主集群、四区为副集群1、清空四区集群索引2、配置CCR主从同步：数据从六区主集群通过CCR复制到四区副集群。
• 回切四区为主集群1、 断开CCR同步，由于此时数据还继续写入六区，这部分数据会丢失，无法同步到四区2、 四区改为普通单实例集群3、业务手动将所有流量切换到六区，会产生业务中断。

ES大集群部署及CCR跨区复制部署优劣比对

自建ES上云迁移方案

操作步骤

1. 腾讯云ES版本需要大于等于客户自建ES集群的版本。
2. 例如客户ES版本是6.5.1，则云上的ES版本最好是6.8.2。
3. 创建云上ES集群的VPC选择自建集群所在的VPC。
4. 腾讯云ES版本选择基础版或者开源版，白金版暂不支持(如果自建ES集群也是白金版可忽略)，可在数据迁移完成之后升级到白金版。
5. 确保自建ES集群没有开启security，如果开启则先关闭。
6. 确保客户自建ES集群没有安装腾讯云ES集群不支持的插件。云上集群的配置名称需要和自建集群保持一致。

Redis跨区容灾方案

Redis容灾主要分为主从和集群。

Redis主从容灾

跨区部署说明

两可用区，1主3副本部署，主可用区1主1副本，备可用区2个副本，每个可用区两个节点，可保障单机故障读请求不跨可用区，单可用区故障后仍然具备主备高可用。该方案适合于对可用性和访问延迟要求较高的场景。

高可用说明：

• VIP实现跨可用区(AZ)访问能力，多 AZ（可用区）的实例只有一个 VIP，这个 VIP 在整个Region 都可以访问，Redis 的 HA（Highly Available）并不会导致 VIP 变化。
• 当4、6区任意一个可用区出现故障：如果有一个可用区redis挂掉，如6区整体不可用，4区依然提供服务，6区的客户端将会通过Proxys集群访问4区的redis。如果4区不可用，那么6区将选举出master节点，4区客户端将通过Proxys访问6区。如果一个可用区内的单机故障，那么就会由没有故障的节点提供服务。这样整个集群依然能够对外提供服务，对客户侧的影响是有限的，客户端做好重试即可。
• 当4、6区之间网络抖动、断开之后：4区为主可用区，访问不受影响，6区默认15秒之后会主动fail ，此时6区的redis将不提 供服务，但是6区的客户端将会在4，6区网络断开10秒后感知到，然后通过第三方可用区网络访问4区的redis，不影响redis使用。2. 如果网络恢复正常之后，重新开始主分片与副分片数据同步，服务自动恢复正常。

Redis迁移方案

Proxy代理切换步骤：

1. 整个切换采用Proxy代理模式，客户应用端可以自行控制，确保灵活、快速实现自建redis切换到云上。
2. 应用端直连Proxy，然后通过Proxy进行灵活切换，例如由自建迁移到云上，以及当云上迁移失败，可以从云上又切换到自建。
3. 自建redis可以通过DTS迁移到云上redis。云上的redis又可以通过redis slaveof 同步数据到线下，需要客户侧自行配置。5月份升级DTS，确保可以从云上迁移数据到自建。