MongoDB杭州用户交流会于2017年3月12日下午在阿里巴巴西溪园区举行，吸引了来自全国各地的近300名用户参与，千寻位置、妈妈帮、阿里云等公司的5位技术专家分享了MongoDB 的运维管理及使用经验，干货满满。
用户会进行过程中我已经在中文社区微信总群、二群里做了实时的图文直播，这里再做一个重点内容汇总，错过现场的同学可以学习一下，完整的PPT、以及视频云栖社区的同学正在整理中，敬请期待。
首先，来自千寻位置的肖应军同学分享了其统一监控平台使用 MongoDB 的实践经验。
千寻的统一监控平台包含数据采集、分发、存储、报表、监控等多个模块，其中「存储」和「报表」的模块大量使用了mongoDB，分别解决数据存储和数据分析的问题。
在数据存储方面，监控数据拥有固有的特性，比如监控的指标不固定，可能临时增加；数据写入的频率比较固定，不会有大的波峰/谷流量出现；读取的并发量比较低，但一次返回的数据量比较大，同时随着数据不断的累计，存储量会越来越大。而mongoDB能很好的解决上述需求
- mongoDB 无 schema 的特性，使得数据结构扩展起来非常方便
- mongoDB 高性能以及数据压缩的特性完全能慢满足数据存储的需求
- mongoDB 的TTL索引的特性能自动的删除过期的数据，确保存储容量不会无限膨胀
千寻的报表模块经历了2个阶段的发展，第一阶段分析需求比较简单，直接使用 mongoDB 的aggregation、mapReduce做数据分析来完成；而随着业务方越来越多，报表的维度越来越细，开始使用spark（通过mongoDB spark connector）、阿里云EMR等产品配合mongoDB做数据分析，效率更高，并且能满足复杂查询分析的需求。
最后，千寻的同学分析了使用 mongoDB 过程中积累的经验
- 生产环境推荐「1主2次」的配置，保证服务高可用、数据高可靠 (注：要保证高可用，除了后端要多节点，还要正确的使用mongoDB driver，以正确的方式连接复制集）
- 慢查询导致长时间锁库（注：3.x版本wiredtiger引入行级锁后，这个问题应该已经不存在）
- 写入压力大可能导致整个库慢 （注：尤其是备库的读会受影响，参考MongoDB Secondary 延时高（同步锁）问题分析，但数据库压力太大说明资源已经不足了，应该扩容了）
- 建索引时，尽量指定{background: true}选项，后台建索引，避免锁库影响业务。
- mongoshell能直接执行js脚本，能极大的方便集群管理
- 使用TTL索引时，索引的字段必须为时间戳字段（注：官方文档有详细介绍）
- 写入时指定需要的writeConcern级别，推荐{w: 1} （注：3.x的版本里{w: 1}是默认的writeConcern级别，是可靠性与性能的折中选择）
- 自建mongoDB 全部迁移 到 mongoDB云数据库服务，极大的降低了运维管理成本。(注：作为 mongoDB 云数据库的开发者，能得到客户的肯定，感到灰常开心），下面是个广告链接，不感兴趣的请直接跳过
接下来阿里云的技术专家明俨深度解析了mongoDB sharding 备份相关的技术。
mongoDB sharding 解决了写入能力、存储容量扩展的问题，引入了 mongos 用于请求路由，引入 config server 存储sharding 集群的元数据，整个架构相比复制集更加复杂。
sharding 的备份因为「外部修改」以及「内部数据迁移」的影响，使得针对 sharding 集群的备份很难对应都一个确定的时间点。
传统的解决方案是整个集群停止写操作（注：停写的方式包括业务停写，或对secondary调用fsyncLock，或将secondary节点移除），然后对所有shard、config server的数据进行备份，这样的确能回复到一个确定的时间点，但代价很大。
阿里云 MongoDB 数据库针对sharding备份的解决方案是
- 每个 shard 通过 「定期全量备份 + 持续抓取oplog」，具备恢复到任意时间点的能力（时间点精确到秒级别）
- 通过分析config server的迁移操作记录，恢复时避开「可能影响数据不一致的时间区间」（通常很短）。
妈妈帮的技术专家胡兴邦介绍了5年来使用 mongoDB 的经验，妈妈帮从2012年就开始全线使用 mongoDB，从2.2（看版本就知道是资深用户）的版本一路升级到3.2（目前都已升级到3.2的最新版本）。
妈妈帮使用mongoDB一路发展过来，使用的架构也不断演进，主要经历了4个阶段
- 最早的master-slave架构 （注：新接触mongoDB的用户可能不知道这是个啥东西，这是mongoDB早期支持的一种部署模式，跟MySQL的主从架构类似，目前已被复制集替代，不建议使用）
- 业务增长后，使用多组 master-slave 的 mongoDB
- 多组的mongoDB master-slave 升级为 多组复制集
- 多组复制集 + mongoDB sharding
妈妈帮最初选择 mongoDB 主要基于其灵活的文档模型，以及天生可扩展的架构，在业务发展的早期能保证业务快速迭代开发，在业务快速发展之后，还能横向扩展。
在遇到事务方面的需求时（注：mongoDB目前无法支持多文档事务，官方有计划支持），妈妈帮使用了最简单的方式来应对，即「后台定时修正不一致的数据」，其他的备选方案，例如使用消息队列、二阶段提交方式从方案上更加成熟，但实现复杂度更高。
在sharding方面，妈妈帮也积累了不少经验，建议用户在使用sharding时，一定要注意shardKey的选择，并给出了一些建议。
- 能满足业务场景查询需求，尽量保证大部分query条件都由shard key，这样请求只用分发到后端单个shard就能满足，性能更高
- 尽量避免单个shard出现热点 （注：需要正确理解hash分片 和 range分片 2种方式的优劣，做出最适合自己业务的选择）
- 避免shard key的取值过少，导致单个chunk很大（jumbo chunk）而无法自动迁移
- 多阅读官方文档，sharding-shard-key
阿里云资深研发工程师果实介绍阿里云 MongoDB 云数据库高可用的主题，介绍mongoDB云数据库如何实现自动的故障检测及故障转移。
阿里云数据库 MongoDB 版 是由3个节点组成的高可用复制集（目前也已支持sharding形态），3个分别为Primary、Secondary 和 Hidden，其中Priamry、Secondary节点提供给用户读写，Hidden节点对用户不可见，主要用于实例备份以及保证实例高可用。
Hidden节点平时只同步Primary上写入的数据，并不对外提供服务，实例的全量及增量备份会在Hidden上进行，做到不影响用户的业务。
同时，后端管控服务会不断的模拟用户访问行为来探测实例可用性，当发现实例有节点故障时
- 如果 Hidden 节点故障（不可恢复的故障，如果机器没挂，会尝试先重启启动），后端管控会从资源池里选择一个新的节点，以Hidden的身份加入复制集，替换原来的Hidden，这个过程对用户的服务无影响。
- 如果 Secondary 节点故障，会自动将 Hidden 节点切换为 Secondary，保证用户访问 Secondary 节点不受影响。此时变成了1的状态，按1的方式继续故障转移处理。
- 如果 Primary 节点故障，这时复制集会自动选出新的Primary，此时复制集里缺一个Secondary，变成了2的状态，按2的方式继续故障转移处理。
如果出现2台及以上节点故障，根据 MongoDB 多数派的选举原则，是无法选出Primary的，这时实例会进入只读状态，需要人工介入恢复，但这种场景极少出现。（注：这里也可以reconfig一下，让复制集变成单节点运行继续服务读写，但考虑到用户数据的可靠性，目前并没有使用这个方案）
除了故障时的处理，对于计划中的机器维修、下线，则需要对机器上所有的实例，先将该节点切换为Hidden角色，然后针对所有的Hidden节点按上述1的流程处理，用新的节点替换，当节点上没有任何实例数据时，就可以安全下线了。
最后出场的是徐雷老师，徐雷老师是《MongoDB实战》第2版的译者，徐雷老师的分享风趣幽默，不仅讲到MongoDB，还分享了很多架构设计方面的经验，由于当时有事掉线了，没有获取到精髓，等PPT出来大家可以好好学习一下。
在分享里徐老师也提到 MongoDB 目前在国内外各大企业里都有着广泛的应用，充分说明 MongoDB 是一门值得深入投资的技术。
最后，预告一下，MongoDB 中文社区今年还会继续在全国各大城市举行 MongoDB 用户的技术交流会，有强大的社区做后盾，用户们可以更放心的使用 MongoDB；而且 MongoDB 本身官方文档已经非常全面了，绝大多数的问题都能从官方文档找到答案，建议大家多看官方文档，用好 MongoDB，为你的业务创造最大价值。
