目录
[1 复制集(replset)](#1 复制集(replset))
[2 分片](#2 分片)
[3 片键](#3 片键)
一、原理
数据可用与安全
可用性与安全性：数据冗余
1 复制集(replset)
在mongoDB中：复制集
复制集的主要意义在于实现服务高可用，类似于Redis中的哨兵模式
结构
一主多从多仲裁
- Primary:可读可写
- Secondary：只读
- Arbiter：不读不写（仲裁）
实现高可用的同时，还有其他几个作用：
数据分发:将数据从一个区域复制到另一个区域，减少另一个区域的读延迟
读写分离:不同类型的压力分别在不同的节点上执行
异地容灾:在数据中心故障时快速切换到异地
复制集架构图
复制集成员:
Primary:主节点
一个复制集只能同时存在一个主节点，接受数据写入，接受读请求。
Secondary:从节点
一个复制集可同时存在多个从节点，从主节点同步数据，不可直接写入数据，
可以接受读请求。
Arbiter:投票节点只负责选主，不存储数据，不承载读写。
复制集主从同步
同步方式:全量同步与增量同步
1.全量同步:增加一个新的从节点;增量同步失效。
2.增量同步:正常同步;通过oplog。
oplog:主节点的操作日志。
ts:操作时间
o:操作内容
从节点记录自己最新的一次同步时间，之后每隔一段时间向主节点查询有没有更新的操作。
复制集故障恢复
复制集故障恢复:
主节点: 需要与复制集中一半以上的节点正常连通。
故障恢复:
主节点挂掉之后，会有一个从节点提升为主节点。
选主策略:
优先度最高，oplog最新且与复制集中一半以上的节点正常连通。
投票选举:Arbiter参与选举，不会选自己。
2 分片
解决性能与存储扩展
单机不能满足要求:
存储性能:
硬盘存储空间不够
计算性能:
内存不够，查询缓慢
IO不够，写入缓慢
分片(sharding)基本原理:按照某些字段的范围，把数据分布在不同的机器上。
mongos:路由服务器。
config:存储配置，分片等信息。
shard:存储数据的分片可以是单机mongod，也可以是复制集。
图
一次请求过程:
请求到mongos:mongos对外提供服务
mongos根据请求内容，查询本地缓存的config 信息(虚线不是每次都去config查询)，将请求发送到正确的shard。
shard处理完信息，返回给mongos。
mongos返回给请求方。
3 片键
片键就是mongos做路由的字段。
{x:5,y:10,z:13}
x是片键规则:
x<3 到 shard1
3<=x<8到shard2
x>= 8到 shard3
片键应具备的特点:
- 片键应使写入应在所有分片大致致均衡。
- 片键应使查询尽可能不跨分片。
- 并不一定存在完美的片键。
- 避免选出明显糟糕的片键。
糟糕的片键:
_id: 自增，所有新数据都写到一个分片。与之类似，所有自增的片键都是不合适的。
与查询无关:
即使写入均衡，查询会占用所有分片资源。比如用驱动生成的_id做hash(_id)片键。
基数小:比如一个boolean值或者几个有限的falg。
eg: 网盘
记录用户信息，使用用户id：uid作为片键
写入是否均衡:不完美均衡，有活跃用户与僵尸用户的区别。
查询是否均衡:同上，不完美。
但是有相当大的基数，这种不完美是可以接受的。
使用集群前，做均衡与预分配
数据库结构
即使是一个分片，也推荐使用sharding
一个分片的sharding性能会比单机差一些。
后期好扩展。
即使是单机，也推荐使用复制集。
oplog会浪费一部分磁盘空间。
后期增加冗余方便。
如果可能，相互备份的节点
(mongos，复制集成员，config,arbiter)
尽量部署在不同的机房。
灾难性事件发生也有容错的余地。