单机版
- 主要用来开发和测试，一般不用于生产环境
复制集
目的
- 主要为了高可用，可以failover
- 读写分离，读可以分担到不同节点
- 可以跨机房，甚至异地容灾
- 数据同步到另外一个区域节点，可以减少区域延迟
基本架构
image.png
高可用实现
- 通过raft一致性来保证主从副本的一致性
- 通过raft来实现failover
- 写入设置write conren选项保证大多数节点同步到oplog
cluster
目的
- 增大存储
- 增大IO
- 地理分布
基本架构
image.png
config server
- 存储集群的元数据，key的范围对应到具体的shard
mongos
- 主要承担路由的功能
- 查询sort，以及count等操作会在mongos上合并排序的等操作，因为数据可能在不同shard上
mongod
- 存储chunk的数据库，这里为了高可用，需要部署成复制集的模式
cluster的特点
- 对应用全透明，无需特殊处理，可以认为是一个超大数据库
- 数据自动平衡，chunk自动balance
- 动态扩容，无需下线
- 提供三种分shard的方式
- 基于range，优化连续读，但是容易造成不均衡，比如连续的id
- 基于hash，优化写，适合大量写入场景，对范围查询不友好
- 基于zone，可以打tag，不同区域写入到不同的shard，比如北京地区写入北京地区的shard，上海写入上海的。
如何用好cluster
- 关于数据：数据单个shard 不要超过3T，最好2T一个shard
- 关于索引：常用索引最好可以全部纳入内存，可以通过db.col.stats压测估算
- mongos和config一般消耗很少资源，mongs需要多点cpu，count以及sort会用到，config占用资源很少
- 集群数量不太大，可以mongs和app-server部署一起，集群数量太大，mongos单独部署
- config的部署最好跨机房，最次也跨机柜
- mongod内存要能容纳索引以及热数据，mongod毕竟还是磁盘数据库，推荐ssd
两地三中心
基本架构
image.png
- mongo可以甚至选举优先级，冷备可以不用参与选举
- 如果北京海淀DC挂了，就会自动选举到朝阳DC
- 如果北京整个都挂了，可以手动恢复上海浦东的DC
建议
- 主数据中心两个节点选举优先级可以提高一点，避免垮机房切换中心点
- 同城双中心，保证低延迟和带宽，因为需要保证writeconern: majority的双中心写需求
- 业务要处理好双中心切换
