今天跟同事讨论了一下rocketMqd的相关实现和一些问题,觉得很有帮助 这里记录一下 先上一张画的图
名词解释
- broker1:其实就是部署rocketMq的节点,也就是部署rocketMq的服务器
- topic1:这个不用过多解释相信大家都知道
- writeQueueNum:创建tpoic的时候写队列的数量,举个例子,我们往topic发送了10条消息如果写队列定义了2那么就会创建q1和q2去均分这次的10条消息.
- readQueueNum:这个就是读队列 主要还是作为写队列和消费者实例的桥梁和负载作用
- q1,q2:这里的q1和q2就是我们在创建topic的时候定义的写队列数量
- group:消费者组一个消费者组里面应该都是创建处理同一个业务的实例
- cousumer:这个就是我们在代码里面创建订阅topic的实例
消费流程
:当provider往定义的topic里面写了10条数据后,topic在创建的时候会根据定义的writeQueuNum数量创建出上图的q1,q2…我们这里假设创建的是2 那么q1和q2里面各有5条数据,之后broker会将topic里面的数据广播到每一个group里面,group会根据根据创建topic时候定义的readQueueNum对写队列里面的数据进行划分之后发送给定义的消费者实例
可能问题
- 消息丢失:之前生产环境我们遇到过消息丢失的情况,大概是因为定义的writeQueueNum大于一个group里面的readQueueNum,这时候多出来的写队列数据就没办法被读取,一直堆积
- 订阅关系不一致: 现在有consumer1订阅topic1:tag1和consumer2订阅topic2:tag2 他们会依次注册到break,break里面有一个consumerTable用来记录不同消费组里面的消费信息其实就是一个map
,这时候假设consumer1先注册
map.put(“groupTest”,[“topic1”:{“tag”:“tag1”}]),consumer2再注册
map.put(“groupTest”,[“topic1”:{“tag”:“tag2”}]),这时候break里面的groupTest的consumerInfo信息会被覆盖会导致先注册的consumer1里面的tag1消息丢失不会有任何消费,consumer2的消息只有分发到consumer2里面的才会被正常消费
深入了解
注意事项