oracle 幂等性问题

所谓幂等，简单地说，就是对接口的多次调用所产生的结果和调用一次是一致的。扩展一下，这里的接口，可以理解为对外发布的HTTP接口或者Thrift接口，也可以是接收消息的内部接口，甚至是一个内部方法或操作。

数学上的定义：f(f(x)) = f(x)。x被函数f作用一次和作用无限次的结果是一样的。幂等性应用在软件系统中，我把它简单定义为：某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一样的，在实际应用中一般针对于接口进行幂等性设计。举个栗子，在系统中，调用方A调用系统B的接口进行用户的扣费操作时，由于网络不稳定，A重试了N次该请求，那么不管B是否接收到多少次请求，都应该保证只会扣除该用户一次费用。

那么我们为什么需要接口具有幂等性呢？设想一下以下情形：

• 在App中下订单的时候，点击确认之后，没反应，就又点击了几次。在这种情况下，如果无法保证该接口的幂等性，那么将会出现重复下单问题。
• 在接收消息的时候，消息推送重复。如果处理消息的接口无法保证幂等，那么重复消费消息产生的影响可能会非常大。

我们的系统大多拆分为分布式SOA，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful，既然是通信，那么就有可能再服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！尤其再支付场景。

    在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。

    在增删改查4个操作中，尤为注意就是增加或者修改，

    查询对于结果是不会有改变的，

    删除只会进行一次，用户多次点击产生的结果一样

    修改在大多场景下结果一样

    增加在重复提交的场景下会出现

    那么如何设计接口才能做到幂等呢？

    方法一、单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：

1. 异步请求获取门票

2. 调用支付，传入门票

3. 根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返回结果；如果不存在，支付扣款，保存结果

4. 返回结果到客户端

    如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的.

    方法二、分布式环境下各个服务相互调用

    这边就要举例我们的系统了，我们支付的时候先要扣款，然后更新订单，这个地方就涉及到了订单服务以及支付服务了。

    用户调用支付，扣款成功后，更新对应订单状态，然后再保存流水。

    而在这个地方就没必要使用门票ticketId了，因为会比较闲的麻烦

    （支付状态：未支付，已支付）

    步骤：

    1、查询订单支付状态

    2、如果已经支付，直接返回结果

    3、如果未支付，则支付扣款并且保存流水

    4、返回支付结果

    如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

    对于做过支付的朋友，幂等，也可以称之为冲正，保证客户端与服务端的交易一致性，避免多次扣款。