简介
记录事务日志,然后系统根据指定的通知策略来重复通知消费.
就是尽量去通知，至于通知成功还是失败，无所谓，我不保证！一般会指定一个通知次数，如果超过次数还是失败，那就不通知了，等被通知方主动来查询。 最大努力通知策略只能算是一种跨平台的数据一致性解决方案，适用于一些时间敏感度低的业务，强调的是最终一致性！
架构图
流程说明
假设两个业务系统的两个业务AB。实现分布式事务流程如下：
- 上层业务系统在完成业务处理之后，向消息中间件发送通知消息。
- 系统监听通知消息队列，监听到通知消息后添加通知记录到数据库。
- 根据系统配置的通知时间，设置通知任务执行时间，放入DelayQueue。
- 通知任务达到执行时候后，发送Http请求给下层业务系统。
- 添加通知日志到数据库。
异常情况处理
Http请求异常：网络波动或下层业务系统Down机时（Http请求超时或响应码为5xx）。
下层业务处理失败：下层业务系统未返回处理成功。
- 通知记录会被标记为对应状态，并且添加通知日志。然后通知任务会根据系统配置的通知时间间隔，设定下次通知时间，放入DelayQueue，继续通知。
- 下层业务系统需事先业务的幂等性
- 当通知次数超过系统配置的最大次数，通知记录会被标记为通知失败，不再继续通知。可在通知管理子系统人工干预（删除或重新通知）。
拓展-延迟任务
- 数据库轮询
- jdk-delayqueue
- redis-Keyspace Notifications
- rabbitmq
- 时间轮算法-HashedWheelTimer 参考: netty 定时任务
参考
| 节点 | 角色说明| | :————: |:—————| :—: | |消息中间件 |提供消息队列功能，ActiveMQ、RocketMQ等| |通知服务子系统 |业务服务实现（存储通知记录、存通知日志、更新通知状态查询等）| |通知恢复子系统 |BEN系统重启后，恢复未完成的通知记录，继续通知| |通知监控子系统 |监控系统内存、堆积消息数，当达到阈值时发送告警邮件| |通知管理子系统 |通知可视化管理后台，通知记录查看、重发、删除、通知日志查看等| |DelayQueue |JDK自带延时队列，实现在指定时间触发通知请求|
