MONGODB 读写队列增高与写延迟与多粒度锁

这个问题来自于我们内部的一个项目，本身MONGODB 并没有特别的大，只是偶发有读写队列瞬时增高的情况。在发生这个情况的时候，会出现global lock 同时会出现写入缓慢的问题。

所以这个问题出现后我发现我对MOGNODB 的锁真的不了解，所以解决问题之前必须弄明白。

首先根据我们的认知，mongodb是一个高速型的数据库产品，也就是说MONGODB 和传统数据库不一样，如果你的查询在 500ms 已经可以算为慢查询了，而在很多传统数据库中，这是正常的。那么一个mongodb中的性能的好坏与mongodb的锁的百分比有很大的关系。

在不少人的头脑中，感觉mongodb是一个无事务的数据库产品，实际上MONGODB 与传统数据库在这部分是一致的，具有mvcc，具有多版本控制，以及并发等功能，同时接受成百上千的.

实际上mongodb的锁也是多粒度的，通过锁来阻止同一个docuemnt在同一个时间被修改。而在读取的过程中，是不会对数据进行锁定的但是会跟踪你的锁定的频率，作为一个指标来对你的数据库进行跟踪。而这个锁定的频率统计是在两个层面，database 和 global . 在锁这个层面上，对于数据库层，只会对不同的用户进行加锁，而不会对在上层进行加锁。

实际上从mongodb的角度来看，mognodb的本身也将一些在写库上的锁进行了分离，如MONGODB本身的多节点，读写分离的方式，让读和写在物理上就进行了分离。所以如果一个利用了MONGODB 的从节点的部分的应用可能在锁方面产生的问题就比较少了。

如果遇到了锁定的部分比较多的情况，一般是系统响应的问题，具体可能有性能较差的 mongodb 的查询或者系统无法满足当前诉求产生的问题。

1 globalLock

4.4

5.0

2 locks

4.4

5.0

通过上面的两个命令，可以查看MONGODB 锁的部分的信息和内容，那么我们怎么解读这些指标和数据来对应我们对于MONGODB 的观测和问题的发现

1 globalLock.currentQueue.total

这个部分主要体现了两个问题 1并发性，如果系统中并发较多，则这个部分的totoal 会有波动，同时如果有需求等待锁的情况下，这个位置的数字会上升。

剩下的readers ，writers 两种是分别表达你的锁的需求来自于 read 还是 write

2 globalLock.totalTime

这个部分的数值需要和你的实际的服务器的运行的时间进行比较，如果你的这部分时间和实际的服务器的运行时间之间差距较大。

4.4

5.0

在4.4的版本中，我们可以通过acquireWaitCount 部分，来获取等待获取资源的等待时间，如果在短期这个数值上升的很高，那么说明系统正在存在大量的系统资源的。

所以撰写一个程序，在发现问题的情况下，快速的收集数据并将这些数据进行比对，可以快速的发现系统中出现的问题。如果后面我们写出这样的程序，也会和大家分享。

同时遇到这个问题，需要综合的去分析和收集数据，global lock 高的原因还需要更详细的分析。