幂等专项测试分享

什么是幂等？

---

$$f(x)=f(f(x))$$

幂等性测试

---

同一个请求被执行一次与被执行多次的效果是一样的，服务器的状态也是一样的

为什么需要幂等？

---

接口调用在一般情况下不会重复提交，但在一些特殊情况下会出现重复提交的状况

用户重发
···
网络重发
···
系统重发
···
消息重发

---

幂等性多数场景运用在支付、订单、和分布式事务处理等

小明去华住定大床房
一间200
结果在付钱的时候因为网络不好系统提示支付失败
于是小明又付了一次钱
等付完钱后发钱钱被扣了两次！！

幂等的类型

---

幂等操作在底层无碍乎就是两种操作

$$1.插入：insert$$

$$2.更新：update$$

插入幂等

---

小明扣了两次钱，查询后台后发现有两个支付流水号（既网络不佳提示失败后又生成了新的支付流水号），导致小明同一个订单支付了2次

一般插入幂等多用于生成流水号

---

在确保流水号的唯一性的同时也要确保与上下游的一致性

没做幂等

---

小明

发起支付

第二次发起支付

生成流水号

生成流水号

支付

支付

如果小明的支付流水号由上游生成或使用全局流水号，就能在保证唯一性的时候发现已经存在该流水号，也就避免了重复插入的问题

做了幂等校验

---

小明

发起支付

第二次发起支付

插入上游传递的唯一流水号

插入上游传递的唯一流水号

支付

发现流水号已存在

查询并返回支付状态

幂等字段的设计

---

1.空间： 流水号的长度，是否需要带有信息¹

2.时间： 流水号需要保存多久？是否需要归档

更新幂等

---

小明想要挽回损失，对多付的订单发起退款申请

小明操作失误，同时点了2次退款申请

两次请求都成功了！

小明获得退款400

由于没有做幂等，导致小明赚了200

---

（罗翔老师：不当得利警告）

为何会有更新不幂等

---

1.未判断原始更新状态

2.事务的并发处理问题

会带来的问题

---

1.更新丢失

2.脏读

3.幻读

4.不可重复读

更新丢失

---

请求T1和请求T2同时进行操作处理，T2提交的结果覆盖T1提交的结果，T1的修改记录被丢失

更新丢失场景

---

小明 退款 银行 发起退款申请 第一次发起退款 查询状态 可以退款 发起退款申请 第二次发起退款 查询状态 可以退款 更新状态 第一次更新退款信息 退款成功 退款成功 更新状态 第二次更新退款信息,覆盖了第一次的信息 退款成功 退款成功 小明 退款 银行

脏读场景

---

A事务读取B事务尚未提交的数据
此时如果B事务发生错误并执行回滚操作
那么A事务读取到的数据就是脏数据

脏读

---

小明 银行 退款 去取钱100 假设小明银行存款500 银行存款-100,余额400 查询小明余额 余额400 取款服务异常，取款失败,取款回退，余额500 取钱失败，余额500 转入200 转入成功，余额600 脏读的400 + 转入200 转账成功 此时小明余额只有600，正常逻辑应为700 小明 银行 退款

幻读和不可重复读

---

幻读和不可重复读的概念有点类似于脏读

幻读：一个事务查询2次，得到的记录条数不一致

不可重复读：一个事务查询同一条记录2次，得到的结果不一致

总结

---

对于现在的系统而言
网络通讯是需要时间的并且其本身并不十分可靠
而幂等就是保证一致性的重要方法
幂等性测试也是验证数据一致性的重要一环

$$Thanks$$

---

1. 商户信息+流水号；商户信息+时间+流水号；商户+时间+类型+流水号 ↩︎