幂等性设计

1、概念

任意多次执行产生的影响与一次执行产生的影响相同，无 副作用。

幂等函数/幂等方法==使用相同参数重复执行并可以获取相同结果的函数

2、幂等

2.1、API接口

API接口响应情况：成功、失败、超时

幂等多发于超时后的上游发起的重试，下游应保证”同一请求重复执行多次对系统造成的影响相同“。

幂等设计

• 上游在请求信息中添加全局唯一属性供下游判重/下游下发全局唯一属性值，供上游交互前获取，供下游做幂>等验证

• 下游提供结果/状态查询接口，异常时上游可通过查询接口获取实时结果/状态

• 业务上：状态机限定

• 实现上
  1、update：乐观锁更新机制；悲观锁 select for update
  2、insert：数据库唯一索引兜底---->分库分表？---->分布式锁

2.2、HTTP

Get：幂等。http://hl.com/activity/1 获取资源。资源本身不会因为Get 请求而受到影响、改变。

Delete：幂等。http://hl.com/activity/delete/1 删除id为1的资源。删除本身造成的影响--资源1被删除，无论执行多少次，影响都是相同的--->删除id为1的资源。

POST：非幂等。 http://hl.com/activity/create 创建一个资源。多次请求会创建多个资源，所以是非幂等的。

幂等设计

token 下发，防止表单重复提交。

2.3 数据库

select：幂等。查到地球🌎爆炸💥也不会导致数据改变。

update：

1、update B set name='hl' 非幂等。记录数量不一样，update 影响有所不同。

2、update B set version=version+1 where id=1 and version=${version} 幂等。多次执行造成影响相同--->将id为的1且version 等于当前version 的记录，version+1 。

insert：

1、unique index idx_u_name ('name') ; insert into user values (null,'hl'); 幂等。多次执行插入，最终只能插入一条。

2、no index；insert into user values (null,'hl'); 非幂等。多次执行插入，会重复。

幂等设计

1、乐观锁更新机制
2、唯一索引

3、i tell you

nice to meet all you guys 。

幂等==多次请求响应报文相同？

多次请求是否返回相同的结果不属于幂等定义范围内。这个可以上下游约定

• ①下游提供查询接口，当发生超时情况下上游调用查询接口获取下游处理结果

• ②下游在内部实现处理前查询，若查询到结果直接返回上游

推荐：① 因为超时属于低概率事件，大多数非超时场景对DB的查询对CPU、网络、IO 等资源是不必要的浪费。

若实际场景对由DB做幂等防重，异常情况下上游重试会导致DB大量duplicate 报错，如果对此SQL 异常不能容忍就设计成 select insert 模式幂等，即：插入前先查询。