聊聊RocketMQ（一）

Posted 2023-03-09

参考技术A

大家好，我是BugKing，不知不觉正式工作快满2年了，在工作之前没有用过消息队列中间件，在这想分享下我这两年对RocketMQ的使用以及一些思考，因为内容比较多，会用好几期来分享。
先简单来聊下我在日常开发中，哪些问题适合使用RocketMQ来解决，因为我是搞IM的，所以下面我都会以IM的角度来分享。

在我负责的IM系统中，经常会遇到业务方群发几十万消息的场景，那面临这么多的请求，如何避免请求压垮我们的IM聊天系统呢？我们的系统应该是在自身能力范围内尽可能多地处理请求，那我们就可以使用消息队列来达到流量控制和保护后端服务的目的。
加入RocketMQ后，整个业务方发送消息的流程变成：
1、业务方调用rpc框架如dubbo接口发送消息后，直接将消息内容放入RocketMQ；
2、发消息后端服务从RocketMQ中获取消息内容，完成后续发消息流量，投递给前端。

这种设计既有优点也有缺点

那想在同一个topic下的某种消息进行流量控制限速呢？有没有什么好的办法？
我的做法是根据某种类型消息的标识，通过令牌桶算法（单机限流），根据你预估的处理能力，为这种消息单独设置一个线程池，线程池队列长度可以设置大些，用这个线程池也单独处理这种消息，这样也不会让其他类型的消息堆积在MQ。

IM系统也需要解决的核心问题时，如何利用有限的服务器资源，尽可能多地处理大量发送消息。在一个正常的IM系统中，一个完整的消息发送包含了很多操作，当你发出去一条消息后可会有这些操作：
1、消息入库
2、消息投递前端
3、用户不在线需要发送离线push。
4、用户这条消息被风控了需要发送风控提示。
5、消息需要统计数据，包含每天发送量，push量等等。
6、....
如果没有任何优化，正常的处理流程时：消息投递后，依次调用上述流程，然后结束。
对于这几个步骤来说，决定消息是否发送成功，实际上只有消息入库这个步骤，只要消息入库了，用户就一定能看到消息，就算当时没有投递给前端，后续用户拉历史消息也能把消息拉出来，但是为了判断用户在不在线，需不需要发离线push，依赖消息投递前端的结果，所以当消息入库、消息投递前端后，就可以马上结束流程，然后把消息体放入rokcetMQ中，由消息队列异步执行后续的操作。

rocketMQ的另一个作用，就是实现系统之间的解耦。
我们知道订单时在电商系统中比较核心的，当有一个新订单时：
1、支付系统发起支付流程
2、风控需要审核
3、IM系统发送一些卡片消息（比如确认收货地址）
4、统计系统需要统计数据
5、.....
这些订单下油的系统都需要实时获得订单数据。随着业务的发展，订单的下游可能在不断增加，负责订单的程序员不得不花费大量的精力，应对不断变化的下游系统，不停地调试订单系统与下游系统的接口。任何一个接口变更，订单系统就需要修改并上线，这是不能接受的。几乎所有的电商都会选择消息队列来解决类型的系统耦合的问题。这时候引入rocketMQ憨，订单系统在有一个新订单时，发送一条消息到rocketMQ的topic中，所有下游系统都订阅topic，这样每个下游可以根据订单消息来做相应的处理。

RocketMQ用的消息模式时发布 - 订阅模型。在发布 - 订阅模型中，消息的发送方称为发布者，接收方称为订阅者，服务端存放的消息的容器称为主题（Topic）。传统的队列模式和这种模型最大的区别就是，一份消息数据能不能被消费多次对的问题。因为在传统的队列模型中，任何一条消息都只能被一个消费者收到。

RocketMQ是发布-订阅模型，但是RocketMQ也有队列的概念，那队列的作用是什么呢？

我们都知道RocketMQ中有ack机制，确保消息不会在传递过程中由于网络或服务器故障而丢失，在消费端如果收到消息并完成了业务逻辑后，会给MQ回一个消费成功的确认，代表一条消息被成功消费，否则会给消费者重新发送消息，直到成功ack。这个确认机制保证了消息传递的可靠性，但是也带来了一个问题，为了确保消息的有序性，在某一笑消息被成功消息前，下一条消息是不能被消费的，否则违背了有序性这个原则，也就是每个Topic在任意时刻，最多只能有一个消费者在进行消费，这样消费端总体的消费性能就不能通过水平扩展消费者数量来提升，所以RocketMQ引入了队列来解决这个问题。来看下面这个图：

RocketMQ的每个Topic都包含多个队列，通过多个队列来实现多实例并行生产和消费。rocketMQ只在队列上保证消息的有序性，Topic层面是无法保证消息严格顺序的。每个消费组都有主题中一份完整的消息，不同消费组之间消费进度不受对方影响，
一条消息被消费组1消费过，也会给消费组2消费。
每一个消费组中包含多个消费者，同一个消费组内的消费者是竞争关系，比如一个消费组内的一条消息被消费者1消费了，就不会再给同组的其他消费者消费。

在一个Topic下的消息消费过程中，消息需要被不同的组进行多次消费，所以每个消费组在每个队列都维护一个消费位置，在这个位置之前的消息都是被消费过的，之后的消息都是没有被消费过。

** 需要注意的是Topic和消费组的关系、消费组和消费者的关系，消费组和队列数没有关系，不是有多少消费者就有多少队列，队列数可以根据数据量和消费速度合理配置**

可以按照某个唯一标识，比如IM中，根据消息发送方用户id，通过一致性哈希算法，计算出队列ID，指定队列ID发送，这样可以保证相同的用户发的消息总被发送到同一个队列上，可以确保严格顺序。

时间不早了～下期再见。