数据重复问题

• 背景

没有做单点登录或由于网络原因或前端卡顿原因，会出现同一个接口请求两次或多次的情况。造成后台出现两条或多条完全相同(除了一些自动生成的字段，如：uuid等)的数据。

• 解决构思：
  1. 前端部分
     前端设置提交一次之后，提交按钮置灰，不允许再次提交，
     设置短时间内不允许多次提交操作
  2. 后端部分
     synchronized： 只允许一个线程进入特定的代码块/方法/静态方法/类。
     –这种方式不适用于分布式架构，他的核心就是内存共享。多进程的情况下，分布在不同服务器上，就不存在什么内存共享了。
     lock： Java可自定义锁接口。灵活性比synchronized高；synchronized是在jvm层面上的，lock实在Java代码模块上的。

分布式锁： 多服务器多进程，用上面两种锁形式已经不能满足我们需求，就会采用分布式锁的形式
分布式锁的三种实现方式；
核心思想：一个方法在同一时间只能被一个机器的一个线程执行

1. 数据库
   在数据中创建一张表,具体如下图所示。
   基本构思：每执行一个方法,就在表中插入一条数据，当然，方法名字段具有唯一性；当该方法执行完毕之后在删除该条数据。
   

• 需要思考问题：

  • 数据库宕机问题。当执行某一方法突然宕机，但是数据插入成功。这就直接导致后来的数据插入不进入，方法无法执行。----(可以创建一定时任务，规定时间内扫描表数据，当某一方法创建时间距离当前时间过长，定时删除该条数据)
  • 不具备锁的特性。当访问某一方法，该方法正在被其他的线程调用，当前的线程不会等待锁数据的释放。-----(可手动写for循环调用方法，存在很大弊端/可手动创建等待时间)
  • 性能问题。不管是代码量还是数据的数据量，都会花费时间去维护， 这种方式依赖数据库比较高，要考虑数据库的性能问题(双机部署/数据同步/主备切换)。

2. 缓存(以Redis为例)
   基本构思：某一方法一key，设置一超时时间(根据自己的业务需求而定，这个没有标准)，执行完成后，在根据key值进行删除。

@Component
public