程序接口幂等性设计
接口幂等性是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
这类问题多发于接口的：
insert操作，这种情况下多次请求，可能会产生重复数据。
update操作，如果只是单纯的更新数据，比如：update user set status=1 where id=1，是没有问题的。如果还有计算，比如：update user set status=status+1 where id=1，这种情况下多次请求，可能会导致数据错误。
1. insert前先select
2. 加悲观锁
update user amount = amount-100 where id=123;
select * from user id=123 for update;
需要特别注意的是：如果使用的是mysql数据库，存储引擎必须用innodb，因为它才支持事务。此外，这里id字段一定要是主键或者唯一索引，不然会锁住整张表。
3. 加乐观锁
既然悲观锁有性能问题，为了提升接口性能，我们可以使用乐观锁。需要在表中增加一个timestamp或者version字段，这里以version字段为例。
select id,amount,version from user id=123;
update user set amount=amount+100,version=version+1 where id=123 and version=1;
4. 加唯一索引
alter table `order` add UNIQUE KEY `un_code` (`code`);
加了唯一索引之后，第一次请求数据可以插入成功。但后面的相同请求，插入数据时会报Duplicate entry '002' for key 'order.un_code异常，表示唯一索引有冲突。
如果是java程序需要捕获：DuplicateKeyException异常，如果使用了spring框架还需要捕获：MySQLIntegrityConstraintViolationException异常。
5. 建防重表
有时候表中并非所有的场景都不允许产生重复的数据，只有某些特定场景才不允许。这时候，直接在表中加唯一索引，显然是不太合适的。
该表可以只包含两个字段：id 和 唯一索引，唯一索引可以是多个字段比如：name、code等组合起来的唯一标识，例如：susan_0001。
6. 根据状态机
update `order` set status=3 where id=123 and status=2;
主要特别注意的是，该方案仅限于要更新的表有状态字段，并且刚好要更新状态字段的这种特殊情况，并非所有场景都适用。
7. 加分布式锁
其实前面介绍过的加唯一索引或者加防重表，本质是使用了数据库的分布式锁，也属于分布式锁的一种。但由于数据库分布式锁的性能不太好，我们可以改用：redis或zookeeper。
鉴于现在很多公司分布式配置中心改用apollo或nacos，已经很少用zookeeper了，我们以redis为例介绍分布式锁。
目前主要有三种方式实现redis的分布式锁：
setNx命令
set命令
Redission框架
具体步骤：
用户通过浏览器发起请求，服务端会收集数据，并且生成订单号code作为唯一业务字段。
使用redis的set命令，将该订单code设置到redis中，同时设置超时时间。
判断是否设置成功，如果设置成功，说明是第一次请求，则进行数据操作。
如果设置失败，说明是重复请求，则直接返回成功。
需要特别注意的是：分布式锁一定要设置一个合理的过期时间，如果设置过短，无法有效的防止重复请求。如果设置过长，可能会浪费redis的存储空间，需要根据实际业务情况而定。
8. 获取token
第一次请求获取token
第二次请求带着这个token，完成业务操作。
服务端生成token，保存到redis中，然后返回给浏览器。
用户通过浏览器发起请求时，携带该token。
在redis中查询该token是否存在，如果不存在，说明是第一次请求，做则后续的数据操作。
如果存在，说明是重复请求，则直接返回成功。
在redis中token会在过期时间之后，被自动删除。
需要特别注意的是：token必须是全局唯一的。