MongoDB在我们的生产环境中已经大规模的使用，它的性能与稳定已经得到的充分的验证，稳定在线的时间已经有一年多了。在这个过程中的确给我们带来了很多性能上的优势，虽然它不像关系型数据那样有方便的join查询，但就目前我们的应用场景这些缺点（暂且把它当做缺点吧）都是可以接受的。最近在思考了下nosql数据库并发控制方面的问题，在此记录一下。
数据库的并发控制机制不外乎就两种情况：
1.悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
2.乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性，乐观锁不能解决脏读和多读的问题。
悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好。
乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。
MongoDB不支持事务，也就没有数据库级别的悲观锁了。那么我们的并发控制只能依赖乐观锁，乐观锁非常适合我的应用场景，并且性能更高。刚才说的是数据库级别的并发控制，当然如果说到程序级别并发控制机制，同样是悲观锁和乐观锁。我们的经常用的lock就是一种悲观锁，不论是java还是.net。那乐观锁呢？当然这个就是软件事务内存，Clojure和Scala言语的内存管理，它们天生就是支持并发编程的。
如果要在普通的关系型数据库里实现乐观并发控制，我们一般需要为其加上一个额外的Version字段，它是整型，也可能是个时间戳。在更新某条记录时，我们将这个字段的“旧值”作为UPDATE语句的条件之一，同时这个字段也会写入新的值。如果这次更新影响了某条记录，那么表示更新成功，反之则表示这条记录已经被删除，或是在“读取”和“提交”之间遇到了其他提交操作。在sql Server中存在一个Timestamp类型，这个类型的字段会在记录修改时自动更新。
要在MongoDB实现乐观锁，方式差不多，只是update完了之后，不会返回修改的数据条数，得还要自己去查询一下是否修改成功。
>db.log.update({"uuid":"1",version:1},{$set:{"enddate":"2012-5-19 17:17:10",version:2}})
> db.$cmd.findOne({getlasterror:1}) { "updatedExisting" : true,"n" : 1,"connectionId" : 1,"err" : null,"ok" : 1 }
>db.log.update({"uuid":"1",version:2}})
> db.$cmd.findOne({getlasterror:1}) { "updatedExisting" : false,"n" : 0,"ok" : 1 }
在update语句后面跟上一句db.$cmd查询，如果它返回updatedExisting为true，则表示更新成功了。当然如果使用java驱动的话，可以使用dbCollection.update和dbCollection.getStats()，便可以更新并且返回状态信息。但是db.$cmd查询的结果是否准确呢？如果在update语句和db.$cmd查询之间，如果另外一个连接恰好也执行了一次update操作，那么db.$cmd返回的是哪次更新的结果？通过查询官方资料，db.$cmd查询是与连接相关，这便不会有问题了。不过值得注意的是，驱动程序是“自动管理连接”的，也就是说当update()完成之后getstats()有可能使用的不是同一个链接了，这个时候db.$cmd返回的状态信息就不准确。所以如果采用上诉方式你要确保自己两次获得的是同一个链接。如果你想一直使用同一个连接，可以用下边这种方式：
DB db...;
db.requestStart();
code....
db.requestDone();
但是如果最后db.requestDone()没有被调用，该连接不会被交还给线程池，所以，一定要在finally块中调用db.requestDone()。
由于我使用spring来管理mongo驱动，我不喜欢上面那种保持一个链接的方式，所以我用findAndModify来更新数据，当然更新条件自然同样需要包括版本号。如果更新成功，那么findAndModify命令则会返回“更新前”的数据，否则则返回空文档。这种使用数据库命令行的方式就可以避免保持同一个链接的要求。该方式也是我推荐的方式，官方文档已经说的很清楚了。
This command can be used to atomicallymodify a document(at most one) and return it. Note that,by default,the document returned will not include the modifications made on the update.
以上便是mongodb并发控制乐观锁的实现方式。