MongoDB3.4的读关注增加了“linearizable”属性，这个属性保证当次节点被暂时选为主节点的时候，主节点的数据不会被回滚。配置这个属性会在一定程度上影响系统的延迟性，因此，需要设置一个maxTimeMS值，保证操作不会长时间执行。
MMAPv1中，没有readconcern这个属性。
主节点选举主节点不可达的时候，如果你使用了read preperence属性而不是默认的primary属性，那么系统任然可以读取数据，但是不能写入数据到复制集中，除非出现以下情况：
l 主节点恢复
l 举行选举后，其中一个此节点选举为主节点
如果主节点只是短时间内不可达（比如，短暂的网络故障），那么***的方式就是等待主节点重新恢复故障。然而，如果主节点在短时间内恢复不了，那么***是系统可以快速选举出新的主节点接管主节点的工作。很显然，这些情况在实际中都需要权衡。
MongoDB3.2引进了一种增强的复制集协议，可以在主节点出现故障后快速的实现服务恢复，同时保证系统持久性。增强的复制集协议扩展了Raft一致算法，增强了系统部署的灵活性，同时保证对原有复制集结构的兼容性。尤其是，这种协议支持replica set arbiters, replica set member election priorities。
增强协议通过优化算法，可以在主节点故障时快速的选举中合适的次节点。故障转移的时间又很多因素决定，比如网络延迟。避免系统出现不必要的故障是非常重要的，使用electionTimeoutMillis参数可以调整故障恢复时系统的表现：
l 参数值越大，故障恢复时间越长，但是可以减小系统对网络延迟的敏感性以及主节点上的负载
l 参数值越小，故障恢复时间越短，但是会增加系统对网络延迟的敏感性以及主节点上的负载。
MongoDB系统扩展 用分片进行水平扩展MongoDB使用分片技术来实现数据库水平扩展的目的，分片对应用来说是透明的，不可见的。分片可以把系统的数据分布在多个复制集中，通过自动数据平衡功能，MongoDB保证在数据体积增大或者集群扩大或者减少的情况下，数据可以平均的分布在各个分片服务器中。MongoDB分片的好处就是在不增加应用的复杂性的前提下，可以突破单个服务器RAM和I/O的瓶颈限制。
MongoDB提供三种分片策略以支持多样化的查询模式：
l Range-based 分片：系统会根据片键把文档分配到不同的分片服务器上。片键值相似的文档有可能会被分配到同一个分片服务器上。这种方式适合于那些基于范围的查询的应用。
l Hash-based 分片：在这种分片方式下，文档会根据片键的MD5哈希值平均的分配到各个分片服务器上。片键值大小差不多的文档一般不会被分配在位置相邻的分片服务器中。这种方法保证了在分片之间均匀分布的写入 - 只要分片密钥具有较高的基数 - 使其成为写密集型工作负载的***选择。
l Zones:MongoDB Zones可以精确控制物理存储数据的位置，适应很多部署场景，比如地理位置、硬件以及配置，或者应用。管理员可以修改片键范围来不断的完善数据存放规则，MongoDB也会自动的把数据迁移到新的域中。MongoDB3.4添加了新的帮助功能以及Ops Manager and Cloud Manager中额外的选项以便配置Zones，用以管理庞大的系统部署。
尽管分片的功能强大，但是同时也会为系统部署带来一定的复杂性，并且它也会对基础架构提出一定的需求。所以，只要在需要的时候才可以根据实际的需求对系统进行分片。
在如下几个场景下用户就应该考虑使用分片。
l RAM有限制：系统活跃工作集以及索引如果超过系统RAM的最大容量，则可以考虑使用分片
l 硬盘I/O有限制：系统有大量的写入操作，并且系统写入速度远远不能满足需求或者I/O已经限制了数据刷入硬盘的速度。
l 存储限制：数据集的容量超过系统单个节点所能承受的压力。
l 对地理位置有需求：数据需要被分配到指定的数据中心以实现读写的低延迟。或者，创建多温度存储设施，把热数据和冷数据分离开。
如果遇到上述的场景，或者可能在以后会遇到上述场景的，就应该及时使用分片，不要等到容量已经不够用的时候在分片。使用分片设计数据模型的时候，需要考虑在那个集合上进行分片，以及使用哪个联合片键。如果系统已经达到了最大容量值，那么在不影响应用的前提下对系统进行分片是很有挑战性的。
分片***实践使用分片时可参考如下实践:
选择合适的片键：选择片键需要考虑如下三个方面：