最近项目中需要设计一个消息服务,承接各个业务线的应用消息(对用户提醒) 其中涉及到消息的可靠投递.目前思考有两种方案可以选型.
image.png
风险点
-
消息投递失败
- 消息中间件不可用.
- 消息中间件内部处理异常
- 消息中间件处理成功 返回给调用端网络超时.(事物回滚 业务逻辑回滚 消息投递成功 数据不一致)
原因1:
调用端重试
原因2:
调用端重试
原因3:
回查消息中间件 或者 重试(消息中间件支持幂等)
-
解决方案
发送事物消息.
- half消息发送失败 事物回滚。(消息中间件不可用. 消息中间件内部处理异常 消息中间件处理成功 返回给调用端网络超时.)
- half 消息发送成功 执行具体业务逻辑。
- 业务逻辑处理成功 发送commit消息。业务逻辑处理失败 发送rollback消息
- 消息中间件定时查询half消息列表，回调发送方,询问业务状态.成功 commit消息 失败 rollback消息.
事物消息 可以保证 发送端业务逻辑处理 和 消息投递成功 两边的一致性.
