架构

1. ZooKeeper：管理 Broker 注册、分区 Leader 选举及消费者组状态。
2. Broker：存储 Partition数据，每个 Partition 为独立日志文件。
3. Producer/Consumer：通过 ZooKeeper获取路由信息，实现消息分发与消费。

1. NameServer：无状态路由中心，管理 Broker 地址与 Topic 队列映射。
2. Broker：主从架构，Master 处理读写，Slave 异步/同步备份数据。
3. CommitLog：全局顺序写入消息体，ConsumeQueue 存储消费偏移索引。

对比

RocketMQ 顺序消息

生产者：单个生产者和串行发送
消息存储：按照时间顺序追加到commitlog中的，然后会被定时分发到cosumerQueue
分区顺序：MQ生产者需要发送顺序消息的时候，需要在send方法中传入一个MessageQueueSelector，其中需要重写一个select方法，这个方法就是用来定义要把消息发送到哪个MessageQueue的。这样就实现了分区顺序消息
全局顺序：写死一个队列，让所有的消息都发往这一个队列中即可
顺序消费：
1.分布式锁保证了同一个消费组内，一个队列只会被分配给一个消费者。
2.Synchronized这把锁的目的就是为了保证同一时刻只有一个线程去消费这个队列
3.ReentrantLock这把锁的目的就是保证在重平衡过程中不会出现重复消费

RocketMQ事物消息

1. 发送half消息，探测MQ是否正常
2. half消息发送失败，MQ故障，业务回滚
3. half消息成功，订单系统执行自己的业务逻辑
4. 订单系统执行本地事务失败，则需要发送一个rollback请求给MQ，让其删除这条half消息
5. 如果订单系统的本地事务执行正常，此时需要发送一个commit请求给MQ，要求MQ对之前的half消息进行commit操作，这样库存系统就可以消费这条消息了。

RocketMQ延时消息

存在不足
1.延时级别只有 18 个，并不能满足所有场景，也不灵活；
2.延时时间不准确，后台的定时线程可能会因为处理消息量大导致延时误差大。

为了弥补延时消息的不足，引入了定时消息，60s 的时间轮，但是对于所有的时间延时，都是支持的。可以在每个时间节点增加一个 round 字段，记录时间轮转动的圈数，时间轮算法的优势是不用去遍历所有的任务，每一个时间节点上的任务用链表串起来，当时间轮上的指针移动到当前的时间时，这个时间节点上的全部任务都执行。