首页 > 代码库 > JD订单去重的问题:谈分布式事务处理中领域驱动设计的原则
JD订单去重的问题:谈分布式事务处理中领域驱动设计的原则
原始文章:http://www.csdn.net/article/2015-01-15/2823577
订单号去重的问题:假设A节点向B节点发送新订单请求,但是网络有可能失败,则这个分布式事务有可能出现B节点上已经成功执行,但是A却以为失败了,导致重新发送订单请求,造成重复的订单
要点:关键问题是订单号这一ID信息要防止重复生成,如果ID号能够提前生成的话,就可以在每次发送这一ID信息,使得请求的每次处理做到幂等。
因此,JD现在的方案相当于在B节点上根据商品信息、客户信息等等,做了一个到订单ID的反向映射,但这个方案并不灵活,假设客户就是想在1秒内连续下2个订单呢???
所以,更简单的方案是,让浏览器端直接生成这个订单ID号:根据用户ID和物品清单;
也就是说,分布式事务处理的一个简单原则是,要保证幂等,让事务请求方直接生成事务ID。
要点:关键问题是订单号这一ID信息要防止重复生成,如果ID号能够提前生成的话,就可以在每次发送这一ID信息,使得请求的每次处理做到幂等。
因此,JD现在的方案相当于在B节点上根据商品信息、客户信息等等,做了一个到订单ID的反向映射,但这个方案并不灵活,假设客户就是想在1秒内连续下2个订单呢???
所以,更简单的方案是,让浏览器端直接生成这个订单ID号:根据用户ID和物品清单;
也就是说,分布式事务处理的一个简单原则是,要保证幂等,让事务请求方直接生成事务ID。
注意:订单号不是敏感信息,因此实际上并不需要一定在服务器端生成。或者说,需要一个初始防止“重复”的虚拟订单号,然后服务器后端可以映射生成自己的,这没有什么问题。
这个事务ID实际上并不是全局的,假如A向B发送了一个事务请求,而B在处理的过程中又需要向C发送一个子事务请求,则B需要生成自己的子事务ID
这实际上就是领域驱动设计的一些思想在里面了
这个事务ID实际上并不是全局的,假如A向B发送了一个事务请求,而B在处理的过程中又需要向C发送一个子事务请求,则B需要生成自己的子事务ID
这实际上就是领域驱动设计的一些思想在里面了
JD订单去重的问题:谈分布式事务处理中领域驱动设计的原则
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。