java接口的幂等性（支付业务的幂等）

本文目录

• 支付业务的幂等
• Java高并发响应接口怎么实现
• 什么是接口幂等性
• 幂等性是什么意思
• 接口的幂等性
• 如何判断请求的幂等性 java
• JAVA中Get和Post请求的区别收集整理
• java里面怎么让异常数据丢失

支付业务的幂等

听到幂等性这个词时，是不是内心一阵恐慌？What？幂等性是个什么鬼？测过相关支付的业务，但没听过幂等性啊？别方，其实就是数据一致性和事务完整性。

什么是幂等

数学上的定义：f(f(x))=f(x)。x被函数f作用一次和作用无限次的结果是一样的。幂等性应用在软件系统中，可以把它简单定义为： 某个函数或者某个接口使用相同参数调用一次或者无限次****，其造成的后果是一致的****， 在实际应用中一般针对于接口进行幂等性设计。例如：

为什么要做幂等

如上文问题一中示例所述，可知，如果支付相关接口不保证幂等性。可能会造成很严重的后果，例如：

所以说保证接口的幂等性是非常重要的。

如何保证幂等性

幂等需要 通过唯一的业务单号 来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。 下面以支付为例，在不考虑并发的情况下，实现幂等很简单：①先查询一下订单是否已经支付过；②如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。

防重复提交策略

上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。在高并发下就会出现下面的情况：第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。既然得出了这个结论，余下的问题也就变得简单：把查询和变更状态操作加锁，将并行操作改为串行操作。

乐观锁

如果只是更新已有的数据，没有必要对业务进行加锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。例如： UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version# 。但是，乐观锁存在失效的情况，就是常说的ABA问题。如果version版本一直是自增的就不会出现ABA的情况。

防重表

使用订单号orderNo做为去重表的唯一索引，每次请求都根据订单号向去重表中插入一条数据。第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，无论成功与否，执行完后更新订单状态为成功或失败，删除去重表中的数据。后续的订单因为表中唯一索引而插入失败，则返回操作失败，直到第一次的请求完成（成功或失败）。可以看出防重表作用是加锁的功能。

分布式锁

这里使用的防重表可以使用分布式锁代替，比如Redis。订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。通过Redis做到了分布式锁，只有这次订单支付请求完成，下次请求才能进来。相比去重表，将并发做到了缓存中，较为高效。思路相同，同一时间只能完成一次支付请求。

token令牌

这种方式分成两个阶段：申请token阶段和支付阶段。 第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到Redis缓存中，为第二阶段支付使用。 第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查Redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。 实际上这里的token是一个信物，支付系统根据token确认操作权限。缺点是需要系统间交互两次，流程较上述方法复杂一些。

支付缓冲区

把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。优点是同步转异步，高吞吐量。缺点是不能及时地返回支付结果，需要后续监听支付结果的异步返回。

Java高并发响应接口怎么实现

你先看看是否有重复的请求，如果有大量的重复请求的话，并且你的接口返回的响应是幂等的，那你可以在用缓存来挡掉大部分重复请求。之后再考虑把两个接口单独部署看看单机是否可以支持，如果单机不行，那只能把接口变成集群的，前面用nginx来做负载均衡，可以用ip hash或者round robin。还可以前面加队列来限制请求，这个就依赖你的业务需要，比如有些业务同时只能接受100个请求，那同时处理1000个请求也是没任何意义的。最终的方案还是依赖你的业务需要的决定的。

什么是接口幂等性

接口幂等性，一般是用在订单处理或者消费处理的场景的。使用接口幂等性是为了防止同一请求多次处理的状况。建议直接在百度中搜索接口幂等性，或者在csdn，博客园搜索下业务场景以及怎么来实现接口幂等性。希望可以帮住到你！

幂等性是什么意思

幂等性是什么意思介绍如下：

HTTP 幂等方法，是指无论调用多少次都不会有不同结果的 HTTP 方法。不管你调用一次，还是调用一百次，一千次，结果都是相同的。

HTTP GET 方法，用于获取资源，不管调用多少次接口，结果都不会改变，所以是幂等的。

只是查询数据，不会影响到资源的变化，因此我们认为它幂等。

值得注意，幂等性指的是作用于结果而非资源本身。怎么理解呢？例如，这个 HTTP GET 方法可能会每次得到不同的返回内容，但并不影响资源。

可能你会问有这种情况么？当然有咯。例如，我们有一个接口获取当前时间，我们就应该设计成

它本身不会对资源本身产生影响，因此满足幂等性。

HTTP POST 方法是一个非幂等方法，因为调用多次，都将产生新的资源。

因为它会对资源本身产生影响，每次调用都会有新的资源产生，因此不满足幂等性。

HTTP PUT 方法是不是幂等的呢？我们来看下

因为它直接把实体部分的数据替换到服务器的资源，我们多次调用它，只会产生一次影响，但是有相同结果的 HTTP 方法，所以满足幂等性。

HTTP PATCH 方法是非幂等的。HTTP POST 方法和 HTTP PUT 方法可能比较好理解，但是 HTTP PATCH 方法只是更新部分资源，怎么是非幂等的呢?

因为，PATCH 提供的实体则需要根据程序或其它协议的定义，解析后在服务器上执行，以此来修改服务器上的资源。换句话说，PATCH 请求是会执行某个程序的，如果重复提交，程序可能执行多次，对服务器上的资源就可能造成额外的影响，这就可以解释它为什么是非幂等的了。

接口的幂等性

在数学里， 幂等 有两种主要的定义。

在计算机领域，幂等性指 多次操作 对系统产生的影响 与一次操作相同。举个例子，假设要删除用户A，无论请求多少次，操作结果都是删除用户A，而不会删除用户B。 在RESTful风格的接口中，幂等性表现在HTTP请求方法中：

无论是微服务中各个子系统相互之间的调用，还是客户端对服务端的调用，都存在网络延迟等问题，会导致重复请求接口，这时候接口就需要支持幂等性，来防止出现问题。 最经典的一个例子就是订单支付操作，假如因为网络问题等因素导致用户重复提交，这时候不可能对用户重复扣款，否则客服电话就要被打爆了。 那么服务端接口对于幂等性应该如何支持呢？有如下两个思路：

1. 逻辑判断处理 支付时对订单状态进行判断，如果该订单已支付，则不应该再次进行扣款操作。

2. 请求带ticket 异步请求获取ticket，此ticket是唯一并且一次性的，保存在页面中，每次发起支付请求都带上ticket，后端检查ticket，若支付成功则删除ticket，这样就算重复提交也不会导致重复扣款。

如何判断请求的幂等性 java

x请求的报文头不一样，通过如下 Java代码 String requestType = request.getHeader("X-Requested-With"); 如果requestType能拿到值，并且值为XMLHttpRequest,表示客户端的请求为异步请求，那自然是ajax请求了，反之如果为null,则是普通的请求

JAVA中Get和Post请求的区别收集整理

一 原理区别

一般在浏览器中输入网址访问资源都是通过GET方式；在FORM提交中，可以通过Method指定提交方式为GET或者POST，默认为GET提交

Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE

URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询 资源信息，而POST一般用于更新 资源信息(个人认为这是GET和POST的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异 )。

根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的 。

1.所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。

* 注意：这里安全的含义仅仅是指是非修改信息。

2.幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等 这个概念：

幂等 （idempotent、idempotence）是一个数学或计算机学概念，常见于抽象代数中。幂等有以下几种定义：对于单目运算，如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的，那么我们就称该运算是幂等的。 比如绝对值运算就是一个例子，在实数集中，有abs(a) = abs(abs(a)) 。对于双目运算，则要求当参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最大值的函数，有在实数集中幂等，即max(x,x) = x 。

看完上述解释后，应该可以理解GET幂等的含义了。

但在实际应用中，以上2条规定并没有这么严格。引用别人文章的例子：比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即可。

根据HTTP规范，POST表示可能修改变服务器上的资源的请求 。继续引用上面的例子：还是新闻以网站为例，读者对新闻发表自己的评论应该通过POST实现，因为在评论提交后站点的资源已经不同了，或者说资源被修改了。

上面大概说了一下HTTP规范中，GET和POST的一些原理性的问题。但在实际的做的时候，很多人却没有按照HTTP规范去做，导致这个问题的原因有很多，比如说：

1.很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。

2.对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。

3.另外一个是，早期的但是Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计 。还有一个较为严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。

* 简单解释一下MVC：MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。

以上3点典型地描述了老一套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST(Representational State Transfer)，一套支持HTTP规范的新风格，这里不多说了，可以参考《RESTful Web Services》。

二 表现形式区别

搞清了两者的原理区别，我们再来看一下他们实际应用中的区别：

为了理解两者在传输过程中的不同，我们先看一下HTTP协议的格式：

HTTP请求：***隐藏网址******隐藏网址***《blank line》             // 回 车 换行***隐藏网址***

在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。在首部之后是一个空行，再此之后可以添加任意的其他数据。

GET与POST方法实例：

GET /books/?sex=man&name=Professional HTTP/1.1Host: www.wrox.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1Connection: Keep-AlivePOST / HTTP/1.1Host: www.wrox.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1Content-Type: application/x-www-form-urlencodedContent-Length: 40Connection: Keep-Alive（----此处空一行----）name=Professional%20Ajax&publisher=Wiley

有了以上对HTTP请求的了解和示例，我们再来看两种提交方式的区别：

（1）GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据

因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变

(2)传输数据的大小：首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。

而在实际开发中存在的限制主要有：

GET:特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系 统的支持。

因此对于GET提交时，传输数据就会受到URL长度的 限制。

POST:由于不是通过URL传值，理论上数据不受 限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

(3)安全性：

POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面 “安全”的含义仅仅是不作数据修 改，而这 里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击

***隐藏网址***1）get：请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全***隐藏网址***但是：它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。***隐藏网址***Content-type设置为: text/xml   任何数据都可以xml化

三 HTTP响应 1．HTTP响应格式：

***隐藏网址******隐藏网址***《blank line》            //回车换行***隐藏网址***

在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。 HTTP响应实例：

HTTP/1.1 200 OKDate: Sat, 31 Dec 2005 23:59:59 GMTContent-Type: text/html;charset=ISO-8859-1 Content-Length: 122 ＜html＞ ＜head＞  ＜title＞Wrox Homepage＜/title＞ ＜/head＞ ＜body＞＜!-- body goes here --＞＜/body＞＜/html＞

2．最常用的状态码有：

◆200 (OK): 找到了该资源，并且一切正常。◆304 (NOT MODIFIED): 该资源在上次请求之后没有任何修改。这通常用于浏览器的缓存机制。◆401 (UNAUTHORIZED): 客户端无权访问该资源。这通常会使得浏览器要求用户输入用户名和密码，以登录到服务器。◆403 (FORBIDDEN): 客户端未能获得授权。这通常是在401之后输入了不正确的用户名或密码。◆404 (NOT FOUND): 在指定的位置不存在所申请的资源.

四 完整示例

例子：

HTTP GET 发送

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1Host: api.efxnow.comResponse :HTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-Length: length《?xml version="1.0" encoding="utf-8"?》***隐藏网址***《Success》boolean《/Success》《ErrorDescription》string《/ErrorDescription》《ErrorNumber》int《/ErrorNumber》《CustomerOrderReference》long《/CustomerOrderReference》《OrderConfirmation》string《/OrderConfirmation》《CustomerDealRef》string《/CustomerDealRef》《/objPlaceOrderResponse》

Http Post 发送

POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1Host: api.efxnow.comContent-Type: application/x-www-form-urlencodedContent-Length: lengthUserID=string&PWD=string&OrderConfirmation=stringResponse : HTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-Length: length《?xml version="1.0" encoding="utf-8"?》***隐藏网址***《Success》boolean《/Success》《ErrorDescription》string《/ErrorDescription》《ErrorNumber》int《/ErrorNumber》《CustomerOrderReference》long《/CustomerOrderReference》《OrderConfirmation》string《/OrderConfirmation》《CustomerDealRef》string《/CustomerDealRef》《/objPlaceOrderResponse》

SOAP 1.2 发送

POST /DEMOWebServices2.8/Service.asmx HTTP/1.1Host: api.efxnow.comContent-Type: application/soap+xml; charset=utf-8Content-Length: length《?xml version="1.0" encoding="utf-8"?》***隐藏网址***《soap12:Body》***隐藏网址***《UserID》string《/UserID》《PWD》string《/PWD》《OrderConfirmation》string《/OrderConfirmation》《/CancelOrder》《/soap12:Body》《/soap12:Envelope》Response : HTTP/1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: length《?xml version="1.0" encoding="utf-8"?》***隐藏网址***《soap12:Body》***隐藏网址***《CancelOrderResult》《Success》boolean《/Success》《ErrorDescription》string《/ErrorDescription》《ErrorNumber》int《/ErrorNumber》《CustomerOrderReference》long《/CustomerOrderReference》《OrderConfirmation》string《/OrderConfirmation》《CustomerDealRef》string《/CustomerDealRef》《/CancelOrderResult》《/CancelOrderResponse》《/soap12:Body》《/soap12:Envelope》

***隐藏网址***

2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 因为get设计成传输小数据，而且最好是不修改服务器的数据，所以浏览器一般都在地址栏里面可以看到，但post一般都用来传递大数据，或比较隐私的数据，所以在地址栏看不到，能不能看到不是协议规定，是浏览器规定的。3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。 没明白，怎么获得变量和你的服务器有关，和get或post无关，服务器都对这些请求做了封装4. get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 post基本没有限制，我想大家都上传过文件，都是用post方式的。只不过要修改form里面的那个type参数5. get安全性非常低，post安全性较高。 如果没有加密，他们安全级别都是一样的，随便一个监听器都可以把所有的数据监听到，不信你自己下一个监听网络资源的软件，

java里面怎么让异常数据丢失

通过幂等实现幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。