举个样例1: 钱有100,两口子之前有约定要剩下90, 老公看到有100,花10元,花完以后由于事件异步,数据不一致,此时老婆刷新页面也看到100,再花10元.那终于是80元. 不符合用户的预期. 这个问题怎样解决?
见http://www.jdon.com/46473#23145064 异步须要一个异步回调.(或者实现一个通知接口. 不如回调实现来的美丽.) 异步须要事件 异步须要重试机制 昨天咨询了下我们的高T. 他觉得是这样实现的: 这个场景在国外银行非经常见,国外有夫妻卡. 先说说不用异步事件框架实现是怎样保持一致性的. 丈夫显示100元, 进行消费,向后端 传递聚合跟的objectVersion 1, 正常扣钱10. 传递聚合跟的objectVersion值+1变为2. 妻子因为也是显示100元,进行消费,所以递聚合跟的objectVersion也是1, 在你的调用方法前会做业务校验,因为版本objectVersion不匹配,妻子会得到错误.页面又一次刷新,显示90元. 妻子就不会继续消费了. 再说说异步事件架构下: 丈夫显示100元,进行消费,. 变成事件1存储. 正常返回给前端.但不是真的出钱. 而是告知用户"后台正在处理,请稍等". 妻子因为也是显示100元,进行消费,相同变成事件2存储.正常返回给前端.相同不出钱,告知用户"后台正在处理,请稍等". 这时候后台队列里有两个事务产生的事件. 顺序看上面两个事务commit的次序. 加时丈夫事件1先被运行. 检查聚合跟的objectVersion,成功.通过一个新接口告知给前端钱已扣除.妻子的事件2后运行,检查聚合跟的objectVersion,失败.通过一个新接口告知给前端钱无法扣除,无法消费. 同步架构採用异步架构,整个业务流程都变了. 须要新添加一个接口.还有就是.异步事件运行可能由于网络等原因产生偶然Exception.须要有重试的机制. 总结: 同步流程採用异步后. 对于开发人员和产品经理来说都更复杂了. 对于开发人员来说: 须要1.保存事件 2. 重试机制 3. 新添加一个接口(即异步框架里的回调接口) 4.告知产品经理流程已变成异步化 对产品经理来说: 须要把原来的一个同步流程思考为多个流程. 那么究竟是谁影响谁呢? 开发和产品经理是互相决定的. 一方面当产品经理处于用户体验的角度,可能会主动把一个同步流程,拆成多个异步流程.添加步骤和接口. 这时候开发人员坑并不愿意,由于添加了工作量. 还有一方面开发人员处于性能,并发量的考虑,可能会把PM思考的一个同步调用改成异步. 这时候产品经理须要知道要有新的页面提醒用户"后台处理中", 流程已变.转载于:https://www.cnblogs.com/bhlsheji/p/5343610.html
