数据冥等性

1，幂等：多次调用对系统的产生的影响是一样的，即对资源的作用是一样的，但是返回值允许不同。

幂等场景

我们来看一下SQL相关业务是否幂等？

一、查询，select * from user where xxx，不会对数据产生任何变化，具备幂等性。

二、新增，insert into user(userid,name) values(1,'a')，

如userid为唯一主键，即重复操作上面的业务，只会插入一条用户数据，具备幂等性。

如userid不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性。

三、修改，区分直接赋值和计算赋值。

1、直接赋值，update user set point = 20 where userid=1，不管执行多少次，point都一样，具备幂等性。

2、计算赋值，update user set point = point + 20 where userid=1，每次操作point数据都不一样，不具备幂等性。

四、删除，delete from user where userid=1，多次操作，结果一样，具备幂等性。

上面场景中，我们发现新增没有唯一主键约束的数据，和修改计算赋值型操作都不具备幂等性

token机制：

主要思想：

1、服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。（微服务肯定是分布式了，如果单机就适用jvm缓存）。

2、然后调用业务接口请求时，把token携带过去，一般放在请求头部。

3、服务器判断token是否存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的token删除。

4、如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行。