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 模式幂等，即：插入前先查询。
网友评论