MongoDB从入坑到入迷

背景： 我司是一家正处于高速发展，目前拥有数百万用户，年销售额近五十亿的社交电商公司。公司技术部建立之初，为了适应用户量的高速增长，与业务的不断变更迭代，在选用数据库的时候，经过调研对比我们选择了MongoDB！

是的，你没看错，All in MongoDB!

全文大纲：

1. 为什么使用MongoDB（选择数据的时候我们是怎么考虑的？）
2. MongoDB架构（99.99%高可用，晚上安心睡大觉！）
3. MongoDB 分片（海量数据应对之道！）
4. MongoDB文档模型介绍（灵活！灵活！灵活！）

1. 为什么使用MongoDB

因为我司主要做社交电商的业务，所以对数据库的性能有一定的要求，加上商品交易是公司主要盈利来源，所以对数据库的高可用也有一定的要求。

总结一下我们对数据库的要求：

• 安全，稳定
• 高可用
• 高性能

我们在考虑数据库选型的时候主要考虑什么？

• 数据规模
• 支持读写并发量
• 延迟与吞吐量

从数据规模来说订单和商品SKU，还有会员信息这些重要的数据记录肯定会随着时间源源不断的增长，所以我们需要的不仅仅是满足当下要求，更需要为半年一年后海量数据更为方便的扩容做考量！

下面我们从MongoDB的架构，性能，和文档模型来介绍一下我们选择MongoDB的理由！

2. MongoDB架构

2.1 关于高可用

数据库作为系统核心，要保证99.99%的可用性，而高可用的保证来自于MongoDB冗余数据的复制集模式。MongoDB自带多副本高可用，只需要合理的配置，就能避免单数据库节点故障导致服务的不可用。

一主两从：

图例说明：

• 一个Primary主节点，主要接受来自server的读写
• 两个Secondary从节点，用于同步来自Primary的数据

关于高可用：
当主节点发生故障的时候，两个从节点会进行选举，投票产生一个新的主节点，进而保证服务的可用性。（PS：在选举过程中数据不可写入，但是如果Secnondary节点配置可读，那么此时是可以读取数据的。）这就是MongoDB的高可用，配置简单，不需要引入额外的中间件或者插件去辅助数据库节点间的故障转移。

2.2 关于选举算法《分布式一致性算法—raft》：

raft协议是在leader节点发生故障或者网络分区导致脑裂时如何保