互联网之利器系列-RocketMq(一)

一、Rocket Mq介绍

    RocketMQ是一款分布式、队列模型的消息中间件，是阿里巴巴集团自主研发的专业消息中间件，借鉴参考了JMS规范的MQ实现，更参考了优秀的开源消息中间件KAFKA,实现了业务消峰、分布式事务的优秀开源框架。

   开源git路径：https://github.com/apache/rocketmq

   何为优秀：

   1.其底层代码编写清晰优秀，采用Netty NIO框架进行数据通信。

   2.摒弃了Zookeeper,内部使用更轻量级的NameServer进行网络路由，提高服务性能，并且支持消息失败重试机制。

   3.天然支持集群模型，消费者负载均衡、水平扩展能力，支持广播模式和集群模式。

   4.采用零拷贝的原理、顺序写盘、支持亿级消息堆积能力。后续文章会细讲。

   5.提供丰富的消息机制，如顺序消息、事务消息等。后续文章会细讲。

二、RocketMq集群部署

部署说明：

NameServer：几乎无状态，可以集群部署，节点之间不同步信息。

Broker：相对复杂，总结下来就这三点
1，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。
2，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示  Slave。
3，Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。

Producer：与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。

Consumer：与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

实际操作：参考docker部署Rokect Mq

三、名词解释：

Message:消息，消息队列中信息传递的载体。

Message ID:消息的全局唯一标识，由 MQ 系统自动生成，唯一标识某条消息。

Message Key:消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。

Topic:消息主题，一级消息类型，通过 Topic 对消息进行分类。

Tag:消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类。

Producer:消息生产者，也称为消息发布者，负责生产并发送消息。

Producer ID：一类 Producer 的标识，这类 Producer 通常生产并发送一类消息，且发送逻辑一致。

Consumer：消息消费者，也称为消息订阅者，负责接收并消费消息。

Consumer ID：一类 Consumer 的标识，这类 Consumer 通常接收并消费一类消息，且消费逻辑一致。

四、rocket mq心跳机制

五、rocket mq消息存储

https://blog.csdn.net/javahongxi/article/details/72956619这篇文章写的很清楚
commitLog：
1，commitLog是保存消息元数据的地方，所有消息到达Broker后都会保存到commitLog文件。
这里需要强调的是所有topic的消息都会统一保存在commitLog中，举个例子：当前集群有TopicA, TopicB，这两个Toipc的消息会按照消息到达的先后顺序保存到同一个commitLog中，而不是每个Topic有自己独立的commitLog。
2，每个commitLog大小上限为1G，满1G之后会自动新建CommitLog文件做保存数据用。
3，CommitLog的清理机制：
     按时间清理：rocketmq默认会清理3天前的commitLog文件；
     按磁盘水位清理：当磁盘使用量到达磁盘容量75%，开始清理最老的commitLog文件。
4，文件地址：${user.home}/store/${commitlog}/${fileName}

consumerQueue：
1，ConsumerQueue相当于CommitLog的索引文件，消费者消费时会先从ConsumerQueue中查找消息的在commitLog中的offset，再去CommitLog中找元数据。如果某个消息只在CommitLog中有数据，没在ConsumerQueue中， 则消费者无法消费，Rocktet的事务消息就是这个原理。
2，consumequeue的数据结构包含3部分：
消息在commitLog文件实际偏移量(commitLogOffset)
消息大小
消息tag的哈希值
3，文件地址：${user.home}/store/consumequeue/${topicName}/${queueId}/${fileName}

五、Rocketmq高并发 

1、Producer端向Broker写消息支持负载均衡，producer会保存着当前所有broker服务器列表，每次发送换成之后切换到下一个broker，即顺序方式。
2、Consumer端负载均衡集群消费模式下，同一个ID的所有消费者实例平均消费该Topic的所有队列。
3、消息顺序写：单台broker上所有的元数据都会顺序的往同一个commitLog中写，写满1G之后才写新的commitLog，属于真正意义上的顺序写。另外，MQ默认累计4K之后才会强制从PageCache中刷到磁盘中，所以并发写的性能很高。
4、消息随机读：
MQ读取消息依赖系统PageCache，PageCache命中率越高，读性能越高，Linux平时也会尽量预读数据，使得应用直接访问磁盘的概率降低。预加载机制+消息顺序保证了大部分的读都会命中PageCache。

五、应用

后续补充