RocketMQ 核心概念

RocketMQ

RocketMQ 分布式集群

NameServer集群 是由多个平等的 NameServer 服务构成的。
Broker 集群是基于主从架构的，master 负责响应客户端的请求，slave 负责备份 master 节点上的数据，如果 master 宕机，slave 节点上可以保留数据备份。

但对应的 slave 不会主动升级为 master 响应客户端的请求。只能等待 master 节点重启后继续做数据备份。

Dledger高可用集群

Dledger高可用集群解决了分布式集群 slave 节点不可主动转换为 master 节点问题，leader 是由所有节点根据 Raft 协议(多数同意机制)选举出来的，如果 leader 宕机，可重新选取 leader，保证高可用。

Dledger 集群如何防止集群脑裂问题？

脑裂问题： 在分布式系统中，由于网络分区或者其他原因导致导致集群被分割成两个或多个集群，各自独立运行且无法感知其他子集群的存在，这可能导致数据不一致或者错误决策。

Raft 协议采取了一系列措施来避免脑裂问题的发生：

• 选举机制：Raft 协议的基础是选举出一个 Leader，其余 Follower 从 Leader 获取数据，选举过程中要求候选人必须获得大多是节点的支持才可以选举成功，从而避免了脑裂问题。
• 任期：Raft 协议在每轮选举时都会设置一个任期编号，是递增的。任期编号用于标识当前的领导者，如果当前领导者发现自己的任期编号小于其他节点的任期编号，就会停止当前的工作并更新任期编号。确保旧的领导者不会再次被选为领导者。
• 心跳机制：Leader 会定期向 Follower 发送心跳信息，当一个 Follower 长时间未收到 Leader 的心跳时，会认为当前 Leader 失效，重新开启一轮新的选举。确保系统即时 Leader 故障，也可以快速重新选取新的 Leader。
• 日志复制：Leader 节点接收客户端的写请求，然后将日志条目复制到其他 Follower 节点。只有当这些条目被多数节点成功写入本地日志后，Leader 才会将日志提交并响应客户端请求。Follower 不直接响应客户端写请求，这种机制有效避免了在脑裂情况下多个节点同时写入数据的问题，确保强一致性。

RocketMQ 运行时架构

主要由以下四大核心组件构成：

• Producer(消息生产者)
  负责向 RocketMQ 发送消息
• Consumer(消息消费者)
  从 RocketMQ 中拉取消息并处理
• Broker(消息中间服务器)
  将 Producer 发送的消息写入磁盘，Consumer 从 Broker 拉取消息，实现消息消费。
• NameServer(注册中心)
  接收 Broker 注册信息，记录每个 Broker 所属集群、IP、端口等。供 Producer / Consumer 查询

RocketMQ 消息流通方式

生产者和消费者都需要指定一个 Topic 发送或者拉取消息。Topic 只是一个逻辑概念，实际消息存在于 MessageQueue 中。

多个 MQ 比较

	优点	缺点	适合场景
kafka	吞吐量很大，性能很好，集群高可用	可能会丢失数据，功能单一	日志分析，大数据采集
RabbitMQ	消息可靠性高，功能丰富	吞吐量比较低，erlang 语言不好定制	企业内部小规模服务调用
RocketMQ	高性能，高吞吐，高可用。使用 java 语言开发，方便定制。客户端协议丰富。功能全面	服务加载比较慢	几乎全场景，特别适合金融场景
Pulasr	基于Bookeeper构建，消息可靠性非常高。	周边生态还有差距，目前使用的公司比较少。	企业内部大规模服务调用