前两篇文章说了CAP理论和PACELC理论，大部分NoSQL系统都基于这两个理论，今天看看mongodb是如何实践的。
其实mongodb不希望大家仅仅将其当作一个NoSQL系统，它认为自己一个数据库系统，可个人认为，最后做的有点不伦不类！
1：结论
mongodb只能从主节点写入数据，且默认读取操作也是来自于主节点，所以按照CAP理论来说，它是一个PC系统；按照PACELC理论来说，它是一个EC系统。
在正常情况下，可用性和一致性是可调的，mongodb通过配置不一样的write concern和read concern，它也可以认为是一个AP系统，注重可用性（主从节点一般需要12秒）。
2：mongodb的架构
一个mongodb集群中的节点分两种类型：
主节点，master节点，所以的写操作必须经过主节点 第二节点，它的数据从主节点同步
默认情况下，读写操作都基于主节点，但读操作客户端可以路由至第二节点，但写操作必须是主节点。
如果主节点挂了，写操作就无法完成了，按照mongodb官方文档描述，12秒可以将一个第二节点选举为主节点。
为了增加可用性，一个mongodb集群最多可以配置50个第二节点（也叫副本集）。
3：一致性
上面也说了，默认情况下，mongodb是一个强一致性的系统，一旦有写入，最近读取的数据就是最新的。
但必须注意的是，如果配置允许在第二节点上进行读操作，那么它只能是一个最终一致性的系统，因为节点之间肯定存在延迟问题，延迟越大，读取返回的数据就可能不是最新的。
（1）可调一致性
什么意思呢？就是可用性和一致性在mongodb中可以互相切换，不管是读操作还是写操作，可以定义副本集ack的数量控制需要可用性还是一致性，这通过write concern和read concern机制完成。
如果是write concern：
0：表示写的时候不需要ack确认 1：表示仅仅需要主节点ack确认就可以 number：表示需要number节点ack确认 majority：表示需要大多数节点ack确认
如果是read concern：
local：从连接的节点读取数据，不管数据有没有真正写入到主节点，相当于关系数据中的未提交隔离 available：基本和local一样 majority：表示读取的数据大部分节点上都存在
（2）在正常情况下失去一致性
mongodb中通过在多个节点之间复制数据，如果延迟太大，就会导致一致性问题，mongodb 4.2开始可以配置延迟的时间，在这段时间mongodb就只能一直等待数据完成同步，如果落后太多，建议就从新拷贝或者从快照中恢复。
（3）节点故障情况下失去一致性
如果主节点出现问题后，mongodb就会失去可用性，直到选举出一个新主节点。当原来的主节点成为从节点后，它原来没有完成的写操作都会回滚。
4：可用性
mongodb是通过副本集的概念提升集群可用性的，集群部署在不同的区域进一步提升可用性。
对于大多数集群来说，典型的复制系数为3，如果对可用性要求非常高，就配置为5。
当数据可用性不太重要时，复制因子可以降低，以节省空间和提高性能。
（1）容错
主节点出现故障后，如果electionTimeoutMillis秒还没有恢复，就会选举新的主节点，在重新选举这段时间：
写操作无法完成 读操作没有问题，如果配置第二节点可读取的情况下
（2）数据中心容错
因为mongodb的集群可以跨越地理位置不同的数据中心，如果一个数据中心出现故障，基本没有影响。
但如果主节点对应的数据中心出现故障，那么在选举出新的主节点之前，整个集群就没法用了。
MongoDB 和 Cassandra 集群都可以跨越地理位置不同的数据中心，以提高高可用性。如果一个数据中心发生故障，应用程序可以依靠幸存者继续运行。
MongoDB 如何应对数据中心的损失取决于数据中心成员的数量和位置。如果包含主服务器的数据中心发生故障，在选出新的主副本之前，可用性就会丧失。
对于我来说，以CAP和PACELC理论理解mongodb整个架构，一切都显得那么自然和可理解！
我的公众号文章比较杂，涉及到编程语言、Linux、大数据、分布式、DevOps、AI、微服务、K8s/Docker等等，希望全方位给初学者一点帮助，积累或巩固知识，体验到技术的美妙。
