幂等性：提交多次的情况下，结果都一样。
比如数据库查询，可称为天然幂等性，即查询多次结果都一样，无需人为去做幂等性操作。
但是
update table set value=value+1 where id=1,每次执行的结构都会发生变化，不是幂等。
inter into table(id,name)values(1,‘name’),如id不是主键或者没有唯一索引，重复操作上面的业务，会插入多条数据，不具备幂等性；
用户多次点击保存按钮
用户保存成功后，返回上一页再次保存
微服务相互调用，由于网络原因，导致请求失败
一、token机制：
1、根据业务场景，判断哪些业务存在幂等性问题，在执行业务之前先获取token，将token缓存止redis中
2、调用业务接口时，将token携带过去，一般放在请求头，作为Auth认证
3、服务器判断token是否存在于redis中，存在表示第一次请求，然后删除token，继续执行业务
4、如果不存在，则表示反复操作，不执行业务逻辑，直接返回重复标志！结束
风险性：业务执行前删除还是后删除token？
如果是执行后删除，在业务执行中，未删除token，用户又点了请求进来，那么则无法保障幂等性。
如果是执行前删除，在分布式下，用户快速请求2次，这时2个请求同时到redis去获取token，对比成功，同时删除，同时执行业务，那么也无法保障幂等性。
so：使用执行前删除，在分布式情况下，获取，对比，删除必须确保原子性，所以要加分布式锁。
二、加锁
1、数据库锁
select * from table where … for update
2、业务层面加分布式锁
将获取、对比、删除作为一个原子性的操作加锁，处理完成后释放锁，确保串行操作。
三、约束
数据库唯一约束：通过主键、唯一索引，确保无法重复新增同一笔数据，这就能确保幂等性
