为什么我们选择了MongoDB？ _MongoDB

我司是一家正处于高速发展，目前拥有数百万用户，年销售额近五十亿的社交电商公司。

文章插图
图片来自 Pexels
公司技术部建立之初，为了适应用户量的高速增长，与业务的不断变更迭代，在选用数据库的时候，经过调研对比我们选择了 MongoDB 。
是的，你没看错，All in MongoDB!
本文将围绕如下几个部分进行分享：

为什么使用 MongoDB(选择数据的时候我们是怎么考虑的?)
MongoDB 架构(99.99% 高可用，晚上安心睡大觉!)
MongoDB 分片(海量数据应对之道!)
MongoDB 文档模型介绍(灵活!灵活!灵活!)

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

安全，稳定
高可用
高性能

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

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

从数据规模来说订单和商品 SKU，还有会员信息这些重要的数据记录肯定会随着时间源源不断的增长。
所以我们需要的不仅仅是满足当下要求，更需要为半年一年后海量数据更为方便的扩容做考量!
下面我们从 MongoDB 的架构，性能，和文档模型来介绍一下我们选择 MongoDB 的理由!
MongoDB 架构
①关于高可用
数据库作为系统核心，要保证 99.99% 的可用性，而高可用的保证来自于 MongoDB 冗余数据的复制集模式。
MongoDB 自带多副本高可用，只需要合理的配置，就能避免单数据库节点故障导致服务的不可用。

文章插图

图例说明：

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

关于高可用：当主节点发生故障的时候，两个从节点会进行选举，投票产生一个新的主节点，进而保证服务的可用性。
PS：在选举过程中数据不可写入，但是如果 Secnondary 节点配置可读，那么此时是可以读取数据的。
这就是 MongoDB 的高可用，配置简单，不需要引入额外的中间件或者插件去辅助数据库节点间的故障转移。
②关于选举算法《分布式一致性算法---raft》
raft 协议是在 leader 节点发生故障或者网络分区导致脑裂时如何保证分布式数据一致性的一个算法，MongoDB 采用了该算法来保证当主节点故障或者网络分区的情况下，数据的一致性。
当然 MongoDB 用的和 raft 原版算法肯定会略有不同，MongoDB 会采用 Secondary 向 Primary 拉数据，而不是 Primary 向 Secondary 推数据的方式来减轻 Primary 的压力等等有利于数据库操作的方式对 raft 进行改进使用。
raft 算法动画演示：
http://thesecretlivesofdata.com/raft/ ③关于超大规模复制集(集群)

文章插图

Non-Voting Members
上图是一个拥有 7 个可投票从节点，一个主节点，两个不可投票从节点。

{"_id" : <num>,"host" : <hostname:port>,"arbiterOnly" : false,"buildIndexes" : true,"hidden" : false,"priority" : 0,// 设置为0"tags" : {},"slaveDelay" : NumberLong(0),"votes" : 0// 设置为0 }

MongoDB 最多允许 50 个节点，但是最多只有 7 个节点有投票权，一个节点可以配置 7 个无投票权的 Non-Voting 节点，加上一个 Primary 节点。
为什么只能允许存在 7 个投票节点呢?参考上节的 raft 算法，节点越多，投票时间越长，选举出来的 Primary 节点时间也就越长，这个过程中我们是无法进行写操作的，因为没有主节点。
那么多非投票节点有什么用呢?大家应该都听过 MySQL 的读写分离吧，利用读写分离来提高数据库性能。
MongoDB 这里其实也可以，Primary 用来写，Secondary 用来读，可以给 BI 部门一个 Secondary，给财务部门一个 Secondary，给运营部门一个 Secondary······
④WriteConcern
既然我们的数据库拥有至少超过三个节点(1Primary+2Secondary)，Secondary 通过同步 Primary 的数据来保持一致性，那么当我们写操作的时候，如何保证数据安全的落盘呢?