【重复处理】CRUD接口幂等性处理

保证幂等性的核心思想：通过唯一的业务单号保证幂等

1. 非并发情况下，查询业务单号有没有操作过，没有则执行操作
2. 针对第一次执行业务时间，有大量并发情况下，整个操作过程加锁，通过分布式锁来加锁
3. Select操作：不会对业务数据有影响，天然幂等
4. Delete操作：第一次已经删除，第二次删除也不会有影响
   • 根据唯一的业务号删除，第一次删除时间，已将数据删除，第二次再次执行时间，由于找不到相应嘉璐，所以delete删除的结果式0，对业务数据没有影响，可在删除前进行数据库查询
   • 删除操作没有唯一业务号，则要看具体的业务需求，如删除未审核的数据，此时多次删除，可能会有新的未审核的数据，此时如果依然需要保证幂等性，就需要使用token机制来实现
5. Update操作：更新操作传入数据版本号，通过乐观锁实现幂等性
   • 更新操作如果每次都是相同的值，那么不需要保证幂等性，因为值一样
   • 更新的字段的值操作是变化的，那么就会有影响，此时就是通过传入版本号来实现

   update set version=version+1, xxx=${xxx} where id = xxx and version = ${version}
   

   上述语句在mysql执行时间，是有行锁的，是串行的，及时有多次提交，那么版本号不一致的情况下，也是无法完成update，即实现了幂等
6. Insert操作：此时没有唯一业务号的，使用Token保证幂等
   • 有唯一业务号的操作，例如：秒杀场景下，商品ID+用户ID必须是唯一的通过分布式锁，保证并发情况下只有一个请求能够生成记录，然后通过数据库的唯一索引控制数据商品ID+用户ID只能有一条记录，保证接口幂等，业务执行完后，不进行分布式锁释放，让其过期自动释放，重拾请求在锁失效前，获得不到锁，也就失败了
   • 没有业务号的操作，如注册、点击多次等，使用Token机制，保证幂等性，在进入到注册页时，后台统一生成Token，返回前台的隐藏域中。用户提交时间，将Token一同传入后台使用Token作为分布式锁的key来获取分布式锁，完成insert操作，执行成功后，不释放锁，等待过期自动释放，拿不到分布式锁的则无法进行操作