mongodb复制

锁

在mongo早期版本中，每个链接都会有锁，在服务器级别，使用互斥锁（互相排序）这种允许多个客户端或者多线程访问相同资源的机制。这种情况下的资源是数据库服务器。但是不是同时并行的。这是最坏的锁，尤其是需要大数据数据库引擎时，同时可能有几千个客户端并发访问

在版本2.2以后做了改变，实现了数据库级别的锁。互斥锁应用在数据库级别而不是整个mongodb服务器实例上，这是个重大的改进。但是mongo线程会尝试获取队列中的写入锁，并且使用串行方式处理它们，无论当前锁线程是否释放锁都可以允许线程继续工作。在小规模数据库里，这可能非常快，没有什么太大的性能影响；但在更大的数据库里，每秒几千次写入请求，这也会成为致命问题，严重降低应用程序的性能。

这个问题在mongo3.0之后被修复，此版本引入了集合级别的锁机制，对于MMAPv1存储引擎可用。 这个新特性把锁机制进一步降低到集合级别。这意味着多个请求可以同时被处理，而不需要互相阻塞， 只要它们可以写入到不同的集合中即可。

在3.0以后使用WiredTiger存储引擎， 还可以支持文档级别的锁。这是一个更细粒度的锁——多个请求现在可以同时访问一个集合而不需要互相阻塞，只要没有同时写入一个文档。

总结：WiredTiger在读写操作里表现得很好，而且提供了文档级别的锁，而MMAPv1没有，它提供的锁支持到集合级别。WiredTiger引擎不像MMAPv1引擎这么贪婪，尽管是对于小规模的应用，比较节约使用磁盘的空间，而且它让mongo成为一个可变化的数据库系统。虽然MMAPv1在某些情况下速度更快，但是WiredTiger的性能与成本远远优于MMAPv1存储引擎的。

复制

主从复制和可复制集群使用了相同的复制机制，但是可复制集群额外增加了自动化灾备机制：如果主节点宕机，无论什么原因，其中一个节点会自动提升为主节点。除此之外，可复制集群还提供了其他改进，比如更易于恢复和更复杂地部署拓扑网络。因此我们很少再用简单的主从复制机制。可复制集群是推荐的生产环境下的复制策略。

缺点：在可复制集群里，数据并非真正地被提交，直到它被写入大多数集群的节点中，这指的是50%上的服务器。因此，如果可复制集群只有两台服务器，就意味没有服务器可以停机。如果主节点在复制数据之前停机，其他成员将会继续接受写入，而且任意未复制的数据必须回滚，意味着这些数据不能被读取。

重点注意的是：虽然可复制集群是冗余的，但是它也无法取代备份机制。备份是过去某个时间点上数据库数据的快照，可复制集群通常是最新的。有些时候数据集太大，可能会导致备份不太符合实际。但是通常的规则下，备份是必须的，即使运行了复制机制也需要启动备份。换句话说，备份是为了预防逻辑故障，比如突发性数据丢失或者数据冲突。

复制的使用场景和限制

冗余：1.它可以确保从节点与主节点的数据同步。这些复制节点可以和主节点位于一个数据中心或者为了安全可以分布于其他数据中心。复制是异步的，任何网络延迟和分区都不会影响主节点的性能。

2.作为另外一种形式的冗余，复制节点也可以延迟某个固定的时间后执行。这防止了用户无意删除集合或者应用程序与数据库冲突的情况。通常，这个些操作将会被立即复制；延迟复制可以给管理员足够的时间来做出相应并保存数据。

灾备： 我们希望系统是高可用的，但是只有在冗余节点时才可以使用，并且在紧急情况下切换这些节点。mongo的可复制集群让这一切都可以自动切换，非常简单。

除了数据冗余和灾备，复制也简化了维护工作，通常通过允许管理员在从节点而不是主节点上运行命令。例如，通常的经验时在从节点上运行备份命令来缓解对于主节点的压力，避免宕机。构建大型索引是另外一个例子。因为所有构建非常昂贵，我们可以在节点上优先构建，然后切换主从节点的角色，再次在新的从节点上构建索引。

最后，复制可以允许我们在从节点上平衡读写压力，对于读取压力超大的应用系统，这个是最简单的解决方法，或者如果你选择最原始的做法，可以伸缩mongo数据库。但是对于所有的承诺，可复制集群在以下情况下无能为力：

1.现有的硬件无法处理工作负荷。例如，我们前面章节提到的工作集，如果数据集超过了可用的内存大小，那么随机读取从节点就不会像我们期望的那样改善性能。从可复制集群从节点读数据可以增加IOPS数量，但是100-200 IOPS可能无法解决性能问题，特别是同时写入并且消耗部分IO数量的时候。此时，分片可能是最好的选择。

2.写入和读取的比例超过50%，这个比例是个好的开始点。由于每个主节点的写入都会最终写入每个从节点上，因此，直接读取已经在处理很多写入请求的从节点时会降低复制的性能，并且可能无法增加读吞吐量。’

3.应用程序需要一致性读取。 从节点异步复制，因此不能确保反映最新主节点的写入数据。在极端的糟糕的情况下，从节点可能延迟几个小时。 

对于不需要立即一致性系统，可复制集群是卓越的伸缩读并发的解决方案，但是并非适用于所有场景。如果需要伸缩系统，特殊的情况可能需要不同的策略，使用分片，升级硬件或者结合两个方案。