事务异步化的读写分离

场景描述

项目中有一个更新工单并激活相关工单的接口，其步骤分为三步：

1. 占用工单
2. 激活工单组相关工单，状态从初始变为激活状态
3. RPC调用（此处使用HSF），更新外部系统的关联的单据状态

整个过程包裹在一个事务中，保证数据一致性；失败后依靠客户端手动重试
由于第二步工单组的工单个数不确定，可能造成处理超时问题，因此想异步化提升业务接口响应性能
通过消息系统（notify）自发自收可以将过程异步化，结果遇到了问题。

遇到的问题

第二步中做了数据库查表操作，原来的方案下，处于同一事务可以获取事务缓存来得到数据库更新后的结果。
将事务的第二步改为异步消息发送，只要消息成功发出，就开始执行第三步，也就是将2、3步骤并行。
如果它比第三步执行更快，那么事务提交之前是查表是不会得到正确结果的。导致第二步的消息处理存在异常。

分析

本来事务的三个步骤的依赖关系是，2和3依赖1执行完成。
异步化之后为了保证数据的最终一致性，有两种思路

事务后异步提交

1. 原来是1、3作为一个事务执行完成后，再发送消息执行2。
2. 配置notify重试次数，如果第二步消息发送失败则重新投递。
3. 如果自动重试失败，则编写ajax手动投递消息

这样能保证数据的最终一致性。适用范围：适用于新编写业务逻辑，不适用异步逻辑被多处引用且方法逻辑复杂的场景

事务写操作异步化

1. 重写异步逻辑，将表查询全部放事务内，成功后再发送消息处理
2. 同样要配置notify自动重试和后门投递

保证数据最终一致性，因为异步处理中真正依赖表状态的都是查询操作。适用范围：读写逻辑没有依赖

因此，新方法采用思路一合适，而重构老方法采用思路二更合适。本问题采用了后者

解决

重试和超时设置

在发送端配置Spring实现，自动重传采用notify默认的3次基本满足要求。

读写分离

1. 对工单组中需要处理的其他工单，在原事务中通过查表，进行一遍筛选，得到需要处理的工单列表。
2. 发送信息，批量更新筛选后的工单列表
3. 接收消息后调用自身manager事务再做处理，失败则回滚，让notify服务端重传。