了解程序中的幂等性

最新推荐文章于 2024-07-04 09:33:01 发布

拯救世界的派大星

最新推荐文章于 2024-07-04 09:33:01 发布

阅读量927

点赞数 1

mtdg

本文链接：https://blog.csdn.net/m0_46266407/article/details/105487343

版权

【今日推荐】：为什么一到面试就懵逼！>>>

目录
1. 前言
2. 幂等的概念
3. 幂等应用场景
3.1 查询操作
3.2 删除操作
3.3 唯一索引
3.4 token机制
3.5 悲观锁
3.6 乐观锁
3.7 分布式锁
3.8 状态机幂等
3.9 系统对外API如何保证幂等
4. 总结

1.前言

我所在的公司是家互联网金融公司，因此开发程序经常和钱的交易打交道，而且金融性质的程序架构并非我们平时开发的集中式架构，不会出现单一进程，在单一进程里面我们完成一个方法的调用只存在两种状态，一种是成功一种是失败;而公司使用的是RPC通信，也就是我们常说的分布式架构，或者说是微服务化架构，即一个系统是由多个子模块或者多个子系统组成的。那么这就会存在各个子系统相互调用的场景。

在分布式架构，会涉及到远程通信，比如说云商通、银行接口、支付宝接口等等，这些接口会涉及三种状态，除了我们所说的成功和失败两种，还有一种未知状态，未知状态可能表示超时、网络延迟、数据包丢失等等。

那么这个数据的未知状态会导致我们调用端对这个结果是未知的，如果在这个未知的场景下，调用端或客户端再次重试去发起请求，也许这个请求对于服务端来说收到并且已经处理了，但是客户端不知道，所以它再次尝试发送多一次请求，那服务端就会收到两次请求，如果服务器端不做处理的话就会导致数据做了两次累加或者两次更新，这样就会发生非常大的影响。

比如支付场景：如果用户对同一个订单发起两次支付操作，那么这个时候服务端不去做相应的处理的话，它就会完成两笔扣款记录，那么这个地方就会造成用户的资金损失，这种情况是绝对不允许在互联网产品上出现的。

而幂等性就是用来解决这样的场景的。

2.幂等的概念

在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。

幂等函数，又或者叫幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数. 更复杂的操作幂等保证是利用唯一交易号(流水号)实现。

因此，幂等性简单来说就是用户对同一个操作发起多次请求以后，对于数据的影响的结果是不变的，一次请求跟N次请求的结果是一样的。

3.幂等应用场景

3.1 查询操作

当我们查询一次或多次，在查询条件和数据不变的情况下，查询结果是一致的。

3.2 删除操作

删除一次或多次都是把数据删除，对数据的操作只执行一次。

3.3 唯一索引

防止新增脏数据。

比如：

支付宝的资金账户，支付宝也有用户账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录。

注意：唯一索引或唯一组合索引来防止新增数据存在脏数据（对某一个关键的数据设置一个唯一索引，第二次请求过来的时候它没有办法正常入库，这时会抛出一个重复的异常，服务端可以捕获到这个异常，然后不作处理）

3.4 token机制

防止页面重复提交。

原理上通过session token来实现的。客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，Token会随着表单一起提交到服务器端。服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。

3.5 悲观锁

获取数据的时候加锁获取。

select * from table_xxx where id='xxx' for update;

注意：id字段一定是主键或者唯一索引，不然会锁表；悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，应该根据实际情况选用。

3.6 乐观锁

乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。

3.7 分布式锁

分布式系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多个系统，也就是分布式系统中得解决思路。

注意：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)；

3.8 状态机幂等

状态机是一种特殊的组织代码，它能够确保你的对象随时都知道自己所处的状态以及可以在这个状态下做出相应的可以做的事情。

在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

举例：发起支付的时候这个状态是支付中，后面有已支付和支付失败，状态随着业务的驱动而变化，那它是怎么实现幂等的呢？
如果请求的是修改操作，那么 update xxxx where status = 1，这就是说只有这个状态等于1的情况下才能修改，也说明当前的修改操作是因为某一场景才触发的，比如说原来的等待支付变成支付中，意味着这个支付中的状态必须是在等待支付的状态下才能去修改的，它的前置条件就是等待支付，这个就是使用状态机的方式去实现幂等。

3.9 系统对外API如何保证幂等

如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号；source+seq在数据库里面做唯一索引，防止多次付款(并发时，只能处理一个请求) 。
注意：对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统的话，即便会报错，但实际已经处理了。