1.mongo锁概况：
各版本锁的特性：
当前版本 生产版本最高是 2.6.7[Production Release (2.6.7)] 开发版本是 3.0.0-rc7[Development Releases (unstable)3.0.0] Version < 2.2 : 只支持进程级锁，一个Mongod实例一个锁。2.8 >Version >= 2.2 : 支持库级锁，一个db一把锁。目前3.0.0 支持 collection 级别的锁。
ps:Mysql的innoDB和Oracle是支持行锁的。目Production Release的最高版本是2.6.7，即只支持库级锁，当一个MongoDB处于写状态时，其他的操作都得干等。mongo虽然拥有库锁，但是还能保持高性能的原因是它在如下几个层面做了让步或者叫优化：
（1）Mongo没有完整的事物支持，原子操作仅仅到document级别，粒度比较小。<br>（2）Mongo锁实际的占用时间是内存数据计算和变更时间，通常很快。<br>（3）Mongo锁有一种临时放弃机制，当出现需要等待慢速IO读写数据时，可以先临时放弃，等IO完成之后重新获取锁。<br>
而目前的2.8版本已经将锁的粒度降低到了collection基本，官网的说法是：
MongoDB 2.8版本的最重要的特性应该就是对WiredTiger的支持，从而实现对文档级锁的支持。在过去使用MongoDB时，自己就遇到了缺少文档级锁的问题。每次进行写入操作时，必须等待写操作的一个反馈，整个数据库级别的锁给写入操作带来了很大的延迟。这次能带来稳定级别的锁特性，真是令人兴奋。
官方锁相关的介绍：
2.针对库锁的优化策略（使用方式）：
（1）索引的构建变成后台操作：当有大规模的数据需要构建索引时，如果在前台构建会创建一个（优化策略：不会临时放弃）的写锁，如果集合的数据量很大，建索引通常会很耗时。优化手段，将建索引的动作有前台切换到后台。
example:前台索引：db.trends.ensureIndex({user_id:1})后台索引：db.trends.ensureIndex({user_id:1},{background:1})
（2）锁的性能测试：a. mongo 2.6 和 mongo 3.0 针对并发写入同一个DB的2个不同集合的性能对比（主要测试mongoV3.0 针对collection锁的支持）:场景：为了测试mongoV3.0 针对collection级别锁的性能的提升，在我们的daily机器上，开了两个针对同一个DB但不同collection的写线程各20个，每个线程一直进行写操作，得出的qps分析结果如下：
结果分析： mongo2.6.4版本是db级别的锁，针对同一个库中的两个不同集合也会存在锁的竞争，而mongo3.0.0是collection级别的锁，所以从理论和测试结果上看，其性能确实有提升。
b. MongoV2.6.4 随着锁冲突的变化，其读写吞吐量的变化趋势：场景：这个是在我自己的开发机上进行测试的效果图，开了10条并发的读写线程进行测试，横坐标代表：锁的比率（锁等待时间/读写事务完成的时间）
结果分析： 从结果看能反应出随着锁等待比率的升高，整体吞吐量有下降的趋势。
c. MongoV2.6.4 测试DB的前台索引、后台索引、以及不加索引的情况下的性能对比效果：场景：MongoDB分为前台索引、后台索引、以及不加索引，，前台索引会和读写事务产生严重的冲突，而后台索引进行了优化，当后台索引耗时较长的时候会让出锁给读写事务。不加索引则读事务耗时很长，写事务耗时较短。效果图如下：
结果分析：在不加索引的情况下读事务qps很低，可以理解为，读取数据在无索引情况下耗时较长，且写事务一直抢占着写锁，导致读事务饥饿等待。
3.锁对副本模式（replica)和sharding模式的影响：
（1）sharding模式：在读写锁方面，每个Mongod实例是和其他实例相互独立。在一个Mongod上的操作不会阻塞其他mongod实例的操作。（2）replica模式：在对Primary结点进行写操作的时候，同时还会向 Primary’s OpLog写入，此时需要锁定2个库，一个是当前写入collection所在的库，另外一个是OpLog所在的 local 库。即 Primary会在这两个库上添加写锁。另外，Secondary结点会同步Primary结点的OpLog，将Oplog顺序批量并发的在自己的结点上执行，此时为写操作，在该写操作执行的过程中，Secondary也是不能提供读操作的。
穷则思变，差则思勤！没有比人更高的山没有比脚更长的路。
