Appearance
注意：接口幂等性根据业务决定，不要盲目使用
1、接口设计与重试机制引起的问题。 1、提交订单按钮如何防止重复提交？ 2、表单录入页如何防止重复提交 3、微服务接口，客户端重试时，会对业务数据产生影响吗？ 2、什么是幂等性？ 幂等性的公式：f(f(x))=f(x)
- 幂等元素运行多次，还等于它原来的运行结果
- 在系统中，一个接口运行多次，与运行一次的效果是一致的
3、什么情况需要幂等性？
- 重复提交
- 接口重试
- 前端操作
4、业务场景？
- 用户多次点击提交订单，后台应该只生成一个订单，不应该产生多个订单，保证订单的唯一
- 支付时，由于网络问题重复，应该只扣一次钱
5、幂等性设计的核心思想。
- 通过唯一的业务单号保证幂等。
6、如何实现接口幂等？
- 非并发情况下，查询业务单号有没有操作过，没有则执行操作
- 并发操作下，整个过程加锁
7、select，delete，insert，update和混合操作的接口幂等性。 Select：不会对业务数据有影响，天然幂等 Delete：第一次已经删除，第二次也不会有影响 Insert：没有唯一业务单号，使用Token保证幂等 Update：更新操作传入版本号，通过乐观锁实现幂等性 混合操作：找到操作的唯一业务单号，有则可使用分布式锁，无则可以通过Token保证幂等。 8、Delete操作的幂等性
- 根据唯一业务号
- 第一次删除时，已将数据删除
- 第二次再次执行时，由于找不到记录，所以返回的结果是0，对业务数据没有影响。可在删除前进行数据的查询。
- 删除操作没有唯一业务号，则要看具体的业务需求
- 列如：删除所有审核未通过的商品
- 在第一次执行，将所有未通过审核的商品删除。
- 在第二次执行前，又有新的商品未审核通过
- 执行第二次删除操作，新的未审核通过的商品要不要删除？（这个）
- 列如：删除所有审核未通过的商品
9、Update操作的幂等性
- 根据唯一业务号去更新数据
- 用户查询出要更新的数据，系统将数据返回页面，将数据版本号放入隐藏域
- 用户更新数据，点击提交，将版本号一起提交给后台
- 后台使用版本号作为更新条件
- update table set version=version+1 ... where id=xxx and version=$
- 使用乐观锁与update行锁，保证幂等
- 更新操作没有唯一业务号，可使用Token机制
10、Insert操作的幂等性
- 有唯一业务号的insert操作，列如：秒杀，商品ID+用户ID
- 可通过分布式锁，保证接口幂等
- 业务执行完成后，不进行锁释放，让其过期自动释放
- 没有唯一业务ID的Insert操作，比如用户注册，点击多次
- 使用Token机制，保证幂等性
- 进入到注册页时，后台统一生成Token，返回前端隐藏域中
- 用户在页面点击提交时，将Token一同传入后台
- 使用Token获取分布式锁，完成Insert操作
- 执行成功后，不释放锁，等待过期自动释放
11、混合操作的幂等性
- 混合操作，一个接口包含多种操作
- 通用可以使用token机制