幂等性原本是数学上的概念，即使公式：f(f(x)) =f(x)能够成立的数学性质。用在编程领域，则意为对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。幂等性是系统服务对外一种承诺，承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。比如我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统问题重发，也应该只扣一次钱，具体幂等处理流程如下图所示：
SQL中的幂等
SELECT col1 FROM tab1 WHER col2=1，无论执行多少次都不会改变状态，是天然的幂等。
UPDATE tab1 SET col1=1 WHERE col2=1，无论执行成功多少次状态都是一致的，因此也是幂等操作。
UPDATE tab1 SET col1=col1+1 WHERE col2=1，每次执行的结果都会发生变化，这种不是幂等的。
insert into user(userid,name) values(123456,'kevin') 如userid为唯一主键，即重复操作上面的业务，只会插入一条用户数据，具备幂等性。
如userid不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性。
delete from user where userid=123456，多次操作，结果一样，具备幂等性
HTTP方法中的幂等
HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。
- GET方法用于获取资源，不应有副作用，所以是幂等的。
- DELETE方法用于删除资源，有副作用，但它应该满足幂等性。例如：删掉id为123456的帖子，调用者可以多次调用或刷新页面而不必担心引起错误。
- POST方法不具备幂等性，两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI
- PUT方法具备幂等性，他所对应的URI是要创建或更新资源的本身，对同一URI进行多次PUT的副作用和一次PUT是相同的。
- PATCH不具备幂等性 他会将一组描述在请求实体里的更改应用到URI标志的资源。这组更改以 "补丁文档" 的格式表示，如果URI未指向现有资源，服务器可能根据补丁文档的类型和权限等来创建一个新资源。
测试角度看幂等
核心测试点包括：
- 用户重复提交
- 网络重发
- 消息重发
- 系统间重试
重点关注的内容如下：
1)需要关注业务性质和产品设计，是否需要做到幂等，是时间维度的幂等(即幂等对象的范围，是个人还是机构，是某一次交易还是某种类型的交易)还是空间维度的幂等(即幂等的保证时间，是几秒、几分钟还是永久性的)。
2)接口的幂等测试，在做接口测试时对每个接口都思考一下是否需要幂等。
3)业务场景，特别是涉及到钱的业务场景，对失败重试机制一定要验证。
