消息队列mq的3个使用场景

一、抵御流量洪峰，

  整体架构设计如下：

1、nginx+tomcat

2、tomcat controller取到请求后向rocketmq 发送一个msg，将msg id返回给app，同时在redis里缓存msg状态为init（设置定时时间，时间到后清除）

3、client（app/h5/小程序） 通过msg id，定时向server获取msg处理状态

（init时 画圈，没有时返回繁忙，fail时返回处理失败）

4、server向redis查询处理的结果，返回 init/null/fail等状态

 

------ 后台服务层

1、原来controller里面的逻辑，改为使用rocketmq的消息来驱动

2、processor（原来的controller里面的逻辑） 取出消息，rpc调用后台的服务，将结果设置到redis

 

区别：1、原来是流量直接打到tomcat，瞬间请求包太多时，会导致tomcat拒绝服务（外部看起来像是down了）

2、现在用rocketmq先缓存消息（至少百万级别，不放心可以使用集群），对于真正的服务处理而言是异步的。

processor可以自己控制消息消费的速度（并发程度），避免整个后台被撑爆

 

二、实现跨进程、跨数据库的一致性事物

0、msg中带有一个业务的msgId

1、本serv处理完后，保证消息发到rocketmq

2、每个serv进程（分布式）监听自己关心的消息，并消费消息（根据msgid 保证幂等性）

3、serv本地除了业务数据，也要记录消息的处理状态

4、这样正常情况下会执行到最后，出现异常时根据各个serv本地的状态人工补单

 

三、服务间异步调用

适用情况（10年前，mmo server就已经用这种方式保证扩展性和灵活性）：

1、内部的服务非常多（拆的很细）

2、一个serv处理完后有很多的后续serv（甚至不知道有多少个）

 

实现方式：

1、定义全局消息，比如开始处理、检查完账户有效性、检查完资金、检查完基金状态、支付完成、发起退款、退款完成……

2、每个serv自己做完了，就发出对应的消息

3、后续的serv监听自己关心的消息

 

整个系统基于宏观的消息来异步组织