一、背景
消息服务和其他两个服务同时消费一条订单消息,消息服务需要依赖其他两个服务的消费结果,发送支付成功公众号推送消息。
二、目的
消息服务处理逻辑时,其他两个服务都已经消费完成。
三、消息同步方式
1.原有消费模式
2.一些方案
标号 | 方案 | 具体 | 优势 | 劣势 |
---|---|---|---|---|
方案1 | 改为串行消息 | coin接收订单消息,处理后透传给marketing,marketing处理后再透传给message | 逻辑简单 | 扩展性极差,如果message又依赖了新的服务,需要改动很大 |
方案2 | 记录消息,定时任务触发 | message接收订单消息后入库,之后定时扫表发送公众号模板消息 | 扩展性好 | 实时性差 |
方案3 | 触发条件由订单消息改为marketing和coin消息 | message同时接收marketing和message的透传消息。如果收到的是marketing消息,在redis中做标记,再收到coin的消息,查redis得知marketing已经消费,触发发送公众号模板消息逻辑。通过分布式锁保证同时只有一个消息在消费 | 扩展性好,实时性强 | 复杂性相对较高 |
3.最终对方案3做了一些改进
1)流程图
2)具体逻辑
- 订单支付消息分别由marketing服务和coin服务消费
- 消费后分别透传订单信息+订单消息的messageId,再指定一个messageType,方便之后处理类似的消息依赖逻辑
- 执行incr命令,key中包含订单消息的messageId
- 如果返回1,说明之前没有这个key,直接返回消费成功,等待另一个服务消费
- 如果返回2,说明另一个服务消费过了,发送公众号模板消息,返回消费成功