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

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

 

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