幂等性学习

幂等性大话题

幂等性的数学表达式：f(f(f(...))) = f(x)

类型解释

• 查询的幂等性

  • 查询操作，天然是幂等的，同样的数据，无论你查询多少次，都不会对数据造成改变。

• 更新的幂等性

  • 更新操作，可能存在重复更新的可能性，因此需要做其他的操作来保证幂等性，可以考虑使用数据version，行锁、分布式锁等来处理。

• 新增的幂等性

  • 新增操作，存在重复新增的可能性，可以在表中添加唯一索引或者联合唯一索引的方式来处理。

• 删除的幂等性

  • 删除操作，本身就是幂等的，无论删除多少次，参数相同的情况下，删除结果都是相同的。

REST 中的幂等操作

GET、PUT, DELETE 都是幂等操作，而POST 不是幂等操作；

分析

GET 请求，对资源做查询多次，此实现的结果都是一样的。

PUT 请求，将A修改为B，它第一次请求值变成了B，再进行过多次此操作，最终的结果还是B，与第一次执行的结果是一样的，所以PUT也是幂等操作。

DELETE请求，同理可得，第一次将资源删除后，后面多次进行此删除请求，最终结果是一样，资源删掉。

POST请求，因为一次请求添加一份新资源，二次请求则添加了两份新资源，多次请求会产生不同的结果，因此POST 不是幂等操作。

题外话，和分布式事务相比，幂等设计的优势在于它的轻量级，容易适应异构环境，以及性能和可用性方面。在某些性能要求比较高的应用，幂等设计往往是唯一的选择。

HTTP幂等 N > 0

HTTP 协议本身是一种面向资源的应用层协议，

对HTTP协议的使用实际上存在着两种不同的方式：

**一种是Restful的,**它把HTTP当成应用层协议，比较遵守了HTTP协议的各种规范；

**另一种是SOA（面向服务架构）的，**它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立自己的应用层协议。

无论是SOA还是RESTful的web API设计都应该考虑幂等性。

拓展了解

唯一索引，可以防止新增脏数据

比如：唯一索引或唯一组合索引来防止新增数据存在脏数据，

当表中存在唯一索引，并发时新增报错时，再查下一次就可以了，数据应该已经存在了，返回结果即可。

穷举业务场景：

账户资金记录操作，创建资金账户操作，创建存管账户操作，促销活动返现，发券操作等。

Token机制，防止页面重复提交

集群环境：采用token加redis，因为redis是单线程的，处理需要排队

单JVM环境：才有token加redis或token加jvm内存

处理流程：

1.数据提交前要向服务端申请token，然后把token放到redis或jvm内存中，设置token有效时间

2.提交后先进行校验token，同时删除token，生成新的token返回

Token feature：

要申请一次有效性，可以限流。

注意redis要用删除操作来判断token，删除成功代表token验证通过，如果用select+delete来校验token，存在并发问题，不建议使用。

悲观锁：

获取数据的时候加锁获取

select * from table where id = xxx for update; //添加行锁

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

乐观锁：

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

乐观锁的实现方式多种多样可以通过version或者其他状态条件：

1.通过版本号实现

update table set name=#name#,version=version+1 where version = #version#

2.通过条件限制

update table set avail_amount = avail_amount-#tenderAmount# where avail_amount-#tenderAmount# >= 0;

或

update table set avail_product = avail_product-#buyProduct# where avail_product-#buyProduct# >= 0; //防止超卖

这个情景，只更新是做数据安全校验，适合库存模型，扣库存和回滚库存，性能更高。

注意：乐观锁的更新操作，最好用主键或唯一索引来更新，这样是行锁，否则更新时会锁表，上面两个sql应该优化成行锁。

update table set name=#name#,version=version+1 where id=#id# and version = #version#;

update table set avail_amount = avail_amount-#tenderAmount# where id=#id# and avail_amount-#tenderAmount# >= 0;

继续拓展

分布式锁：

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

要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志如用户mbId+后缀获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁。

select + insert 方式

并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方式是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了。

注意：核心高并发流程不要用这种方法。

状态机幂等

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

注意：订单等单据类业务，存在很长的状态流转，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助。

业务分析

对外提供接口的api如何保证幂等

银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，sequence序列号，source+sequence在数据库里面做唯一索引，防止多次付款，并发时，只能处理一个请求。

重点：对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号sequence，这两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。

注意：为了幂等，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际上已经处理了。

SOA 重复消息幂等设计

重复消息是SOA服务实现中非常常见的问题，永远不要指望调用方每次请求消息都不一样，对于查询操作，重复消息可能无害，可对于写操作可能就是惊天大BUG。

可以通过幂等模式处理重复的消息，基本处理思路是:

• 1、调用这给消息一个唯一请求ID标识。ID标识一个工作单元，这个工作单元只应该执行一次，工作单元ID可以是Schema的一部分（个人理解请求参数），也可以是一个定制的SOAP Header（请求头Head）,服务调用的约定是这个唯一请求ID标识是必传的；
• 2、接收者在执行一个工作单元必须先检验该工作单元是否已经执行过。检查是否执行的逻辑通常是根据唯一请求ID，在服务端查询请求是否有记录，是否有对应的响应信息，如果有，直接把响应信息查询后返回，如果没有，那么就当做新请求去处理。