在实际应用中，用户可能会有连点操作，当连点操作的时间间隔非常短时，系统很容易造成重复数据的插入，如图所示：
可以看到有2条数据被重复插入了(encrytedPassword一致)，尽管userId是不同的。
二、解决方案1.从sql方面解决，这里可以根据数据库表是否有其他唯一索引来划分：
a.表中除了主键外，还有唯一索引时：假设表中除了主键，存在某一字段a是唯一索引，且已存在于表中的数据为1
- 使用ignore关键字 如果是用主键primary或者唯一索引unique区分了记录的唯一性,避免重复插入记录可以使用：
INSERT IGNORE into user(a,b,c) VALUES('1','joshua317','13299999999');
插入a=1冲突，这样当有重复记录就会忽略,执行后返回数字0
- 使用Replace
REPLACE into user(a,b,c) VALUES('1','joshua317','13299999999');
REPLACE的运行与INSERT很相像,但是如果旧记录与新记录有相同的值，则在新记录被插入之前，旧记录被删除
- 使用ON DUPLICATE KEY UPDATE
INSERT INTO `table` (`a`, `b`, `c`) VALUES (1, 2, 3) ON DUPLICATE KEY UPDATE `c`=`c`+1;
加入a是唯一索引时，如果表中已存在a=1，则插入失败，等价于下面的update语句
UPDATE `table` SET `c`=`c`+1 WHERe `a`=1;b.表中不存在唯一索引时
上面规定a为表中的唯一索引，但很多时候表中除了id外，是不存在唯一索引的，我们又不能随便改变公司的表结构，所以可以使用下面的方案：
- 先查询后插入，伪代码：
@Transactional
User register(User user){
User user = UserDao.SelectUserByUid(user.getUid());
if(null==user){
user = UserDao.save(user);
}
return user;
}
这种方法并发时可能会出现错误，比如用户第一次点击时，执行register方法，当前的user查询为null，还没执行save方法时，用户再次点击时，并发执行了register方法，并且完成后，线程回到第一次操作中，再次执行save方法，会导致user重复插入。所以我们要加上**@Transactional**保证事务的原子性。另外这种方法性能稍微差一些
- **使用insert ignore if not exist，**具体格式为：
INSERT IGNORE INTO 表名('字段')
SELECT '字段需要插入时的数据' FROM dual
WHERe NOT EXISTS
(SELECt * FROM '表名' WHERe '需要被限制不重复的字段' = '被限制字段本次插入的数据')
比如mybatis使用时为：
INSERT IGNORE INTO user(a,b,c)
SELECt #{a},#{b},#{c} FROM dual
WHERe NOT EXISTS
(SELECt a,b,c FROM user WHERe b = #{b})
解释一下：
第一行的insert ignore我们知道，插入不进去就取消插入操作
第二行的dual是虚表，select 1,2,3 是合法的，但为了好看，所以变成select xxx from dual虚表
第三行和第四行顾名思义，如果存在b的某个值以及在数据库中存在，那么第一行的insert不生效。
参考：https://blog.csdn.net/qq_23490959/article/details/90669128
https://blog.csdn.net/b644ROfP20z37485O35M/article/details/108633274
https://www.csdn.net/tags/NtzaggysMDMzNDEtYmxvZwO0O0OO0O0O.html
三、悲观锁(分布式锁)方案：上面虽然是不错的解决方案，但是如果一个工程中所有的save代码都已经写好了，那么都得全部都按照上面的方法改一遍吗？太麻烦了，比如：
另外，如果是分布式呢？一个save方法在多个服务中都存在时，上面的方法 很多时候是不适用的。
所以我们应该从根源解决问题，百因必有果，重复插入操作的根源就是重复执行了这段代码，那我们完全可以使用锁的方式把这段代码锁住，防止重复性操作。
待续解释分布式锁。。。。
参考https://juejin.cn/post/6904629373383639048
