mongodb工作模式

单机版

• 主要用来开发和测试，一般不用于生产环境

复制集

目的

• 主要为了高可用，可以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的方式
  1. 基于range，优化连续读，但是容易造成不均衡，比如连续的id
  2. 基于hash，优化写，适合大量写入场景，对范围查询不友好
  3. 基于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的双中心写需求
• 业务要处理好双中心切换