RocketMQ实战与原理解析

一、Topic消息存储

image.png

1、消费者发送的Message会在Broker中的Queue队列中记录。
2、一个Topic的数据可能会存在多个Broker中。
3、一个Broker存在多个Queue。
4、单个的Queue也可能存储多个Topic的消息。
也就是说每个Topic在Broker上会划分成几个逻辑队列，每个逻辑队列保存一部分消息数据，但是保存的消息数据实际上不是真正的消息数据，而是指向commit log的消息索引。

二、NameServer 调度中心

NameServer在RocketMQ集群中扮演调度中心的角色。各个Producer、Consumer上报自己的状态上去，同时从NameServer获取其他角色的状态信息。NameServer的功能虽然非常重要，但是被设计得很轻量级，代码量少并且几乎无磁盘存储，所有的功能都通过内存高效完成。本章还介绍了底层的通信机制，RocketMQ基于Netty对底层通信做了很好的抽象，使得通信功能逻辑清晰，代码简单。

为何不用ZooKeeper
ZooKeeper是Apache的一个开源软件，为分布式应用程序提供协调服务。那为什么RocketMQ要自己造轮子，开发集群的管理程序呢？答案是ZooKeeper的功能很强大，包括自动Master选举等，RocketMQ的架构设计决定了它不需要进行Master选举，用不到这些复杂的功能，只需要一个轻量级的元数据服务器就足够了。

中间件对稳定性要求很高，RocketMQ的NameServer只有很少的代码，容易维护，所以不需要再依赖另一个中间件，从而减少整体维护成本。

三、消息队列核心机制

尽量保证顺序写，随机读，利用“零拷贝”技术，提高消息存盘和网络发送的速度。

image.png

存储机制这样设计有以下几个好处：

1）CommitLog顺序写，可以大大提高写入效率。

2）虽然是随机读，但是利用操作系统的pagecache机制，可以批量地从磁盘读取，作为cache存到内存中，加速后续的读取速度。

3）为了保证完全的顺序写，需要ConsumeQueue这个中间结构，因为ConsumeQueue里只存偏移量信息，所以尺寸是有限的，在实际情况中，大部分的ConsumeQueue能够被全部读入内存，所以这个中间结构的操作速度很快，可以认为是内存读取的速度。此外为了保证CommitLog和ConsumeQueue的一致性，CommitLog里存储了Consume Queues、Message Key、Tag等所有信息，即使ConsumeQueue丢失，也可以通过commitLog完全恢复出来。

高可用机制

消费端高可用：consumer在Master繁忙时会自动切换到Slave读，当Master故障时，不会影响consumer从Slave消费消息；

服务端高可用：创建Topic时，将message queue创建在多个broker组上，这样当某个broker组的Master挂掉之后，也能通过其它broker组的master发送消息；

刷盘方式一般采用异步刷盘，保证性能，主从复制方式选择同步复制，保证数据不会丢失