mysql异步消息队列_消息队列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监听自己关心的消息

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