一、概述
- 一次和多次请求某一个资源应该具有相同的副作用。
1. 服务间调用状态
-
把系统解耦后，服务间的调用三个状态
- 成功 success
- 失败 failed
- 超时 timeout， 超时完全不知道是什么状态
- 假如超时 是网络传输丢包的问题
- 可能是请求时就没有请求到
- 可能是请求到了，返回结果时没有正常返回等等情况。
- 假如超时 是网络传输丢包的问题
-
因为系统超时，而调用方重试一下，会给我们的系统带来不一致的副作用。
- 两种处理方式
- 一种是需要下游系统提供相应的查询接口。
- 上游系统在timeout 后去查询一下。
- 查到了，表明做了，成功了就不用做了， 失败了就走失败流程
- 上游系统在timeout 后去查询一下。
- 一种是通过幂等性的方式。
- 这个查询操作交给下游系统，上游系统只管重试，下游系统保证一次和多次的请求结果是一样的。
- 一种是需要下游系统提供相应的查询接口。
- 两种处理方式
二、幂等性的方式
1. 全局ID
- 要做到幂等性的交易接口，需要一个唯一的标识，来标志交易是同一笔交易。
- 全局id 参考 全局id 的文章。
2. 处理流程
1. 流程
- 是需要一个存储来记录收到的交易。
- 当收到交易请求的时候，我们回到这个存储中去查询
- 如果查到了就不再做操作。并把上次做的结果返回。
- 如果没有查到，那么我们就记录下来。
- image.png
2 问题
- 上面流程有个问题，28定律，80%的请求都是正常的，让100%的请求都到这个存储里去查一下，这会导致处理流程变的很慢。
2.1 解决
- 最好是当这个存储出现冲突的时候会报错，
- 我们收到交易请求后，直接去存储里记录这个 ID（相对于数据的 Insert 操作），如果出现 ID 冲突了的异常，那么我们就知道这个之前已经有人发过来了，所以就不用再做了。
- 假如是mysql数据库中你可以使用 insert into … values … on DUPLICATE KEY UPDATE … 这样的操作
CREATE TABLE unique_table
(
id bigint DEFAULT 0 NOT NULL
CONSTRAINT `PRIMARY`
PRIMARY KEY,
type varchar(50) NULL,
state int DEFAULT 0 NOT NULL
);
insert into unique_table values (2,'订单系统',1) on DUPLICATE KEY UPDATE state = state + 1 ;
# 第一次操作 1 row affected in 19 ms
# 第二次操作 2 rows affected in 15 ms
根据 row的值不同，判断值是否有
- 假如是更新的场景
update table set status = “paid” where id = xxx and status = “unpaid”;
- 网上还有 MVCC 通过使用版本号等其他方式，我觉得这些都不标准，我们希望我们有一个标准的方式来做这个事，所以，最好还是用一个 ID。
3. 存储
- 因为幂等性服是分布式的，所以需要存储也是共享的。
- 这样每个服务就变成没有状态的了。但是，这个存储就成了一个非常关键的依赖，其扩展性和可用性也成了非常关键的指标。
- 你可以使用关系型数据库，或是 key-value 的 NoSQL（如 MongoDB）来构建这个存储系统。
3. HTTP 的幂等性
1. http 常见方法的幂等性
image.png
HTTP GET 方法用于获取资源，不应有副作用，所以是幂等的
-
HTTP HEAD 和 GET 本质是一样的，区别在于 HEAD 不含有呈现数据，而仅仅是 HTTP 头信息，不应有副作用，也是幂等的
- 欲判断某个资源是否存在，我们通常使用 GET，但这里用 HEAD 则意义更加明确。也就是说，HEAD 方法可以用来做探活使用。
-
HTTP OPTIONS 主要用于获取当前 URL 所支持的方法，所以也是幂等的
- 若请求成功，则它会在 HTTP 头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
-
HTTP DELETE 方法用于删除资源，有副作用，但它应该满足幂等性。
- 比如：DELETE http://www.forum.com/article/4231，调用一次和 N 次对系统产生的副作用是相同的，即删掉 ID 为 4231 的帖子。因此，调用者可以多次调用或刷新页面而不必担心引起错误。
-
HTTP POST 方法用于创建资源，所对应的 URI 并非创建的资源本身，而是去执行创建动作的操作者，有副作用，不满足幂等性。
- 比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP 响应中应包含帖子的创建状态以及帖子的 URI。两次相同的 POST 请求会在服务器端创建两份资源，它们具有不同的 URI；所以，POST 方法不具备幂等性。
-
HTTP PUT 方法用于创建或更新操作，所对应的 URI 是要创建或更新的资源本身，满足幂等性
- 用于更新资源，没有的话则执行创建操作。每次执行请求时都会先判断一下序号为1的花信息是否存在，不存在则创建，否则视为更新。
HTTP PATCH 是对PUT方法的补充，用来对已知资源进行局部更新 , 不满足幂等性
-
TRACE 方法 实现沿通向目标资源的路径的消息环回（loop-back）测试，提供了一种实用的 debug 机制。
- 请求的最终接收者应当原样反射（reflect）它接收到的消息，除了以下字段部分，作为一个Content-Type 为 message/http 的 200（OK）响应的消息的主体（body）返回给客户端。
2. POST 方式不支持幂等性，的幂等性设计。
在表单中需要隐藏一个 token（可以前后端生成）
-
后端把用户提交的数据和这个 token 保存在数据库中
- 如果有重复提交，那么数据库中的 token 会做排它限制，从而做到幂等性。
更为稳妥的做法是，后端成功后向前端返回 302 跳转，把用户的前端页跳转到 GET 请求，把刚刚 POST 的数据给展示出来。如果是 Web 上的最好还把之前的表单设置成过期，这样用户不能通过浏览器后退按钮来重新提交。这个模式又叫做 PRG 模式（Post/Redirect/Get）。
3 . POST 方式不支持幂等性，常用方式
- 前端实现
- 点击提交， 按钮disable
- 后端
- 数据库唯一索引
- 适合场景
- 插入操作
- 适合场景
- 基于redis 实现一套幂等性防重框架
- 适合场景
- 更新操作，配合业务操作
- 步骤
- 用个拦截器，拦截所有参数， 参数拼接作为key去redis 判断下。
- 适合 系统参数比较规定。
- 先uuid 获取，然后操作成功删除。
- 用个拦截器，拦截所有参数， 参数拼接作为key去redis 判断下。
- 适合场景
- 数据库状态机
- 适合场景
- 更新操作
- 适合场景
- 通过锁实现
- 使用数据库实现幂等性
- 通过悲观锁来实现幂等性
- 通过唯一索引来实现幂等性
- 通过乐观锁来实现幂等性
- 使用 JVM 锁实现幂等性
- 使用分布式锁实现幂等性
- 使用数据库实现幂等性
- 数据库唯一索引
