【MQ】如何保证消息队列的高可用？
RocketMQ
-
NameServer集群部署
-
Broker做了集群部署
-
主从模式
-
类型：同步复制、异步复制
-
主节点返回消息给客户端的时候是否需要同步从节点
-
Dledger：要求至少消息复制到半数以上的节点之后，才给客户端返回写入成功
-
slave定时从master同步数据（同步刷盘、异步刷盘），master一旦挂了，slave提供消费服务，不能写入消息
-
-
-
Kafka
-
Kafka 从 0.8 版本开始提供了高可用机制，可保障一个或多个 Broker 宕机后，其他 Broker 能继续提供服务
分区副本、备份机制
- 同一个 Partition 存在多个消息副本，每个 Partition 的副本通常由 1 个 Leader 及 0 个以上的 Follower 组成，
-
Kafka 会尽量将所有的 Partition 以及各 Partition 的副本均匀地分配到整个集群的各个 Broker 上
-
多副本机制
-
分区（Partition）引入了多副本（Replica）机制。
-
多分区、多副本机制好处呢？
-
1. Kafka 通过给特定 Topic 指定多个 Partition分区, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力（负载均衡）。
-
2. Partition 可以指定对应的 Replica 数, 这也极大地提高了消息存储的安全性, 提高了容灾能力，不过也相应的增加了所需要的存储空间。
-
-
-
ACK 机制
- 生产者发送消息中包含 acks 字段，该字段代表 Leader 应答生产者前 Leader 收到的应答数
-
发送的 acks=1 和 0 消息会出现丢失情况，为了不丢失消息可配置生产者acks=all & min.insync.replicas >= 2
-
「acks=0」
-
生产者无需等待服务端的任何确认，因此 acks=0 不能保证服务端已收到消息
-
-
「acks=1」默认值
-
只要 Partition Leader 接收到消息而且写入本地磁盘了，就认为成功了，不管其他的 Follower 有没有同步
-
-
「acks=all or -1」
-
服务端会等所有的 follower 的副本受到数据后才会收到 leader 发出的 ack，这样数据不会丢失
-
Broker 有个配置项min.insync.replicas(默认值为 1)代表了正常写入生产者数据所需要的最少 ISR 个数
-
-
ISR 机制
- ISR 中的副本都是与 Leader 同步的副本，不在 ISR 中的Follower副本就被认为是没有资格的
-
Follower 周期性地向 Leader 发送 FetchRequest 请求，发送时间间隔配置在replica.fetch.wait.max.ms中，默认值为 500
-
每个分区的 Leader 负责维护 ISR 列表并将 ISR 的变更同步至 ZooKeeper，被移出 ISR 的 Follower 会继续向 Leader 发 FetchRequest 请求，试图再次跟上 Leader 重新进入 ISR
-
ISR 中所有副本都跟上了 Leader，通常只有 ISR 里的成员才可能被选为 Leader
-
主从同步
- 1、Follower副本通过发送Fetch请求来同步Leader副本上的数据。
-
Unclean 领导者选举
-
当 Kafka 中unclean.leader.election.enable配置为 true(默认值为 false)且 ISR 中所有副本均宕机的情况下，
-
开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性，
-
-
LEO（Log End Offset）
-
对于Leader副本和每个Follower副本来说，它们都有各自的LEO
-
LEO是下一个要写入的消息的偏移量
-
-
HW（High Watermark）
-
HW是分区中所有副本的已提交消息的最大偏移量。是分区中所有ISR（In-Sync Replicas）副本的LEO中的最小值
-
只要分区的Leader副本和至少一个Follower副本保持同步，消费者就能看到所有已提交的消息，即使Leader副本发生故障
-
-
确保了Kafka在分区的Leader副本发生故障时，可以从ISR中选举出一个Follower副本作为新的Leader，
-
Leader 选举 & 故障恢复机制
- 「Kafka 从 0.8 版本开始引入了一套 Leader 选举及失败恢复机制」
-
在集群所有 Broker 中选出一个 Controller，负责各 Partition 的 Leader 选举以及 Replica 的重新分配
-
Controller
-
集群中的 Controller 也会出现故障，因此 Kafka 让所有 Broker 都在 ZooKeeper 的 Controller 节点上注册一个 Watcher。
-
-
当出现 Leader 故障后，Controller 会将 Leader/Follower 的变动通知到需要为此作出响应的 Broker。
-
Kafka 使用 ZooKeeper 存储 Broker、Topic 等状态数据，Kafka 集群中的 Controller 和 Broker 会在 ZooKeeper 指定节点上注册 Watcher(事件监听器)，以便在特定事件触发时，由 ZooKeeper 将事件通知到对应 Broker
-
当 Broker 发生故障后，由 Controller 负责选举受影响 Partition 的新 Leader 并通知到相关 Broker
-