腾讯Cmongo数据库架构与优化实践VIP

1、技术创新，变革未来腾讯Cmongo数据库架构与优化实践01CMongo简介02整体架构03功能特性&最佳实践04未来规划MongoDBNoSQL领头羊，增长势头持续、强劲灵活高效的文档模型灵活性灵活的表结构：Schema-free 丰富的索引类型Binary-json友好的交互方式易扩展优秀的 横向+纵向 扩缩容能力分片之间自动负载均衡，对用户使用透明灵活可配的迁移策略，将性能影响降到最低企业级功能审计：优于官方企业版的审计能力 存储加密全链路限流中文全文索引高性能专业内核团队：贴近业务定制内核特性 多种插件式引擎：WiredTiger/RocksDB/InMemory/Mmap优秀的读写性能

2、：具体参考腾讯云 官方测试报告CMongo简介整体架构OSS+内核+运营系统Master管控核心模块集群生命周期管理 对外RPC接口资源管理Supervisor集群拨测、告警巡检、健康状态报告 自动化运维Worker宿主机agent 进程管理机器资源管理管控架构计算存储分离架构（coming）内核架构原生架构功能特性管控内核集群创建、删除、扩缩容备份、回档故障处理监控、告警智能诊断资源隔离容量、连接数控制跨地域容灾资源管理3.2开始支持从库snapshot读（官方4.0版本才支持该特性）geoNear优化（相比原生性能提升10倍）MongoRocks优化基于checkpoint的不停服物理备份

3、大量短连接下随机数生成算法优化白名单免密动态resize oplog（代码已被官方接受）TTL索引优化审计、加密内核全链路过载保护（业界独家）skip + limit优化hdfs/cos管控-企业级数据安全备份/回档高效备份回档，有“备”无患，兜底数据安全多副本数据多副本，高效HA只读/灾备实时同步，镜像集群审计、加密请求可追踪，整链路数据加密多种类型secondary、hidden、delay、arbiter等支持50个从节点自动HA容灾节点状态定期巡检多副本挑战：资源利用最大化？多副本高效容灾节点角色持久化解决方案：机房、机架、机器多维度容灾降序最佳适应算法(BFD)，避免碎片，提升资源利

4、用率节点迁移、变更带状态整实例回档 VS. 库表回档可回档到7天任意时刻snapshotrestore nowReplay oplog备份回档逻辑备份 VS. 物理备份全量备份 VS. 增量备份（oplog）动态调整备份间隔，保证备 份连续覆盖7天时间分片回档分片集群回档数据+路由分片集群回档时间全局有效性 回档“脏数据”过滤同城多AZ+异地灾备 解决方案跨地域容灾跨地域容灾挑战：同步速度数据一致性如何保证?异常处理断点续传状态监控&故障恢复oplog由串行改并行回放， 速度提升N（并发数）倍DDL串行处理源和目标定期比对、校验rollback的优雅处理灾备集群只读权限控制增量阶段oplog

5、ts持久化同步状态实时上报审计审计范围DDLCRUD可选开启审计规则支持动态增删改查 灵活性高(细粒度)亮点审计实时监控支持同步/异步两种模式 性能损耗5%以内秒级监控异常告警定期巡检过载保护弹性伸缩自动化运维管控-核心PaaS服务能力秒级监控秒级监控整体架构新版监控：秒级监控系统关键指标上报集中式改为分布式架构旧版监控：监控粒度粗缺乏关键指标集中式上报，可用性低扩展性差Scale up：扩节点资源扩从节点，上限50Scale out：扩分片数，上限128弹性伸缩弹性伸缩-加节点方案一：基于原生加节点逻辑逻辑同步建索引耗时太久影响源节点initial-sync方 案 二 ： hotbackup

6、直接拷 贝文件新建节点影响源节点，尤其高 峰期可能导致业务雪 崩hotbackup最终方案 方案三：基于远端热备文件加节点对源节点无影响充分利用冷备文件尽可能加快恢复速度低峰期热备COS文件下载&加节点全量文件 导入增量回放Standalone模式启动Apply Oplog，做增量回放主动写自己的Oplog表加入原副本集，成为从节点巡检目标：集群健康体检，提前发现集群潜在风险自动化运维自动处理确定性故障，快速修复问题，保证集群可用性健康检查故障汇聚处理决策自动化运 维操作通知supervisorETCDRuntimemongodmongos确定性故障卡主recover且 oplog追不 上假死

7、内部连接 池满节点类故障机器类故障磁盘只读磁盘坏块掉盘内存故障周期+窗口频率控制白名单可用区维度 集群维度适用性能特别敏感的客户，低峰 期再补充节点全链路内核流控内核-深度优化定制Skip+limit优化K歌和Q音的评论、作品“大翻页“：几十甚至上百页的翻页跳转cursor只能顺序读，需使用skip+limitskip+limit优化问题：性能差，QPS上不去mongos入流量是出流量上百倍mongos cpu接近打满skip+limit优化优化思路：命中单个shard，skip下推到mongod版本对比请求总数并发数耗时网卡流量mongos-CPUmongod-CPU原生版本20056.3s

8、120MB/s30%13%优化版本20050.6s1MB/s1.7%14%网卡流量下降 2 个数量级CPU利用率（peak）降低 1 个数量级性能提升 1 个数量级（备注：测试场景为查询数据落在单分片）skip+limit优化性能对比全链路流控线上问题：原生集群缺少流控短时大量请求打垮集群流控方案：嵌入式设计，无需额外模块自适应平滑限流全内核逻辑全链路流控限流因子：资源 cpu/mem/io/net锁 ar/aw、qr/qw等QPS tcp Vegas效果：更加平滑稳定的QPS业务请求突发，系统不雪崩限流因子阈值动态可配动态开关业务 场 景管控 平 台内核生 态 融 合 MongoDB托管服务 管控操作运维系统作业调度监控告警资源管理运维web定时任务读写拨测实例管理工具系统备份回档故障检测作业调度健康巡检生命周期管理采集上报性能鉴权优化