系统接口幂等性设计探究

前言：

刚开始工作的时候写了一个带UI页面的工具，需要设计登录功能，登录功能也很简单，输入用户名密码点击登录，触发后台查询并比对密码，如果登录成功则返回消息给前端，前端把消息弹出提示一下。后来发现如果短时间内双击一下登录按钮则会提示两次登录成功，只要手快，点几下就弹出几次登录成功。后来随着工作的时间的增长，知识也开始慢慢积累，发现这种场景就是一个典型的幂等性问题。前面的例子如果多次点登录，提示多次那还没有问题，但是如果后台还要记录一些登录信息，比如登录时间，登录次数…，那没有幂等性判断则会在后台记录多次登录信息。

幂等性是什么

就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

目前的解决方案

1、补偿式

我目前所处的团队就是使用的这种方式。由于涉及账务业务，因此涉及很多的充值，而充值一般都会使用各大银行、或者第三方支付（微信、支付宝）和现金。这些银行或者第三方支付平台都会提供对账文件（支付平台的收支）给我们，程序会自动比对系统当天收支与银行（平台）收支情况，如果发现不平衡，分两种情况，一种是补到账，另一种则是拉资金（改用户的帐户余额）。如果发生现金充值因柜员操作不当，双击了充值导致系统多到账，这种一般直接拉资金处理。这种补偿式的方案，虽然存在幂等性问题，但是会保证系统的最终一致性，最终通过纠错的机制来保证幂等。

2、基于TOKEN机制

这种机制也是我了解到的目前各公司的主流操作，例如：用户通过UI界面进行充值，当发起充值后，前台首先会去后台获取token,同时后台记录token信息到存储介质中（数据库、redis、jvm内存等）随后前台携带token去请求后端，后端接收到请求后先比对token,然后处理业务最后删除存储介质中的token信息（删除token的顺序视情况而定）。如果柜员操作不当双击了充值，那么第二次充值携带token到后端，此时后端已经没有了token信息，所以第二次充值不做处理。这样就保证了幂等。

3、前端防重

第三种方式比较简单，比如前言中提到的登录，第一次点击之后，将登录按钮设置为不可用，这样也可以保证幂等，但是这种是不推荐的。因为可以通过抓包的方式直接调用接口发起请求

总结

以上几个是我了解或者说是接触过的几个幂等性解决方案，各有利弊，就补偿式的而言是我最熟悉的，但是我发现几个其中的不足之处和优点：
不足之处：
1、就提到的案例而言，用户感知度比较大，很容易引起投诉。
2、就充值而言，需要第三方平台配合，如果是个人很可能拿不到这种对账的文件。
3、如果没有主键或者其他唯一性约束的表涉及表数据变更的，不容易稽核。

优点：
1、一个字简单，就是完全不考虑嘛，然后通过异步去稽核，不需要引入其他组件或者流程。