解决数据库报惟一性约束错误的实践

猿们好，我是honery，今天来给你们唠一唠如何避免数据库报惟一性约束的错误。

##1、问题的引出   首先抛出一个问题，如何保证数据库表中的某列的值都不同呢？相信你们很容易想到给该列加上惟一性约束，这样就能保证业务逻辑的正确性了。实际的使用中，尤为高并发场景下，很容易出现插入同一条记录的状况，该状况下数据库会报违反惟一性约束的错误。总不能让数据库一直抛这个错误吧。因而咱们想到能够在业务代码中加上该列值是否为空的判断，判断为空时再行插入，因而问题就解决了。

  问题真的解决了吗？说是，你就too young too simple了。有没考虑过高并发场景呢？若是多个线程同时在某次插入前去判空，显然判断的结果都是空，那么第一次插入成功后，后续的插入动做都会报违反数据库惟一性约束的错误。总不能让日志一直报错吧，该如何解决呢？

##2、问题的解决方案   这个问题实际上是个典型的问题，能够有不少种解决方案，小编这里就简单提供三种解决策略。方案很简单，猿们跟上思路~~ ###2.1 经过锁机制，将查询和插入原子化   相信不少小伙伴很容易就能想到这个方案，经过锁机制（如内置锁，synchronized）将记录是否存在的查询动做和插入新记录的动做放在一个同步锁中，实现的关键代码以下：

@Transactional
public synchronized void insertWhenIdIsEmpty(Qingmj qingmj) {
	log.info("进入时间："+System.currentTimeMillis());
	log.info(qingmj.toString());
			
	Qingmj qingmj_old = qingmjMapper.getQingmjById(qingmj.getId());
	
	try {
		//等待10s,制造并发场景
		Thread.sleep(15000);
	} catch (InterruptedException e) {
		log.warn("睡眠等待过程异常",e);
	}
			
	if(qingmj_old==null) {
		log.info("数据准备插入中... ...");
		try {
			qingmjMapper.insert(qingmj);
			log.info("数据插入成功！");
		}catch(Exception e) {
			log.info("数据插入失败",e);
		}
	}else {
		log.info("约束键已存在，再也不插入");
	}
	
	log.info("结束时间："+System.currentTimeMillis());
	
}

• <font color=#0099ff size=4 face="黑体">[执行结果]</font>：

• <font color=#0099ff size=4 face="黑体">[结果分析]</font>：

<font color=#ff0000 size=3 face="黑体">  从执行结果可知，经过锁机制将查询和插入原子化后，完全的避免了插入重复数据的问题。可是带来了一个新问题，同步锁将两个业务动做锁在一块儿，强制执行过程串行化，会致使系统运行的性能较差，该如何优化呢？</font>

###2.2 经过双重检查锁机制，优化串行化带来的性能问题   所谓的双重检查锁机制，从名字不难看出其逻辑。它主要有两个技术点：1、将方法锁细化成代码块锁，尽可能减小锁住的执行逻辑；2、执行两次判空逻辑，即在同步代码块中再加入一次判空检查。具体的代码实现以下：

//@Transactional
public void insertWhenIdIsEmpty(Qingmj qingmj) {		
	log.info("进入时间："+System.currentTimeMillis());
	log.info(qingmj.toString());
			
	Qingmj qingmj_old = qingmjMapper.getQingmjById(qingmj.getId());
	
	try {
		//等待10s,制造并发场景
		Thread.sleep(15000);
	} catch (InterruptedException e) {
		log.warn("睡眠等待过程异常",e);
	}
			
	if(qingmj_old==null) {
		synchronized (this) {
			Qingmj qingmj_old_2 = qingmjMapper.getQingmjById(qingmj.getId());
			if(qingmj_old_2==null) {
				log.info("数据准备插入中... ...");
				try {
					qingmjMapper.insert(qingmj);
					log.info("数据插入成功！");
				}catch(Exception e) {
					log.info("数据插入失败",e);
				}
			}else {
				log.info("约束键发现变为存在状态，再也不插入");
			}
		}

	}else {
		log.info("约束键已存在，再也不插入");
	}
	
	log.info("结束时间："+System.currentTimeMillis());
	
}

• <font color=#0099ff size=4 face="黑体">[执行结果]</font>：

• <font color=#0099ff size=4 face="黑体">[结果分析]</font>：

<font color=#ff0000 size=3 face="黑体">  引入双重检查锁机制，有效优化了同步方法锁性能较差的问题，是一种较为推荐的方法。这也是单例模式中懒汉模式的一种经典实现。代码中的事务注解不能在此处方法上加上，不然会拔苗助长，这也是锁与事务做用范围的一个角逐。好了，回到正题，解决违反数据库惟一性约束问题，能不能不加锁呢？答案是确定的。</font>

###2.3 经过巧用Redis的setnx特性，避免重复数据的插入   咱们要解决的问题是业务流程正常，但数据库会持续的报违反惟一性约束的问题。如何保留数据库的惟一性约束，维持业务流程正常，但同时不让数据库报上述异常呢？顺着这个思路咱们能够想到可否在数据进入数据库以前就识别出重复数据的冲突呢？这样即可以解决上述问题了。有不少第三方的中间件能够帮咱们作到这点，其中Redis就是一个例子。

  你们都用过Redis，知道Redis的setnx方法有个特色，当第一次插入某个key及其value值时会返回“1”；当后续继续插入该key的其余value值时会返回“0”，并插入失败。因而乎，咱们在插入数据库以前，先将数据存入Redis当中，若Redis反馈为第一次插入则落地数据库中；若Redis反馈非第一次插入则不落地数据库。如此便巧妙解决了数据库报惟一性约束的问题了，并且！没有用到锁！具体实现以下：

@Transactional
public void insertWhenIdIsEmpty(Qingmj qingmj) {
	log.info("进入时间："+System.currentTimeMillis());
	log.info(Thread.currentThread().getName() + " parameters:" + qingmj.toString());
	
	Qingmj qingmj_old = qingmjMapper.getQingmjById(qingmj.getId());
	
	try {
		//等待10s,制造并发场景
		Thread.sleep(15000);
	} catch (InterruptedException e) {
		log.warn("睡眠等待过程异常",e);
	}
	
	if(qingmj_old==null){
		if(redisUtil_test.setnx("constraint_id_"+qingmj.getId(), qingmj.getId()) == 1){//若是数据存在则返回0，不存在返回1
			log.info("数据准备插入中... ...");
			try {
				qingmjMapper.insert(qingmj);
				log.info("数据插入成功！");
				redisUtil_test.expire("constraint_id_"+qingmj.getId(), 1000);//设失效时间3秒
			}catch(Exception e) {
				redisUtil_test.del("constraint_id_"+qingmj.getId());//插入出异常则删除
				log.info("数据插入失败",e);
			}
		}else{
			log.info("并发情形，约束键已存在，再也不插入");
		}
	}else{
		log.info("约束键已存在，再也不插入");
	}
	
	log.info("结束时间："+System.currentTimeMillis());
}

• <font color=#0099ff size=4 face="黑体">[执行结果]</font>：

• <font color=#0099ff size=4 face="黑体">[结果分析]</font>：

<font color=#ff0000 size=3 face="黑体">  经过巧用Redis的setnx特性有效解决了数据库持续报违反惟一性约束的错误。同时没有使用同步锁，大大提高了系统的性能。这种方法甚至在表字段未加惟一性约束的状况下，也能保证业务逻辑的正确性，很是巧妙且灵活。固然系统也必需要支持Redis才能采用这种方案啦。</font>

##3、总结

  数据库违反惟一性约束问题，只是一个典型的小问题，解决方案特别多，你们均可以去借鉴。可是小编文中陈述的三种方案汇聚了解决这类问题的两个思路。其一是加锁，锁性能优化；其二是不加锁，在落地数据库以前提早引起数据冲突。方案虽然说简单，可是值得回味的。