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节点发生故障或者网络分区导致脑裂时如何保证分布式数据一致性的一个算法