最近项目中需要设计一个消息服务,承接各个业务线的应用消息(对用户提醒) 其中涉及到消息的可靠投递.目前思考有两种方案可以选型.

image.png

风险点

• 消息投递失败

1. 消息中间件不可用.
2. 消息中间件内部处理异常
3. 消息中间件处理成功 返回给调用端网络超时.(事物回滚 业务逻辑回滚 消息投递成功 数据不一致)

原因1:
   调用端重试
原因2:
   调用端重试
原因3:
   回查消息中间件 或者 重试(消息中间件支持幂等)

• 解决方案

发送事物消息.

1. half消息发送失败 事物回滚。(消息中间件不可用. 消息中间件内部处理异常 消息中间件处理成功 返回给调用端网络超时.)
2. half 消息发送成功 执行具体业务逻辑。
3. 业务逻辑处理成功 发送commit消息。业务逻辑处理失败 发送rollback消息
4. 消息中间件定时查询half消息列表，回调发送方,询问业务状态.成功 commit消息 失败 rollback消息.

事物消息 可以保证 发送端业务逻辑处理 和 消息投递成功 两边的一致性.