背景
我负责的是一个游戏服务器
最近项目新增了激活码的需求，需要给每个购买的用户发放一个激活码，但是激活码并不是我们的游戏服务器生成的，而是用的接入平台那边给的指定的激活码，平台的激活码是唯一的，每一个激活码发放的时候都会发一个短信给用户，短信通知的功能很好实现，关键在于服务器要保证的是不能重复发放激活码。
由于激活码是平台那里提前给出的，我要先把激活码存入数据库，由服务器去发放。举个例子，平台给了500个激活码，我就要把这500个激活码存入数据库，如果有500个用户来买游戏，服务器就要把这500个激活码发到每个用户，每个激活码只能用一次，不能重复发放。
根据万物皆对象的程序猿定理，我创建了激活码对象，具体属性如下：
key 激活码（平台那里给的激活码）
status 激活码状态（主要区分激活码是否被发放，0未发放/1已发放/2已使用）
createTime 创建时间
useTime 使用时间
uid 用户的UID（用来记录这个激活码发给了哪个用户）
isSms 是否已发送短信（0未发送/1已发送）
说下几个关键属性的用处，key是激活码，因为要保证唯一性所以在key上建立唯一索引；status用来判断激活码使用状态，查询未发放的激活码时候就需要通过这个字段进行筛选；uid要跟着激活码状态的改变添加进去，status从0变成1的时候必须要把uid更新进去。在导入激活码的时候也给每个激活码设置status为0，至于isSms是否成功发送短信是另一套逻辑进行操作的，不是本篇重点。
由于Java中操作MongoDB的工具甚多，方法不尽相同，所以我用MongoDB命令去写下列操作，使用时请替换成各自工具的方法
正常来说，如果你要更新一条数据的某几个字段，就先要把他找出来，即在使用update之前要先find
① db.activation_code.find({"status":0}).limit(1)
这样我就找到了一个未被使用的激活码，然后下一步就是把这个激活码的uid和status更新，然后接着执行更新操作
② db.activation_code.update({"key":"qwer"},{$set:{"uid":"123213","status":1}})
整个流程看似没什么问题，但在实际应用的时候不会是单线程运行的，如果同时两个线程都在执行①，MongoDB中find和limit会找到符合条件的第一条结果，那么这两个线程得到的将会是同一个激活码，然后两个线程都对这个激活码进行②更新操作，那么肯定会有一个uid被覆盖掉，这种情况肯定是不安全的。
这里有两种解决方案，一种是使用乐观锁，另一种是先执行更新，再去查uid对应的key。
先说乐观锁，查询和①一样，只是在更新的时候带条件去更新
③ db.activation_code.update({"key":"qwer","status":0},{$set:{"uid":"123213","status":1}})
即在②的基础上加上状态为0的条件，更新的时候会找到key为qwer且状态为0的激活码，如果该激活码已经被使用status肯定不为0，更新条件就查不到这条记录。每次更新都会有返回值，通过返回值判断是否更新成功，如果没有更新成功，则继续执行①和③操作，直到更新成功为止。
另一种是先执行更新，再去查对应的key
④ db.activation_code.update({"status":0},{$set:{"uid":"123213","status":1}},{upsert:true})
⑤ db.activation_code.find({"uid":"123213"}).limit(1)
先是④更新，再去通过更新时的uid去找对应的激活码key，即⑤，然后把激活码key返回给用户。
更新的时候有条件，必须是status为0的才能执行更新，MongoDB的更新语句有隐藏属性multi，默认为false时只更新符合条件的第一个文档，为true时更新符合条件的所有文档，这里我们不设置multi即为默认false。
upsert属性是不存在就插入这条记录，应对激活码用完，没有新的激活码存入这种情况，不至于程序挂掉。实际上是不可能会发生这种情况的，但是如果真的发生了，如果真的发生了，我们还能去查哪些记录只有uid没有key，从而去补发激活码。
这里讲一下为什么要先写入
MongoDB的写入操作是原子操作，在MongoDB2.0及以前的版本，MongoDB会在写入的时候对所有数据库上锁，这一点和MySQL的行级锁不同，MongoDB2.0是全局锁，而且写入的优先级是大于读的，当时因为效率问题屡被吐槽，在MongoDB2.2的时候实现了数据库锁，只对该数据库上锁，不影响其他数据库，依然没有逃脱被吐槽的命运，直到3.0的版本MongoDB加入了表级锁，执行写操作的时候会对整张表上锁，不影响其他表的操作，性能有了大的改善，才逐渐体现出NoSQL的优点。
这两种方案，乐观锁依靠的是服务器去执行写入操作，每次写入都有迹可循。而先更新再查找依靠的是数据库本身的性能，在更新的时候带入条件，每次更新都会找符合条件的数据进行更新，MongoDB的表级锁在这时候就起到了关键作用。
