随着近年来私有云技术及云基础设施的倒退，越来越多的企业转为应用私有云来托管本人的服务。云数据库因为数据可靠性、资源弹性、运维便捷行，云上数据库服务也正成为企业数据管理的较好的抉择。
本文以叮咚买菜自建MongoDB数据库整体迁徙上腾讯云MongoDB为背景，分享叮咚买菜上云过程中的遇到的疑难问题及对应的性能优化解决办法等，次要包含以下分享内容：
云上MongoDB版本选型
平安上云及切换计划
叮咚买菜业务侧性能优化
上云遇到的疑难问题及解决办法
自建上云收益
1.叮咚买菜自建MongoDB上云背景
叮咚买菜业务以生鲜即时配送为外围，兼备新批发电商和生鲜供应链的特点，对高并发和数据一致性有硬性要求。在疾速扩张的过程中，很多服务技术选型以MongoDB作为其次要数据存储。相比其余非即时业务场景，叮咚买菜对数据库拜访时延、稳定性、数据一致性、数据安全性也有更刻薄的要求。
借助腾讯云MongoDB产品欠缺的自动化运维、数据安全备份回档、云弹性等能力，能够疾速补齐叮咚买菜的外围MongoDB数据库根底技术能力，确保数据团队能够熟能生巧的撑持业务开发。
叮咚数据团队基于自建成本、物理资源有余等起因，通过综合评估，决定把MongoDB数据迁徙到腾讯云MongoDB上。
2.云上版本举荐及切换计划
业务正式开始迁徙前，联合叮咚DBA和业务同学理解具体场景、MongoDB集群部署形式、业务MongoDB用法、内核版本、客户端版本、客户端driver类型等。提前理解到用户第一手信息：
自建MongoDB版本较低
客户端driver次要包含java和PHP
集群部署都带tag
集群存在较频繁的抖动问题
2.1. 腾讯云MongoDB内核版本举荐
叮咚自建MongoDB因历史起因统一放弃在官网MongoDB-3.2版本，在一些场景存在性能瓶颈，例如用户主从读写拆散时候会遇到读超时等问题。思考到用户对性能要求较高，同时联合以下技术点，最终举荐用户应用腾讯云MongoDB-4.0版本，次要起因如下：
非阻塞从节点读(叮咚买菜遇到的低版本次要问题)
MongoDB-4.x开始，引入了非阻塞的从节点读(Non-Blocking Secondary Reads)，彻底解决了3.x版本从节点批量重放oplog时候加全局ParallelBatchWriterMode类型MODE_X锁引起的读从节点读阻塞问题。
存储引擎优化(低版本的次要问题)
相比3.2版本，4.0对存储引擎做了很多优化，例如cache脏数据淘汰、锁粒度、更全的引擎参数调整反对等，极大的解决了低版本后盾加索引、大流量读写等引起的客户端拜访阻塞问题。
更好的写性能
相比3.2版本，除了下面提到的非阻塞从节点读引起的读性能晋升外，在写性能方面4.0也更有劣势。
更多有用新性能
通过几个大版本迭代，4.0版本相比3.2新增了十分多有用性能，例如Retryable Writes(可重试写)、Change Streams(变更流操作)、Tunable Consistency(更强的可调一致性)、Schema Validation(模式查看)、平安性能加强、事务反对、更丰盛的操作类型等。
分片模式集群扩容balance效率更高
4.0版本相比3.2版本，减少分片扩容后的数据迁徙采纳更好的并发迁徙策略，扩容数据迁徙速率更高。
为何不抉择更高的MongoDB版本
MongoDB版本越高性能越多，例如更高版本反对分布式事务、多字段hash片建反对等。因为叮咚次要是正本集集群，并且对这些新性能需要不强烈，同时综合集群稳定性思考，最终抉择4.0版本。
客户端driver版本兼容性，缩小用户客户端革新老本
因为内核版本较低，如果降级到高版本，首先须要思考对应客户端driver版本是否兼容低版本driver。如果客户端版本和内核不兼容，则须要进行driver降级甚至代码革新，因而客户端driver兼容性也是MongoDB内核版本抉择的一个要害指标。叮咚技术团队通过验证，确认客户端版本齐全兼容4.0内核，代码无需任何革新。
罕用客户端driver与MongoDB内核版本兼容性详见：
Driver类型
官网兼容性阐明
Java
https://docs.mongodb.com/driv...
golang
https://docs.mongodb.com/driv...
php
https://docs.mongodb.com/driv...
其余
https://docs.mongodb.com/driv...
2.2. 平安上云迁徙计划
叮咚自建MongoDB集群蕴含局部重要数据，务必保障迁徙的数据一致性。罕用通用迁徙计划如下：
通用迁徙计划
下面的迁徙计划步骤如下：
步骤1：腾讯云DTS for MongoDB全量+增量形式实时同步自建数据到云上MongoDB
步骤2：抉择凌晨业务低峰期判断DTS提早进度，提早追上后，业务停写
步骤3：确保源集群最初一条oplog同步到指标集群，客户端IP地址切到指标集群
通过下面的操作步骤，最终实现不同版本的MongoDB上云。然而，该上云计划有个危险，假如业务切换到指标新集群后局部读写有问题，这时候就须要回滚到源自建集群。因为切换到新集群过程后，可能局部写流量到了指标集群，这时候指标集群相比源集群就会有更多的数据。这时候，切回到源集群后，也存在数据不统一的状况，即便把指标集群增量oplog回写到源集群，也可能存在乱序写入引起的数据凌乱问题。
优化计划
为了解决极其状况下回滚引起的数据失落、数据凌乱、数据不统一等问题，叮咚业务集群采纳如下更加平安可回滚切割计划：
当业务流量从源叮咚自建MongoDB-3.2集群切换到腾讯云MongoDB-4.0后，如果存在版本兼容、业务拜访异样等问题，则可间接回滚到腾讯云MongoDB-3.2版本，因为回滚集群和源自建集群版本统一，并且通过DTS实时同步，因而，能够肯定水平保障回滚流程数据不凌乱、不抵触、不失落，也可保障切割出问题时候的疾速回滚。
因为叮咚业务MongoDB存储了局部重要数据，不容许数据失落及凌乱，对数据一致性要求极高。以后计划在切换过程中，仍存在向前回滚时数据提早、连贯串更换后利用写错等危险。因而为了确保实时同步及回滚数据一致性十拿九稳，除了DTS的回滚计划，叮咚在业务侧减少了几层爱护：通过订阅和扫描，针对外围库的数据进行校验；通过流量检测进行业务反查；如果呈现业务数据不统一，能够通过工具进行可灰度、可控速的形式进行补齐。
3.叮咚自建MongoDB上云遇到的问题及优化解决办法
叮咚不同业务从3.2版本上云降级到4.0版本过程中，遇到了一些性能瓶颈问题，次要包含以下问题：
腾讯云MongoDB短链接性能优化
叮咚业务侧短链接优化
Session定期刷新引起的集群抖动问题
3.1.短链接性能优化解决办法
以叮咚集群其中某业务为例，该业务局部接口应用PHP driver，因而会波及到大量的MongoDB短链接拜访，以下别离阐明叮咚自建集群短链接瓶颈优化及腾讯云MongoDB短链接优化过程。
3.1.1. PHP业务短链接瓶颈起因
PHP一次申请拜访，须要如下交互过程日志如下：
2021-11-04T12:45:36.621+0800 I NETWORK [conn6] received client metadata from … 2021-11-04T12:45:36.621+0800 I COMMAND [conn6] command admin.$cmd command: isMaster … 2021-11-04T12:45:36.622+0800 I COMMAND [conn6] command adminxx.users command: saslStart … 2021-11-04T12:45:36.626+0800 I COMMAND [conn6] command admin.$cmd command: saslContinue … 2021-11-04T12:45:36.627+0800 I ACCESS [conn6] Successfully authenticated as principal … 2021-11-04T12:45:36.627+0800 I COMMAND [conn6] command adminxx.users command: saslContinue 2021-11-04T12:45:36.627+0800 I COMMAND [conn6] command admin.$cmd command: ping… 2021-11-04T12:45:36.627+0800 I COMMAND [conn6] command x.test command: find { find: "test" 2021-11-04T12:45:37.636+0800 I NETWORK [conn6] end connection …从下面的简化日志能够看出，一次find申请预计须要上面多个操作步骤，并且屡次能力实现，次要流程如下：
TCP三次握手链接
客户端发送isMaster命令给服务端获取所连节点的一些状态信息、协定兼容信息等
进行sasl屡次认证交互
Ping探测获取往返时延
真正的业务拜访，例如这里的find查问申请
四次挥手敞开本次链接对应申请
下面的流程体现出一次拜访，不仅仅建链、断链开销、还有屡次认证交互以及其余额定交互开销，最终无效拜访只占用极少一部分开销，有效拜访节约了零碎大部分开销。此外，PHP业务单次访问的总时延减少，单次访问总时延如下：
PHP单次访问时延=建链工夫+isMaster()交互工夫+认证工夫+ping工夫+数据拜访工夫
3.1.2.叮咚自建MongoDB集群短链接部署优化
该用户集群尽管数据量不是很大，然而流量较高，读写总流量数万/秒，如果间接采纳一般正本集模式集群，则存在MongoDB存储节点因为短链接流量高引起的负载问题。叮咚自建MongoDB为了解决短链接拜访引起的瓶颈问题，采纳如下架构：
上图为某业务集群，业务读写流量较高，总流量数万/S，其中有一部分PHP业务。思考到PHP业务短链接每次拜访须要屡次认证交互，会减少mongo内核压力，因而用户采纳分片架构集群部署，单个分片。客户端程序和mongos部署在同一台服务器，每个客户端通过本地mongodb:///var/run/mongodb-order.sock/拜访，通过该架构来解决短链接带来的性能瓶颈。
3.1.3.腾讯云MongoDB部署架构及优化过程
MongoDB部署架构
腾讯云MongoDB采纳叮咚相似架构，惟一区别是mongos代理叮咚部署在客户端机器本地部署，MongoDB则是独立部署，云上MongoDB部署架构如下：
MongoDB短链接优化
在业务正式上线前，MongoDB团队对PHP短链接进行了提前的摸底测试(后端分片无瓶颈，压一个mongos)，测试后果存在如下景象：
服务器CPU闲暇
listener线程CPU耗费较高
短链接并发越高链接报错比例越高。
后端分片MongoDB无瓶颈
通过剖析，netstat查看发现大量的SYN_RECV 、FIN_WAIT状态的链接，同时客户端大量链接报错，阐明mongos代理解决链接不及时，这和MongoDB内核网络线程模型有较大的关系，MongoDB所有客户端申请由listener线程进行accept解决，accept获取到一个新链接，则创立一个线程，该线程负责该链接当前的所有数据读写。
一个mongos过程只有一个listener线程，当客户端链接并发较高的时候，很容易造成链接排队，最终造成客户端链接超时。不过，该瓶颈能够通过部署多个mongos来解决，多个mongos就会有多个listener线程，accept解决能力就会加强。
最终，综合老本及性能思考，抉择多个最低规格(2PU/4G)的mongos来解决短链接瓶颈。
除了多mongos部署外，还对MongoDB内核listen backlog队列长度进行了适当的调整，缓解队列满引起的客户端链接异样问题。
net.listenBacklog配置在3.6版本开始反对，调研了罕用服务端中间件nginx、redis，这类中间件都反对listen backlog配置，默认取值别离如下：
Nginx默认取值：511
Redis默认取值：511
MongoDB默认取值：SOMAXCONN
SOMAXCONN也就是操作系统/proc/sys/net/core/somaxcon文件中的值，线上默认取值128。批改somaxcon为10240，配置net.listenBacklog为511，放弃和nginx、redis举荐默认值511 统一。通过测试，net.listenBacklog调整后，4C规格测试，短链接异样超时景象会有较大缓解。
listenBacklog配置
测试后果
128
2000并发约10%左右申请链接报错
511
2000并发无任何链接报错
3.2.Session定期刷新业务抖动优化解决过程
3.2降级到4.0版本上云过程中，除了用户短链接PHP瓶颈外，另外一个就是session会话定期刷新引起的业务抖动问题。
3.2.1.业务抖动景象
用户从3.2版本升级到腾讯云4.0版本后，腾讯云MongoDB集群流量监控图如下：
如上图所示，整个景象如下：
update周期性流量尖刺，尖刺周期5分钟
delete周期性流量尖刺，尖刺周期30分钟
流量尖刺过程中，时延也对应减少，周期性抖动
CPU周期性耗费
3.2.2.线下模仿测试
当客户端泛滥，连接数过高的状况下，正本集主节点有霎时大量update甚至delete操作，mongostat和mongotop监控如下(测试条件：500并发短链+500并发长链接，进行insert持续性写入测试)：
mongostat监控发现大量未知update操作，甚至远超过失常insert流量
从下面能够看出，存在大量update更新操作，同时该操作类型统计甚至超过失常的insert写入。
mongotop确定流量来自于哪一个表
500并发短链接及500并发长链接同时进行持续性insert写入测试，发现mongostat监控中存在大量的update更新操作，而咱们的测试中没有进行update更新操作，于是通过mongotop获取update操作起源，监控后果入下图所示：
从上图能够看出，大量的update操作来自于config库的system.sessions表，这是一个潜在隐患。
其余潜在隐患(system.sessions表集中过期)
system.sessions表默认30分钟过期，因为session会话数据都是集中刷新到system.sessions表，因而该表还存在集中过期的状况，集中过期将让update定期更新和过期操作叠加，进一步减轻集群抖动。
3.2.3.session模块内核实现
从MongoDB-3.6版本开始，MongoDB开始逐渐反对单文档事务，从而开始引入session逻辑会话模块。不论是正本集mongod还是分片集群的mongos，都会启动一个定时器刷新cache中缓存的session信息到config库的system.session表中。
通过走读MongoDB内核代码，确定该问题是对system.sessions表做更新引起，内核对应次要代码实现由LogicalSessionCache模块负责session会话治理操作。上面通过一次残缺的客户端拜访为例，剖析session模块外围原理及次要代码实现：
步骤1：客户端发送isMaster命令到服务端，服务端告诉客户端是否反对session治理
客户端通过发送isMaster命令给服务端，如果服务端反对session会话治理模块，则返回session会话超时工夫信息给客户端。
步骤2：客户端申请携带”lsid”信息发送给服务端
服务端收到客户端”lsid”信息后，查看本地cache是否有该session 信息,如果本地cache没有该session信息则增加到本地。一个”lsid”代表一个session会话信息。
如果业务没有创立session信息，则默认对一个链接创立一个会话信息，链接和session一一对应。
步骤3：启动定时器，定期把cache中的session信息system.sessions表中
mongos和mongod实例都会启动一个后盾线程，定期把cache中的所有sessions信息同步到config库的system.sessions表中。同步的session会话信息能够分为以下两类。
1.activeSessions沉闷session
activeSessions会话信息次要包含一个定时器周期沉闷的session信息(一个定时器周期该session对应的客户端有拜访MongoDB)和新创建的session会话信息。
mongos或者mongod会定期把activeSessions信息一条一条一次性update到正本集对应system.sessions表中。
2.endSessions会话信息
endsessions会话信息次要包含客户端显示通过endSession命令完结的会话信息和闲暇工夫超过system.sessions表对应TTL过期工夫的会话信息。
客户端被动触发endSession的session会话信息，mongos也是在同一个定时器中通过remove操作system.sessions表，从而实现cache和system.sessions表的一致性。Remove操作和沉闷session的update操作在同一个定时器实现，update更新结束后，立马进行remove操作。
如果是短链接，并且敞开链接前被动进行了endSession完结会话操作，正本集可能还存在system.sessions表大量remove的操作。
如果session长时间闲暇，则通过system.sessions表的TTL索引来触发本地cache的清理工作。
定时器相干
定时器默认定时工夫5分钟，能够通过logicalSessionRefreshMillis配置。
System.sessions表TTL过期工夫
默认30分钟过期。
会话统计信息
会话统计信息通过“db.serverStatus().logicalSessionRecordCache”命令获取，如下图所示：
logicalSessionRecordCache统计中，能够分为两类：session类统计和transaction事务类统计，外围统计项性能阐明如下：
统计类型
统计项
统计内容阐明
Session统计
activeSessionsCount
以后沉闷会话数
lastSessionsCollectionJobEntriesRefreshed
上一个周期刷新到system.session表的沉闷会话数
lastSessionsCollectionJobEntriesEnded
上一个周期刷新到system.session表的endSessions会话数
lastSessionsCollectionJobCursorsClosed
上一个周期内清理的
Transaction统计
lastTransactionReaperJobEntriesCleanedUp
本周期内清理的transactions表数据条数
3.2.4. Session问题MongoDB内核优化解决
从下面的原理能够看出，业务抖动次要因为cache中的session定期集中式刷新，以分片MongoDB集群为例，内核层面能够通过以下形式优化缓解、也能够通过减少内核配置开关躲避。
无MongoDB内核开发能力：参数调优、部署优化
如果没有MongoDB内核开发能力，能够通过以下办法进行session内核参数调优和部署形式调整来缓解问题：
办法一：mongos及正本集mongod部署工夫打散，防止所有节点定时器同时失效
以后集群默认启动后，所有代理和mongod简直都是同时启动的，代理启动时差较小，session定时器可能同一时间触发，能够手动打散到不同工夫点重启，包含所有mongos和正本集mongod。
办法二：短链接业务思考定时刷新周期适当调短
短链接默认每次申请会生成一个session会话，拜访结束后不会被动告诉MongoDB内核开释session，因而，session在定时周期内会大量挤压，能够思考缩短定时工夫来躲避大量短连贯session的定期刷新操作。例如logicalSessionRefreshMillis从默认5分钟调整为30秒，则集中式的session刷新会散列到多个不同工夫点。
办法三：长链接业务适当调大定时刷新周期
理论测试验证中，默认官网driver长链接(包含golang、java、c客户端测试验证)都是一个链接对应一个session会话id，也就是同一个申请客户端携带的”lsid”放弃不变。MongoDB内核实现中，只有每一个链接对应的定时周期内有一次以上沉闷申请拜访，则会再次缓存该session id，session id刷新到config.sessions表中后，cache中会革除。
从下面的长链接session cache流程能够看出，个别长链接用户都是连接池配置，总连接数越高session也会越高。因而长链接能够通过以下调整缩小session定期刷新的影响：
管制连接池最大连接数，缩小cache中的session总量
适当调大logicalSessionRefreshMillis刷新周期，缩小频繁刷新的影响
内核减少禁用session会话性能开关
在3.6以下版本，MongoDB是没有session会话治理模块的，为了反对事务和可重试写性能而引入。
剖析了MongoDB-c-driver客户端，发现客户端第一次报文交互是否携带“lsid”给服务端是依据isMaster的返回内容中是否携带由” logicalSessionTimeoutMinutes”来决定的，如下：
实际上用户从MongoDB-3.2版本升级到4.0，用户也不须要事务、可重试写性能，客户端齐全没必要默认走session id生成流程。如果客户端不触发session id(也就是报文交互中的”lsid”)，则就不会触发Mongo服务端内核启用session定期刷新功能模块。因而，能够思考在MongoDB内核代码实现中，客户端isMaster获取相干信息的时候，不返回“logicalSessionTimeoutMinutes”信息，这样客户端就不会生成”lsid”信息发送给服务端。
4.0官网代码默认写死，MongoDB内核实现减少session模块反对开关，如果业务没有事务等需要，内核不应答“logicalSessionTimeoutMinutes”信息给客户端，这样客户端认为服务端不反对该性能，就不会被动生成session id交互。
阐明：session会话模块性能开关反对，以后已验证c driver、java、php，测试验证session问题彻底解决，应用该性能切记对客户端进行提前验证，可能不同客户端对logicalSessionTimeoutMinutes解决逻辑不统一，特地是应用spring+MongoDB整合的客户端。3.2.5.叮咚长链接session问题用户侧优化
叮咚用户某长链接通过腾讯云MongoDB提供的节点地址本人对集群也做了具体的流量监控，监控曲线如下图所示：
在对该长链接用户进行MongoDB内核优化前，能够看出流量周期性尖刺，并且发现一个归类：随着该java长链接流量qps越高，定期的sessionupdate尖刺越重大。
利用线上MongoDB进行复现，应用MongoDB官网java driver测试后果和之前的长链接剖析统一，也就是一个链接一个session会话，也就是java服务定期最大的session update不会超过总连接数。然而叮咚用户的java服务通过MongoDB内核日志，看到如下景象：
Thu Sep 2 18:07:19.833 I COMMAND [conn48527] command xx.xxx command: insert { insert: "xx", ordered: true, $db: "xx", $clusterTime: { clusterTime: Timestamp(1630577239, 387), signature: { hash: BinData(0, B37C8600CE543BEE2D8085730AADD91CB13C14AF), keyId: 7002593870005403649 } }, lsid: { id: UUID("3ce872be-5a8d-4a1b-b656-8ba33b3cb15d") } } ninserted:1 keysInserted:2 numYields:0 reslen:230 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 1 } }, oplog: { acquireCount: { w: 1 } } } protocol:op_msg 0ms Thu Sep 2 18:07:19.921 D COMMAND [conn48527] run command xx.$cmd { insert: "xxxx", ordered: true, $db: "xxx", $clusterTime: { clusterTime: Timestamp(1630577239, 429), signature: { hash: BinData(0, B37C8600CE543BEE2D8085730AADD91CB13C14AF), keyId: 7002593870005403649 } }, lsid: { id: UUID("ab3e1cb8-1ba1-4e03-bf48-c388f5fc49d1") } } Thu Sep 2 18:07:19.922 I COMMAND [conn48527] command xxx.xxx command: insert { insert: "oxxx", ordered: true, $db: "maicai", $clusterTime: { clusterTime: Timestamp(1630577239, 429), signature: { hash: BinData(0, B37C8600CE543BEE2D8085730AADD91CB13C14AF), keyId: 7002593870005403649 } }, lsid: { id: UUID("ab3e1cb8-1ba1-4e03-bf48-c388f5fc49d1") } } ninserted:1 keysInserted:2 numYields:0 reslen:230 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 1 } }, oplog: { acquireCount: { w: 1 } } } protocol:op_msg 0ms Thu Sep 2 18:07:19.765 I COMMAND [conn48527] command xxx.xxx command: find { find: "xxx", filter: { status: { $in: [ 1, 2, 4, 5, 9, 11, 13, 3, 7, 15 ] }, order_number: "xxxxxxxxxxxxxxxxxxx", is_del: false }, sort: { _id: -1 }, $db: "xxx", $clusterTime: { clusterTime: Timestamp(1630577239, 375), signature: { hash: BinData(0, B37C8600CE543BEE2D8085730AADD91CB13C14AF), keyId: 7002593870005403649 } }, lsid: { id: UUID("ed1f0fd8-c09c-420a-8a96-10dfe8ddb454") } } planSummary: IXSCAN { order_number: 1 } keysExamined:8 docsExamined:8 hasSortStage:1 cursorExhausted:1 numYields:0 nreturned:4 reslen:812 locks:{ Global: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_msg 0ms 从下面的日志能够看出，即便是同一个长链接下面的屡次会话，客户端也会携带多个不同的”lsid”发送给MongoDB服务端，因而须要解决为何java服务同一个链接屡次拜访会生成多个session id，即”lsid”。
通过排查客户端，最终定位问题是客户端的埋点监控在降级到MongoDB-4.0后，触发每次申请生成一个新的”lsid”。
4.叮咚买菜自建上云收益总结
自建MongoDB迁徙腾讯云MongoDB后，带来了如下收益：
通过梳理拆分，把一些外围的简单的MongoDB集群，垂直拆分为多个集群，耦合性升高，稳定性进步
集群稳定性进步，上云前业务遇到的各种MongoDB拜访毛刺和抖动问题失去了彻底解决
腾讯云MongoDB相比自建MongoDB性能更好，并可能充分利用云的弹性扩容能力，不必预留过多的硬件资源，从而节俭了较大老本
腾讯云MongoDB欠缺的监控告警、数据备份回档、跨地区容灾、实时巡检、7x24小时在线服务等，使得可运维性、数据安全、故障预发现等能力得以加强
迁徙到腾讯云，也能够利用腾讯云技术团队的技术劣势，帮忙剖析定位解决一些MongoDB深层次的疑难技术问题
对于作者
叮咚买菜技术团队：
叮咚买菜根底技术，撑持叮咚买菜外围业务的资源、数据、基础架构，是一支技术背景深厚、充斥激情与现实、保持同指标共进退，打胜仗的团队。尤其器重技术人才培养和倒退成长，很多技术骨干都是外部成长倒退起来的。
腾讯云MongoDB团队：
腾讯云MongoDB以后服务于游戏、电商、社交、教育、新闻资讯、金融、物联网、软件服务等多个行业；MongoDB团队(简称CMongo)致力于对开源MongoDB内核进行深度钻研及持续性优化(如百万库表、物理备份、免密、审计等)，为用户提供高性能、低成本、高可用性的平安数据库存储服务。后续继续分享MongoDB在腾讯外部及内部的典型利用场景、踩坑案例、性能优化、内核模块化剖析。