场景描述
项目中有一个更新工单并激活相关工单的接口,其步骤分为三步:
- 占用工单
- 激活工单组相关工单,状态从初始变为激活状态
- RPC调用(此处使用HSF),更新外部系统的关联的单据状态
整个过程包裹在一个事务中,保证数据一致性;失败后依靠客户端手动重试
由于第二步工单组的工单个数不确定,可能造成处理超时问题,因此想异步化提升业务接口响应性能
通过消息系统(notify)自发自收可以将过程异步化,结果遇到了问题。
遇到的问题
第二步中做了数据库查表操作,原来的方案下,处于同一事务可以获取事务缓存来得到数据库更新后的结果。
将事务的第二步改为异步消息发送,只要消息成功发出,就开始执行第三步,也就是将2、3步骤并行。
如果它比第三步执行更快,那么事务提交之前是查表是不会得到正确结果的。导致第二步的消息处理存在异常。
分析
本来事务的三个步骤的依赖关系是,2和3依赖1执行完成。
异步化之后为了保证数据的最终一致性,有两种思路
事务后异步提交
- 原来是1、3作为一个事务执行完成后,再发送消息执行2。
- 配置notify重试次数,如果第二步消息发送失败则重新投递。
- 如果自动重试失败,则编写ajax手动投递消息
这样能保证数据的最终一致性。适用范围:适用于新编写业务逻辑,不适用异步逻辑被多处引用且方法逻辑复杂的场景
事务写操作异步化
- 重写异步逻辑,将表查询全部放事务内,成功后再发送消息处理
- 同样要配置notify自动重试和后门投递
保证数据最终一致性,因为异步处理中真正依赖表状态的都是查询操作。适用范围:读写逻辑没有依赖
因此,新方法采用思路一合适,而重构老方法采用思路二更合适。本问题采用了后者
解决
重试和超时设置
在发送端配置Spring实现,自动重传采用notify默认的3次基本满足要求。
读写分离
- 对工单组中需要处理的其他工单,在原事务中通过查表,进行一遍筛选,得到需要处理的工单列表。
- 发送信息,批量更新筛选后的工单列表
- 接收消息后调用自身manager事务再做处理,失败则回滚,让notify服务端重传。