我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果的。
幂等性的概念
幂等(Idempotent)是一个数学与计算机学的概念,常见于抽象代数中。
在编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行,并能获得相同结果的函数/方法。这些函数/方法不会影响系统状态,因此不用担心重复执行会对系统造成改变。例如:
1.前端重复提交选中的数据,后台也只会产生对应这个数据的一个反应结果。
2.用户发起一笔付款请求,就应该只扣用户一次钱,即使遇到网络重发或系统bug重发请求,也应该之扣一次钱。
3.发送验证短息也应该只发一次,同样的验证短信不应该发送多次。
4.创建业务订单,一个业务请求只能创建一个业务订单,创建多个就会出大问题。
这些等等很多的业务逻辑都需要幂等的特性来支持。
简单来理解就是,幂等就是一个操作,这个操作不管执行多少次,产生的效果和返回的结果都是一样的。比如说有一个getOne()函数,无论执行这个函数多少次,它返回的都是1,这时就可以说它是一个幂等函数。
幂等性的技术方案
1.查询操作
查询一次和查询多次,在数据不变的情况下,查询结果是一样的。select是天然的幂等操作。
2.删除操作
删除操作也是幂等的,删除一次和删除多次都是把数据删除。但是要注意的是,删除操作返回的结果可能是不一样的。如果删除的数据不存在,返回0;如果删除多条数据,可能返回多个结果。
3.建立唯一索引,防止新增脏数据
当表存在唯一索引,并发时新增重复记录就会报错,那么这时候就查询已存在的记录并返回即可。
4.Token机制,防止页面重复提交
页面数据只能够提交一次,但是由于出现重复点击或者网络重发或Nginx重发等情况导致数据被重复提交的情况下,可以采用Token+Redis(Redis是单线程的,处理需要排队)的解决方案。处理的流程是,在数据提交前要向服务器申请带有有效事件的Token,然后Token放到Redis或JVM内存中,然后数据正式提交到后台要校验Token并删除Token。
5.悲观锁
获取数据的时候加锁获取:
select * from table where id = 'xxx' for update;
要注意的是,id字段一定要是主键或者唯一索引,否则会导致锁表。
悲观锁的使用一般伴随事务一起使用,数据锁定事件可能会很长,要根据实际情况慎用。
6.乐观锁
乐观锁只是在更新数据的那一刻锁表,其他时间不锁表,所以相对于悲观锁效率更高。
乐观锁的实现方式多种多样,可以通过version或者其他状态条件。
7.分布式锁
还是拿插入数据的例子,如果是分布式系统,构建全局唯一索引比较困难,例如唯一性的字段无法确定。那么这时候就可以引入分布式锁,通过第三方的系统(Redis或Zookeeper),在业务系统插入数据或更新数据,获取分布式锁,然后做操作,之后再释放锁。这样其实是把多线程并发锁的思路引入了多个系统,也就是分布式系统中的解决思路。
要注意的是,某个长流程处理过程要求不能并发执行,可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁,其他流程执行时获取锁就会失败,也就是同一时间该流程只能有一个能执行成功,执行完成后,释放分布式锁(分布式锁要第三方系统提供) 。
8.select+insert
并发不高的后台系统,或者一些任务Job,为了支持幂等,支持重复执行,简单的处理方法是先查询下一些关键数据,判断是否已经执行过,在进行业务处理就可以了。但是要注意的是核心高并发流程不要用这种方法。
9.状态机幂等
在设计单据相关的业务,或者是任务相关的业务,肯定会涉及到状态机(状态变更图),就是业务单据上面有个状态,状态在不同的情况下会发生变更,一般情况下存在有限状态机,这时候,如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。
要注意的是,订单等单据类业务,存在很长的状态流转,一定要深刻理解状态机,对业务系统设计能力提高有很大帮助。
10.对外提供接口的api如何保证幂等
如银联提供的付款接口:需要接入商户提交付款请求时附带source来源和seq序列号。这时可以使用source+seq在数据库里面做唯一索引,防止多次付款,(并发时,只能处理一个请求) 。
对外提供接口为了支持幂等调用,接口有两个字段必须传,一个是来源source,一个是来源方序列号seq,这个两个字段在提供方系统里面做联合唯一索引,这样当第三方调用时,先在本方系统里面查询一下,是否已经处理过,返回相应处理结果;没有处理过,进行相应处理,返回结果。注意,为了幂等友好,一定要先查询一下,是否处理过该笔业务,不查询直接插入业务系统,会报错,但实际已经处理了。
总结
幂等性应该是一个合格程序员的基因,在设计系统的时候一定要考虑进去,尤其是像支付宝、银行、互联网金融公司等涉及的都是钱的系统,即要高效,数据也要准确,所以不能出现多扣款、多打款等问题,不然这样会很难处理,用户体验也不会好。
"人生不能一直隔岸观火,要么积极灭火,要么欲火重生。"