李晓慧：如何利用MongoDB打造爆款小程序

Posted 2021-05-01 云加社区

本文整理自作者在云加社区线下沙龙活动中的精彩分享，主题内容大概是两部分，第一部分：在现网运营中服务小游戏以及爆款小游戏积累的经验。在现网运维中我们做了一些改动，帮助爆款小游戏能够稳定运行。

第二部分我们推出了一套新的解决方案，适合小白开发者，适合初创公司，可以在微信开发小程序的同时，能够使用腾讯云的资源，享受腾讯云的各种服务。

以下为分享内容：

大家好，我叫李晓慧，我没有一页PPT介绍自己，我就自己简单说一下，我以前是一个开发，我感觉很孤独，因为开发的女生很少，我转过两次组，然后一开始做C++开发，后来用C++做后台开发，后来用php、JS、Python进行前台开发和运营开发，整个过程我都感觉有点孤独的。

后来我转产品经理，之后做的第一个产品是时序数据库，现在马上就要计费了，现在做的是MongoDB，做了产品经历之后，感觉责任很大，toB要多接近客户，今天我感觉来这么多人，我感觉真的是很开心，因为这么近距离跟我已有的客户或者未来要成为我的客户交流。昨天拜访了一个客户，他的业务侧的开发其实是不太强的，主要靠我们的数据库，拜访完之后就感觉责任很大，对于初创公司的话，我们这种数据库团队其实责任还是非常大的，我的心路历程以及自我介绍就这样。

今天我分享的主题内容大概是两部分，最主要的还是小游戏和小程序，第一部分就是跟大家分享下我们在现网运营中服务小游戏以及爆款小游戏积累的经验。在现网运维中我们做了一些改动，帮助爆款小游戏能够稳定运行。第二部分我们推出了一套新的解决方案，适合小白开发者，适合初创公司，可以在微信开发小程序的同时，能够使用腾讯云的资源，享受腾讯云的各种服务。

先讲第一部分的内容，刚才邹鹏最后讲的一段的时候，一直有一个图片，那个图片就是各种数据库的排名，可能大家没有注意到，MongoDB的排名其实已经是第五名，再说一下MongoDB为什么适合游戏开发场景。我们知道游戏开发中一个最主要的特点是需求变化非常快的，因为在游戏不同的阶段会加入一些新的元素黏住用户，例如道具，在游戏上线的不同阶段加不同道具，这种用传统的关系型数据库不免对表进行结构修改的DDL的操作，可能有些开发者说不需要，之前做的就是把所有的字段打包成一个字段塞进一个库表就可以了。使用MongoDB不需要改变表结构，对开发者是非常Nice的。另外，大多数游戏会添加社交元素增强用户的活跃度，黏住用户。我们提供了地理位置索引以及配套的API，不需要在业务层做操作，数据库层已经原生支持了。海量数据的支持，我们提供了分片的功能，其实数据最开始，在业务上线最开始阶段，并不知道到底将来是什么样的量级。使用关系型数据库的话，后期避免不了进行分库分表，扩容，MongoDB这边提供了分片集群，可以在不影响业务的同时进行水平的扩容，这个对运维来说是非常好的解决方案。

运营分析，现在是大数据时代，每个业务都会根据数据分析的结果支持运营策略，我们是原生支持MapReduce的，开发者可以直接使用。还有一点非常重要，假如你是小程序开发的话，用JS语言写，存在javascript技术栈MEAN和MERN，MongoDB和Nodejs两者是伴随成长起来的。总之，MongoDB特别适合游戏开发场景。

我想问一下现在在座的有没有用我们腾讯云MongoDB的？或者是有没有用MongoDB的？自建也可以。你们用MongoDB存什么数据？（目前搜集用户行为日志）是自建的吗？（对，本来想用云上，后来发现自建会便宜一点）一主两从还是一主一从？（做副本集，三个部分，没有固定说哪个是主）实例多大？（现在几十G的数据量）你们买的CVM是多大？（500G空间，我们前期使用起来，现在一个方向还不太明确，就是一个试探，我在之前用的都是阿里的比较多，腾讯是今年才开始接触）我大概了解了，所以说我觉得今天能站在这分享，跟这么多用户见面，对我个人来说是非常高兴的一件事，至少我知道大家现在怎么使用以及有没有用，不用我一一拜访了。

小游戏的调用栈，很多开发者都非常清楚，我只需要简单的带过，一般会在前面加负载均衡，然后通过虚拟机搭建服务器，后面连数据库。

我刚才跟大家提了我们其实在现网服务过很多爆款小游戏了，最主要的一个目的就是能够让客户的游戏稳定运行，我们在服务他们的过程中，累积了一些运维经验，做了一些连接参数的调优，帮客户实现实例价值的最大化。

首先跟大家简单分享一下MongoDB的连接模型，分两部分，第一部分是Mongos对客户端的连接，第二是Mongos对后端的连接，第一部分连接采用的是非常古老的方式，叫one-Thread-per-connection，每个连接分配一个线程，每个线程栈1MB内存，1000个连接是1G内存，所以，MongoDB对连接是非常敏感的。对后端连接的模型就是每个Mongos会绑定一个Worker池，假如你有三分片，每个分片是一主两从，那就是9个Mongod，每个worker就会有9个连接。

这里有一个参数，如果这个参数设计的不合理，业务体量比较高的情况下，后面连接池子的线程是不够用的，就会进行频繁的线程调度和切换，因为线程的切换和调度的开销是比较大的，所以运维人员比较关心的就是minConnection这个参数，这个参数我们是单独提出来能够给运维人员直接修改的，这个参数的设置有一个公式，这个公式就是你需要根据，比如当前TPS为1000，每个连接要求处理10毫秒，2个分片,minConnection=1000/2/(1000/10)。则第二个参数也是运维人员比较关心的，第二就是refreshRequirement，就是每个业务会有一个估算的连接峰值，那么refreshRequirement设置要超过5分钟才行。以上是我们对MongoDB连接模型的优化。

第二个我们服务现网很多小游戏时遇到的慢查询问题。很多用户比较了解MongoDB的话，因为是一主两从，就会为了减少主的压力，就设置把读请求打到从，从可以同步数据，也可以接收读请求，主就做接收写请求，这是理想的方案，但是我们服务用户过程中发现这个方案也会带来问题，因为从3.2版本，引擎就默认是WT。WT引擎有一个操作就是从在同步数据的时候会加一个全局锁，这个锁会把所有的读请求都锁住，这样的话慢查询就可能会变多，基于这个问题，我们这边是搞了一个专利，这个专利就是基于快照的读的一种方案，就是当你进行从读的时候，此时让你读快照，同步数据完成之后，所有读请求正常，快照被清掉。最左边的图是另外一个解决方案，这种解决方案就是我们提供了一种只读实例，在主实例上挂只读实例，主实例负责接收读写请求，其他业务模块只需要把所有的连接请求打到只读就可以了。这两种解决方案在一般情况下的优势不是非常明显，但是当你的实例Primary写入压力非常大的情况下，效果是非常明显的。最后面有一张图，蓝色部分是源生的Mongo，红色的部分是我们基于读快照的方式的一个性能，X轴是写入大小，Y轴就是从库读请求的延时，我们发现在源生的Mongo中最大的读延时能达到85毫秒左右。用我们的解决方案的话，在10毫秒左右，非常快。以上是我们第二个优化。

业务最开始上线的时候其实并不知道后期量级能达到多少，假设开发人员在最开始的时候申请比较大的实例的话，其实会被运维挑战的。但是假如用分片集群的话，就会避免这个问题。最开始的时候设置很小的，买一个很小的分片，后面你的业务量大起来之后，再水平扩分片。只需要指定分片的Key，就会把数据分到不同的片里面去，自动做均衡，业务无感知。

库表回档，在游戏运维过程中比较痛苦的一件事就需要回档。确实很痛苦，有时候我感觉有些用户回档过程中非常着急，一旦回档应该是发生了比较严重的事，要回档到之前的时间段。因为程序是避免不了有Bug的，或者游戏在上线过程中有一个Leader手抖，发了很多道具，可能造成很多人民币的损失，这个时候就要进行回档。但是仅仅是某个库表进行回档，不需要整实例回档，针对这种情况，我们支持库表回档，对运维人员是非常nice的功能。

我的第二部分内容就是针对小游戏和小程序的一种解决方案。小程序开发和小游戏开发特别是小游戏会遇到一个问题，使用本地缓存30-40M完全不够，如何把小程序赋能到云，我们提供了方案，不需要到腾讯买CVM、数据库、函数，只需要在小程序开发IDE上点击控制台上的按钮，开发者只需要关注业务逻辑的实现，后端的服务器的运维知识都不需要再去了解。小游戏和小程序的特点就是短平快，快速上线，迭代快法，强占市场，通过一些道具和广告迅速变现，生命周期不长。

我们这个解决方案在服务层有数据库的管理、文件的管理、函数的管理，后面还会加一些日志、触发器的服务，底层服务有腾讯云MongoDB、云函数这一套。也就是说刚才我们在服务现网其他游戏中的运维经验的累计都会应用到这个解决方案里面，所以说大家可以放心使用。

开发过程中会有多个环境，开发环境、测试环境、生产环境，在云上开通这套服务之后我们默认会包含多个环境，环境之间是相互隔离的。

这种方案特别适合个人开发者、初创团队，对于成熟团队需要上一些项目的话，可以立即使用。以下是我们的控台，有三个功能，可以创建集合，我们增加了导入和导出功能，可以把其他地方的数据导到这里面让你的小程序直接运行。第二就是索引，我们把索引功能优先开出来了，默认给_id字段加了索引，用户也可以自己增加单列索引和复合索引。另外，权限管理这里也非常精细。

Q&A：

Q：老师，您好，您刚刚讲的关于监控数据，我想问的是关于小程序会让用户看到日志以及监控数据吗？你们有提供报警机制吗？

A：我觉得你应该是深入思考这件事了，确实是，监控和日志很重要，日志很快会包到解决方案里面，用的是ES。现在监控指标跟MongoDB公有云的数据是一样的。告警我们做了策略，会对关键指标的告警系统进行预值自动设定，自动告警，用户自定义告警在短期内还没有提供。

Q： 您好，老师，今天下午辛苦了。我曾经不太了解MongoDB，我听说MongoDB有一个安全的事件，应该在一年以内，但具体时间不清楚，我想了解一下，比如说云上Mongo的安全的这块，你们是怎么做的？

A：安全有两点，第一点是网络，我们会有在前面加了安全组，这样对访问来源IP进行了第一层过滤，安全组，用户可以自己设置。第二我们加了VPC网络，在自己虚拟机同一个网络类的CVM才能访问我们的Mongo，这样就做了网络隔离。第二方面我们有数据加密，我们现在做的是存储型加密，这个加密功能是用户在购买的时候可以选择的，所以说用我们腾讯云MongoDB的安全是完全可以放心的，但是你自建的话可能就没有这么。

Q：您刚说的VPC，如果自建的话，咱们的网络就是独立的。

A：自建的话，VPC可以做到，但是数据层的加密是做不到的。

李晓慧，腾讯云数据库MongoDB产品负责人，多年安全、前端、数据库研发经验。在MongoDB、CTSDB、CRM等产品有丰富的研发经验。

推荐阅读：

关注云加社区，回复 3 加读者群

点击 阅读原文，获取本文PPT文件