RocketMq知识点理解

RocketMq关键点理解

各个角色间的关系：

RocketMq中每个Broker（master和slave）与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
Name Server之间不会有任何信息交互，各自独立。
producer和consumer随机从一个name server即可获得全部topic的路由信息。
producer根据得到的路由信息，同master建立长连接。
consumer根据路由信息，同master个salve都建立长连接。然后根据设置的订阅规则，选择从master或者slave订阅消息。

Broker：

分为master和slave两个角色。master提供读写读物，salve只提供读服务。
为了保证可用性，需要部署多套broker，每套broker至少有1个master和1个以上的salve。
在同一套broker中，master和salve都是同样的brokerName，master的brokerId是0，salve的brokerId必须是非0的。

同步刷盘和异步刷盘。

同步刷盘是说，broker在收到每个消息后，都是先要保存到硬盘上，然后再给producer确认。异步刷盘就是先回复确认，然后批量保存到硬盘上。异步刷盘有更好的性能，当然也有更大的丢失消息的风险。

同步复制和异步复制。

是说在master和salve之间复制消息的方式。同步是说在salve也存储了消息后再答复producer。
异步复制是先答复producer，再去向salve复制。
通过同步复制技术可以完全避免单点，同步复制势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。RocketMQ从3.0版本开始支持同步双写。

MQPullConsumer和MQPushConsumer的区别

consumer被分为2类：MQPullConsumer和MQPushConsumer，其实本质都是拉模式（pull），即consumer轮询从broker拉取消息。
区别是：
push方式里，consumer把轮询过程封装了，并注册MessageListener监听器，取到消息后，唤醒MessageListener的consumeMessage()来消费，对用户而言，感觉消息是被推送（push）过来的。
pull方式里，取消息的过程需要用户自己写，首先通过打算消费的Topic拿到MessageQueue的集合，遍历MessageQueue集合，然后针对每个MessageQueue批量取消息，一次取完后，记录该队列下一次要取的开始offset，直到取完了，再换另一个MessageQueue。

对RocketMQ使用长轮询Pull方式，可保证消息非常实时，消息实时性不低于Push的理解

数据交互有两种模式：Push（推模式）、Pull（拉模式）。
推模式指的是客户端与服务端建立好网络长连接，服务方有相关数据，直接通过长连接通道推送到客户端。其优点是及时，一旦有数据变更，客户端立马能感知到；另外对客户端来说逻辑简单，不需要关心有无数据这些逻辑处理。缺点是不知道客户端的数据消费能力，可能导致数据积压在客户端，来不及处理。
拉模式指的是客户端主动向服务端发出请求，拉取相关数据。其优点是此过程由客户端发起请求，故不存在推模式中数据积压的问题。缺点是可能不够及时，对客户端来说需要考虑数据拉取相关逻辑，何时去拉，拉的频率怎么控制等等。

长轮询：
轮询是说，每隔一定时间，客户端想服务端发起一次请求，服务端有数据就返回数据，没有数据就返回空，然后关闭请求。
长轮询，不同之处是，服务端如果此时没有数据，保持连接。等到有数据返回（相当于一种push），或者超时返回。
所以长轮询Pull的好处就是可以减少无效请求，保证消息的实时性，又不会造成客户端积压。

其他

1. 对于一个消息中间件来说，持久化部分的性能直接决定了整个消息中间件的性能。RocketMQ充分利用Linux文件系统内存cache来提高性能

2. RocketMq Broker的buffer不会满。原因是RocketMQ没有内存Buffer概念，RocketMQ的队列都是持久化磁盘，数据定期清除。这是RocketMq和其他消息中间件的重要区别。对RocketMQ来说的内存Buffer抽象成一个无限长度的队列，不管有多少数据进来都能装得下，这个无限是有前提的，Broker会定期删除过期的数据。

3. 消息堆积。消息堆积的能力是评价一个消息中间件的重要方面。因为使用消息中间件有一部分功能是为了为后端系统挡住数据洪峰。在产生消息堆积时，消息中间件对外的服务能力至关重要。
   因为RocketMq的消息都是持久化硬盘的，当消息不能在内存Cache命中时，要不可避免的访问磁盘，会产生大量读IO，读IO的吞吐量直接决定了消息堆积后的访问能力。

4. 分布式事务。分布式事务涉及到两阶段提交。分为预提交阶段和commit阶段。在commit阶段需要回去改消息的状态。RocketMq在这里没有使用KV存储来做。而是在commit阶段会拿到消息的offset，然后直接去找消息，修改其状态。这样的好处是设计更简单，速度更快。缺点是会产生过多的数据脏页。

5. producer只与master建立连接，consumer同master和slave都建立连接，向谁订阅可以配置。

6. Rocketmq的消息的存储是由consume queue和 commitLog 配合完成的
   consume queue 消息的逻辑队列，相当于字典的目录用来指定消息在消息的真正的物理文件commitLog上的位置, 每个topic下的每个queue都有一个对应的consumequeue文件。
   默认文件地址：${user.home} \store\consumequeue${topicName}${queueId}${fileName}
   修改方法：配置文件的
   storePathRootDir=/home/haieradmin/mqstore/rocketmqstore
   storePathCommitLog=/home/haieradmin/mqstore/rocketmqstore/commitlog
   这两个参数。