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实际上并不是全局的,假如A向B发送了一个事务请求,而B在处理的过程中又需要向C发送一个子事务请求,则B需要生成自己的子事务ID

这实际上就是领域驱动设计的一些思想在里面了

时间: 2024-10-07 03:22:26

JD订单去重的问题:谈分布式事务处理中领域驱动设计的原则的相关文章

(转载)浅谈我对DDD领域驱动设计的理解

原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故

浅谈我对DDD领域驱动设计的理解

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

结合领域驱动设计的SOA分布式软件架构

引言 本文主要是参考Martion Fowler所著的<企业应用架构模式>与Eric Evans所著的<领域驱动设计>这两本泰山之作,加上本人在近年实际的工作过程中开发SOA系统所认识到的问题所写的一篇文章,欢迎各位点评. 最后两节  细说应用层 .系统总体架构是本文的重点,着重说明领域驱动设计与SOA之间的关系,对DDD有一定基础的朋友可以越过前面的几节,直接查看第七.八节. 源代码下载 (数据库可以在.edmx文件根据模型生成) 一.SOA与DDD的定义 SOA与DDD都是常用

[.NET领域驱动设计实战系列]专题八:DDD案例:网上书店分布式消息队列和分布式缓存的实现

一.引言 在上一专题中,商家发货和用户确认收货功能引入了消息队列来实现的,引入消息队列的好处可以保证消息的顺序处理,并且具有良好的可扩展性.但是上一专题消息队列是基于内存中队列对象来实现,这样实现有一个弊端,就是一旦服务重启或出现故障时,此时消息队列中的消息会丢失,并且也记录不了日志.所以就会出现,商家发货成功后,用户并没有收到邮件通知,并且也没有日志让我们发现是否发送了邮件通知.为了解决这个问题,就需要引入一种可恢复的消息队列.目前有很多开源的消息队列都支持可恢复的,例如TibcoEms.ne

浅谈分布式事务与TX-LCN

最近做项目使用到了分布式事务,下面这篇文章将给大家介绍一下对分布式事务的一些见解,并讲解分布式事务处理框架TX-LCN的执行原理,初学入门,错误之处望各位不吝指正. 什么情况下需要使用分布式事务? 使用的场景很多,先举一个常见的:在微服务系统中,如果一个业务需要使用到不同的微服务,并且不同的微服务对应不同的数据库. 打个比方:电商平台有一个客户下订单的业务逻辑,这个业务逻辑涉及到两个微服务,一个是库存服务(库存减一),另一个是订单服务(订单数加一),示意图如下: 如果在执行这个业务逻辑时没有使用

浅谈分布式数据库

基本概念 1) 单库,就是一个库 ? 2) 分片(sharding),分片解决扩展性问题,引入分片,就引入了数据路由和分片键的概念.分表解决的是数据量过大的问题,分库解决的是数据库性能瓶颈的问题. ? 3) 分组(group),分组解决可用性问题,分组通常通过主从复制(replication)的方式实现.(各种可用级别方案单独介绍) ? 4) 互联网公司数据库实际软件架构是(大数据量下):又分片,又分组(如下图) 数据分片简介和问题 数据分片是按照某个维度将存放在单一数据库中的数据分散地存放至多

【转】浅谈分布式服务协调技术 Zookeeper

非常好介绍Zookeeper的文章, Google的三篇论文影响了很多很多人,也影响了很多很多系统.这三篇论文一直是分布式领域传阅的经典.根据MapReduce,于是我们有了Hadoop:根据GFS,于是我们有了HDFS:根据BigTable,于是我们有了HBase.而在这三篇论文里都提及Google的一个Lock Service —— Chubby,哦,于是我们有了Zookeeper. 随着大数据的火热,Hxx们已经变得耳熟能详,现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人

浅谈分布式消息技术 Kafka

http://www.linkedkeeper.com/1016.html Kafka的基本介绍 Kafka是最初由Linkedin公司开发,是一个分布式.分区的.多副本的.多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志.访问日志,消息服务等等,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目. 主要应用场景是:日志收集系统和消息系统. Kafka主要设计目标如下: 以时间复杂度为O(1)的方式提供消息持久化

浅谈分布式消息技术 Kafka(转)

一只神秘的程序猿. Kafka的基本介绍 Kafka是最初由Linkedin公司开发,是一个分布式.分区的.多副本的.多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志.访问日志,消息服务等等,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目. 主要应用场景是:日志收集系统和消息系统. Kafka主要设计目标如下: 以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能.