RocketMQ入门学习：(1) RocketMQ常见应用场景

RocketMQ常见应用场景

今天正式开始关于消息中间件RocketMQ的学习。在实际应用前，需要先了解在什么情况下我们可能会应用到它，因此首先了解 Rocket的基本使用场景。
提到消息队列，首先就会想到最基本的三个使用场景：异步、解耦、削峰。
下面我们在实际环境中解释下这三个使用场景。
对于一个基本的支付系统，在早期设计的时候。用户下单后，需要等待大概100ms，即可得到支付消息发送成功的反馈，这个响应时间对于用户来说是能够接受的。

而随着系统的迭代更新，产品经理可能会加一些新的功能到系统中：如优惠券、用户积分的发放，用户短信的反馈等等。

在支付流程走完后，还需要依次完成代金券、积分、短信等接口，最后才能将支付消息成功送达。这会导致原本的100ms延迟到300ms，响应时间的增加可能会导致系统的tps下降，严重影响系统性能。
为了解决上述问题，首先想到的解决方式就是采用异步消息的方式。首先来了解一下同步消息与异步消息的定义。
1、同步消息
同步消息传递涉及到等待服务器响应消息的客户端。消息可以双向地向两个方向流动。本质上，这意味着同步消息传递是双向通信。即发送方向接收方发送消息，接收方接收此消息并回复发送方。发送者在收到接收者的回复之前不会发送另一条消息。
2、异步消息
异步消息传递涉及不等待来自服务器的消息的客户端。事件用于从服务器触发消息。因此，即使客户机被关闭，消息传递也将成功完成。异步消息传递意味着，它是单向通信的一种方式，而交流的流程是单向的。
从定义来看，两者的主要区别就是是否需要来自服务器的响应消息。从消息类别上分析，支付消息对于一个商城系统来说是最为重要的，需要服务器端及时反馈给客户端消息是否发送成功了。而优惠券、会员积分等消息的传递则显得不是那么的重要，不需要服务器端立即反馈消息是否传递成功的响应。
因此，我们可以将两者分离开，对于支付消息，采用同步传递的方式，而其他信息，则采用异步消息的传递机制。

从上图能够看出，经过异步处理的支付系统，只需要发送一条支付的同步消息，响应时间依旧是100ms。
对于上述场景的解决方法，首先想到的可能是采用新建线程的方式。原始的线程负责完成支付消息，并等待服务端响应。新建一个新的系统，依次调用优惠券、积分、短信等接口。
采用多线程的方式的确能够实现消息的发送，但同时也会带来很多的缺点。
首先，由于需要在现有系统中，新建线程、调用多个接口，这会导致现有代码的耦合度较高，也会使当代码出现问题时，难以排查。
同时，由于采用多线程的方式，我们还要对多个线程进行管理维护，这也会增加我们的工作量。
这也就是MQ使用的第二个场景，将业务进行解耦。

通过MQ这个单独的系统，我们无须编写代码、新建线程来异步调用接口。只需将消息发送到MQ中，MQ就会替我们将相应的消息发送至各个接口了。
而对于比较常见的高并发场景。假设我们的Mysql服务器tps为2000，当较多的请求发送到Mysql 时，会导致Mysql宕机或请求被拒绝。
这时候就需要进行削峰，将多出来的请求“暂存”起来，等待Mysql处理完之前积压的任务后，再处理这些请求。
MQ内置有较大的存储空间，能够将将多余的消息请求按序存储起来，根据接收者的接收能力按序输出消息