rocketmq一些细节记录(持续更新)

消费进度：https://www.jianshu.com/p/ca3816c4a9e6
消费模式：https://blog.csdn.net/l18848956739/article/details/83111455
消费进度在broker端的保存是按照group来区分的，json格式：
{“consumeGroup" : [ {”ConsumeQueue1“:offset} ] }

总的流程和消费失败详解：https://blog.csdn.net/javahongxi/article/details/85009840

关于自动创建topic：
为什么生产环境不建议自动创建：
https://blog.csdn.net/prestigeding/article/details/91476328

关于主从同步：https://blog.csdn.net/qq_27529917/article/details/79774128

这里的读写分离，并不是主只负责写，而是只有当主服务器消息拉取出现堆积时才将拉取任务转向从服务器。

同一个brokerName，有brokerId =0,和broker=1,2的，那怎么选呢：

对于没有消息可拉取的情况，一般队列都会有空轮训的问题，rocketmq用长轮训来处理这个问题，避免资源浪费：https://www.jianshu.com/p/f071d5069059?utm_source=oschina-app
会将请求hold住，然后好像每隔5秒去查询一次有没有新消息，整体保留30秒

顺序消费：comsumeQueue一把锁，processQueue一把锁，consumeService一把锁

关于重复消息：
https://blog.csdn.net/linuxheik/article/details/79579329
就是offset 101-200，102-200都都消费成功了，但是101都过了很久才完成，那么消费进度保存会在101，然后后面的都会再消费一次。
然后关于15分钟和2000offset最大值，参考《技术内幕》137-139.
都是绑定在ProcessQueue上
限流：1000offset就等待
2000是因为上面说的102-200成功，101失败。
15分钟暂时不理解。按道理是15分钟没消费都就会从processQueue移除，调用remove()方法，那这把它重发回去了是怎么更新进度的呢？放入重试队列吗，然后会自动更新进度？
下面这个解释不知道是不是该这么理解

有一个问题：consumerQueue是什么时候生成的？？tag是什么时候加上去的？能按tag过滤，那么是发送消息时，如果没有这个tag，那就新生成一个consumerQueue并添加上tag吗？
过了一段时间回来冲头看来，consumeQueue是默认4个文件夹，tag是附带在Message对象里都，然后保存到consumeQueue都时候会把这个tag都哈希值也保存进去

转载大佬博客，解决来我很久都弄混都东西：https://blog.csdn.net/meilong_whpu/article/details/76921208
commitlog和consumeQueue是保存在不同都地方都：
顺手也看到了重试队列和定时任务。。。。。
consumeQueue:

commitlog:

commitlog相当于整个文件夹，里面保存所有都消息，然后consumeQueue保存消息在commitlog里面都位置（偏移量）

关于从哪里开始拉取：是在pullRequest里面判断的，从broker拉取消息的时候返回的offset如果<0,说明需要校正偏差，那么就自行设置采用哪种方式(CONSUME_FROM_FIRST_OFFSET)

关于重复消费
在ProcessQueue的removeMessage的第二种情况有个问题，假设有如下情况：
批量拉取了4条消息ABCD，分别对应的offset为400|401|402|403，此时consumeBatchSize(批量消费数量，默认为1，即一条一条消费)，那么会分4个线程去消费这几个消息，出现下面消费次序
消费D -> removeMessage -> 返回400(情况2)
消费C -> removeMessage -> 返回400(情况2)
消费B -> removeMessage -> 返回400(情况2)
消费A -> removeMessage -> 返回404(情况1)

在消费A之前，本地消费进度持久化到Broker之后，应用宕机了，那么此时Broker保存的是offset=400(准确来说，在消费完A且保存消费进度到broker之前，offset都是400)。那么会有什么问题呢？

先假设消费完DCB且消费进度上传完成宕机，然后重启应用，这时候会先从broker获取应该从哪里消费()，因为DCB消费完成后都是保存400这个消费进度，那么返回的是400，这时候consumer会请求offset为400的消费，到这里，已经重复消费了DCB。(做幂等)

消息丢失的问题：https://www.jianshu.com/p/3213d8c29fd0
这个可以加深理解offset的作用

关于ProcessQueue和ConsumerMessage的使用，可以参照线程池的消息队列。

关于消费进度：

关于消费者启动：consumer.start()----》MQClientInstance.start()

关于延迟容错等。

最开始ID调用在这里。这个东西会更新FaultItem

然后在选择队列等地方，会有一个判断是否可用，里面就是判断FaultItem


如果这个MAp表里已经被更新，不存在失败ITEM里就直接返回true，说明可用，不然就比较下时间。


这个startTimeStamp就是创建等时间+延迟容错时间，判断是否可以就看现在是不是已经过了禁用时间。

1.namesrv每十秒检测一次存活的broker,但是不会把结果直接推给producer，而是producer每30秒向namesrv更新一次路由信息。
2.topic队列选择：tryToFindTopicPublishListInfo方法。
假设Topic A分布在b,c两个broker上，b,c各有4个队列，生产者里面会有一个sendWhichQueue属性，自增的，然后如果获取b的第一个队列后，b宕机了，下次还是会依次去看b的剩下三个队列，就浪费了，所有可以开启故障延迟，(sendLatencyFaultname)，会把这个broker标记，默认5分钟后再去重新看它是否可用
3.broker里commitlog保存所有的主题，但是同一个主题的消息是不连续的保存在commitlog里面，所以直接从commitlog里面去遍历查找效率很低。就引入里comnsumeQueue.一个Topic下的每个Message Queue都有一个对应的consuemeQueue,保存的是指向物理存储的地址（offset）。


另外，broker里面还有一个还给消息生成里一个indexFile索引文件来加速查询。rocketmq会先把消息全部存储到commitlog里，然后异步生产转发任务来更新consumequeue和indexFile.
4.为什么broker读比较慢，因为所有队列共用一个文件，1G，然后是随机读，所有比较慢。

5.事务消息的流程，看阿里云的介绍：https://help.aliyun.com/document_detail/43348.html?spm=5176.doc43490.6.566.Zd5Bl7

关于HalfTopic和OpTopic：
OpTopic记录了已经有了状态（commit/rollback)的消息，回查的时候，会看这条消息有没有在op里面有记录，有记录的话说明状态已经明确了，就不需要回查了.