2022-05-16 消息队列：高可用

对一个消息队列而言，高可用通常考虑的客户端连接与服务端内部：客户端包含了消除单点故障导致连接失败，保障连接与宕机后找到替代结点；服务端内部包括多机房高可用与数据备份等。
以下分部分来详细说明：

1. 客户端初次连接的高可用

1.1 高可用设计

用户在使用消息中间件时，第一步要做的是创建与服务端的连接，为了确保这一步的高可用，我们需要避免连接服务端遇到单点故障的问题。当消息队列集群背后某一台机器的不可用时，客户端就无法使用整个消息队列，这就是这个场景下的单点故障，是在高可用系统中不应该出现的问题。
通常来讲我们可以笼统的把此处的HA解决方案称为服务发现策略。在此类型策略的中间件系统中，有两个必不可少的功能：

1. 中间件提供一个服务发现层，这一层的服务可以处理结点的注册与探活，把各集群的结点管理起来。当接到客户端想要建立连接时，首先访问服务发现层，接到请求的结点要使用合适的分配策略，挑出一个数据层结点，供这个客户端使用，来专门来处理它后续的生产、消费请求。
2. 结合第一条功能，在服务发现层提供一个负载均衡（LB）。客户端在访问LB时，LB会将请求随机转到背后任意可用的一台机器，同时保证LB背后的每一台机器都可以合理的处理或转发这个请求，来建立客户端的初次连接。

举例来说，客户端C发起请求到服务发现的LB后，请求打到了背后的机器S1上。S1根据中间件的分配策略，决定了分配S2数据结点给这个客户端使用。客户端开始与S2创建连接，并在短期内所有的生产、消费交由S2处理。这样一来，创建连接时的高可用的责任，就转移到了负载均衡及消息队列的服务注册、分配逻辑上。

image.png

服务发现的结点尽可能无状态（每一个结点都可更替）且部署在多个数据中心（单机房断电服务不停），其所依赖的下游服务也尽可能是HA的，这样一来我们在客户端创建连接这一步，就达到了HA。

1.2 例子

Apache Pulsar

Pulsar的元数据处理称为Broker，任何一个接到请求的Broker机器，可以根据当前处理的Topic来确认由哪台Broker（数据结点）来处理，细节可见官方文档。
关于LB，Pulsar提供了两种方案，一种是自己部署，或使用Pulsar 代理）。

Apache RocketMQ

内部有一个Name Server模块，对数据结点做结点注册与心跳检测，并且负责路由请求。https://rocketmq.apache.org/docs/rmq-arc/
RocketMQ同时也提供了同Pulsar一样的代理服务。

eBay NuMessage

NuMessage不区分数据结点与服务发现结点，当请求打到NuMessage LB时，请求会被转发到客户端想要的集群的主结点上。主结点负责结点注册与心跳检测探活，以及分配结点给客户端，此处的主结点类似于RocketMQ的Name Server。

Apache Kafka

同Pulsar Broker策略，但Apache Kafka需要引入额外的第三方包来做负载均衡或代理层。

2. 客户端与服务端交互过程中的高可用

以下为eBay NuMessage为例介绍。

2.1 多数据中心高可用

当消息队列的数据存储在多个数据中心时（Data Center，下文简称DC），发生了单个DC失效断电，其它DC依然可以为客户端提供服务，此时可以达成多DC的高可用。
NuMessage的结点可以部署在多个DC。默认客户端在建立连接时，都会分配一台对应DC的服务端结点。但如果一个DC内的NuMessage结点全部宕机（或根本没有部署）时，NuMessage会为客户端分配其它DC的服务端结点。这样单DC不可用时，客户端连到其它DC上依然可用（客户端机器宕机与断网不在考虑范围内）。随后当服务端坏掉的DC重新恢复时，会被服务端发现并尝试重新分配同DC的结点给客户端。

2.2 聚集在单数据中心的高可用

NuMessage的所有结点都注册在ZooKeeper上，因此单个结点宕机时，同一个DC下该集群的主结点（后称leader）会通过ZooKeeper了解到这件事。此时客户端再往该宕机结点发来请求必然会失败，这类失败在客户端触发了一次重新建立连接的请求。这一次Leader重新为这个客户端分配机器，不会再将这个挂掉的机器纳入考虑，而是分配其它健康的机器。
若NuMessage Leader结点宕机，一样会被其它结点通过ZooKeeper发现，并触发内部的选主，进而出现新的Leader。
因此在客户端视角，服务端连接故障时，只会发生短暂的断开后重连，以此达成了在同一DC下的高可用。

3. 服务端内部的高可用

eBay NuMessage

的存储层是Kafka，通过默认三个副本与rack awareness来保障一定程度的高可用。但当数据出现DC断电、磁盘问题、大规模网络问题时依然无法从存储层达到HA。因此NuMessage在做了以下措施：

• 生产者：默认将数据写入当前DC，若失败次数达到一定阈值或频率，尝试写入其它DC。跨DC写入时有更高延迟，但本DC产生的数据依旧能写入该集群。
• 消费者：有时会为Kafka部署aggregation结点，把所有DC的数据同步到多份aggregation topic上。而消费者只消费其中一个aggregation topic，出现DC断电时切换到另一DC消费。但消费的offset需要映射到另一DC的对应offset上。可参见uber的Kafka方案。

Uber Kafka

https://eng.uber.com/ureplicator-apache-kafka-replicator/
https://eng.uber.com/kafka/

Apache RocketMQ

结点分master\slave，写入仅写master，读取时可从slave读，因此master挂掉不影响consumer读取。
写入时可写入多个master，因此单master挂掉不影响写入。

Apache Kafka

Kafka将数据存于多份副本，仅有一个主副本，它可写可读，其它副本只能从主副本同步数据。但是在主副本宕机时，其它副本若数据合适可以通过选举为新的主副本提供服务。