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