业务背景及业务mongodb规模
全民K歌作为腾讯音乐集团四大产品线之一，月活超过1.5亿，并不断推出新的音娱功能及新玩法，极大丰富了数亿用户的音乐娱乐活动。
mongodb天然支持高可用、分布式、高性能、高压缩、schema free、完善的客户端访问均衡策略等功能。因此，作为腾讯音乐集体核心部门，K歌业务众多业务采用腾讯云cmongo作为主存储服务，极大的方便了K歌业务的快速迭代开发。当前，cmongo在全民K歌推荐系统、feed信息流、ugc、画像等业务线中被广泛使用。
K歌信息流业务核心数据采用腾讯云cmongo进行数据存储，该业务采用mongodb分片架构，集群使用模式及规模如下：
- 峰值流量：数十万/秒
- 分片数：数个
- 单个分片副本数：1主4从
- 读写分离
- ……
本文主要分享K歌技术演进过程中的一些踩坑过程、方案设计、性能优化等，主要包括以下技术点：
- 全民K歌业务特性
- Feed业务读写如何选项
- Feed核心表设计
- Feed数据吐出控制策略优化
- K歌业务层面踩坑及优化过程
- K歌业务mongodb使用踩坑及优化
- 腾讯云cmongo内核新特性在K歌业务中的使用
第一章：业务层面优化过程
- 腾讯音乐全民K歌业务特性
每一个社交产品，都离不开feed流设计，在全民K歌的场景，需要解决以下主要问题：
- 我们有一些千w粉丝，百万粉丝的用户，存在关系链扩散的性能挑战
- feed业务种类繁多，有复杂的业务策略来控制保证重要的Feed的曝光
对于feed流的数据吐出，有种类繁多的控制策略，通过这些不同的控制策略来
-
- 大v曝光频控，避免刷流量的行为
- 好友共同发布了一些互动玩法的Feed，进行合并，避免刷屏
- 支持不同分类feed的检索
- 安全问题需要过滤掉的用户feed
- 推荐实时插流/混排
- 低质量的Feed，系统自动发类型的Feed做曝光频控
- 读写选型
![]()
Feed主流实现模型主要分为3种，这些模型在业界都有大型产品在用：
- 读扩散 （QQ空间）
- 写扩散 （微信朋友圈）
- 大v读扩散+普通用户写扩散 （新浪微博）
没有最好的模式，只有适合的架构，主要是权衡自己的业务模型，读写比，以及历史包袱和实现成本。
K歌使用的是读扩散模型，使用读扩散模型的考虑如下：
- 存在不少千万/百万粉丝的大v，写扩散严重，推送延迟高，同时存储成本会高
- 低活用户，流失用户推送浪费计算资源和存储资源
- 安全合规相关的审核会引发大量写扩散
- 写扩散qps=3 x 读扩散qps
- K歌关系链导入的历史原因，早起写扩散成本高，同时后期改成读写扩散混合的模式改造成本大。
但是读扩散模式存在以下比较明显的缺点：
- 翻页把时间线前面的所有数据拉出来，性能开销越来越大，性能越来越差
- 关注+好友数量可达万级别，实现全局的过滤，插流，合并，频控策略复杂，性能不足
3. 主要表设计
3.1. Feed表设计
Feed这里的设计建立了2个表：
该表使用用户userid做片健，feedid做唯一健，表核心字段如下：
![]()
该表使用uid做片健和唯一健，并且做ttl，表核心字段如下：
![]()
FeedCache是一个kv存储的文档，k是uid，value是CacheFeedData jce序列化后的结果。
3.2. 账号关系表设计
关注关系链常规涉及两个维度的数据：
一个关注，一个粉丝 (一个关注动作会产生两个维度数据)。
关注一般不是很多，最多一般只有几千，经常会被全部拉出来，这个可以存储为kv的方式（高性能可以考虑内存型数据库或cache)。
关注是用Redis存储的，一个key对应的value是上面RightCache这个结构的jce序列化后的结果。
![]()
粉丝会是一个长列表(几百万甚至上千万)，一般会以列表展示，存储与mongodb中，以用户id为片健, 每个粉丝作为一个单独的doc，使用内存型的存储内存碎片的损耗比较高，内存成本大。关注和粉丝数据可以使用消息队列来实现最终一致性。
粉丝是mongodb的文档，主要是fuid，realtiontype，time。
![]()
4.读扩散优化
读扩散模型的存储数据主要分为3大块：
4.1. 优化背景
未优化前的关系链读扩散模型，每次拉取Feed数据的时候，都需要通过关系链，时间戳，以及Feed索引数据来读扩散构建候选结果集。最后根据具体的Feedid拉取Feed详情来构建结果进行返回。
对于首屏，如果一页为10条，通过关系链+最新时间戳过滤出最新的20个uid（预拉多一些避免各种业务过滤合并策略把数据过滤完了），然后拉取每个uid最新的60条Feed的简单的索引信息来构建候选集合，通过各种业务合并过滤策略来构建最多10条最新Feedid，再拉取Feed详细信息构建响应结果。
翻页的时候把上一次返回的数据的最小时间戳basetime带过来，然后需要把basetime之前的有发布feed的uid以及basetime之后有发布的最近20个uid过滤出来，重复上面构建候选集合的过程来输出这一页的数据。这种实现逻辑翻页会越来越慢，延迟不稳定。
4.2. 优化过程
针对以上问题，所以我们在读扩散模型上进行了一些优化，优化架构图如下：
![]()
我们通过读扩散结果的Cache模式，解决翻页越来越慢，复杂的全局过滤逻辑。
Cahce优势
- 灵活过滤，实现复杂的过滤合并逻辑
- 翻页读Cache性能高，首页使用Cache避免重复计算
时间线Cache需要解决的问题？弊端？
- 关系链变更Cache有延迟
- 脏feed导致Cache体积减小
此外，我们把Cache主要分为全量生成过程，增量更新过程，以及修补逻辑三部分来解决这些问题：
- 全量是在首次拉取，和24小时定时更新
- 增量则是在首页刷新，无最新数据则复用Cache
- 通过缓存关系链，如果关系链变更，活脏Feed太多过滤后导致的Cache体积过小，则触发修补逻辑。
最终，通过这些策略，让我们的Feed流系统也具备了写扩散的一些优势，主要优势如下：
- 减少重复计算
- 有全局的Feed视图，方便实现全局策略
粉丝求count慢优化
前面提到，粉丝关系表存在mongodb中，每条数据主要包含几个字段，用户的每个粉丝对应一条mongodb文档数据，对应数据内容如下：
1. { "_id" : ObjectId("6176647d2b18266890bb7c63"), "userid" : “345”, "follow_userid" : “3333”, "realtiontype" : 3, "follow_time" : ISODate("2017-06-12T11:26:26Z") }
一个用户的每个粉丝对应一条数据，如果需要查找某个用户下面拥有多少个粉丝，则通过下面的查询获取(例如查找用户id为”345”的用户的粉丝总数)：
db.fans.count({"userid" : “345”})
该查询对应执行计划如下：
1. {
2. "executionSuccess" : true,
3. "nReturned" : 0,
4. "executionTimeMillis" : 0,
5. "totalKeysExamined" : 156783,
6. "totalDocsExamined" : 0,
7. "executionStages" : {
8. "stage" : "COUNT",
9. "nReturned" : 0,
10. ......
11. "nSkipped" : 0,
12. "inputStage" : {
13. "stage" : "COUNT_SCAN",
14. ......
15. }
16. },
17. "allPlansExecution" : [ ]
18. }
和其他关系型数据库(例如mysql)类似，从上面的执行计划可以看出，对某个表按照某个条件求count，走最优索引情况下，其快慢主要和满足条件的数据量多少成正比关系。例如该用户如果粉丝数量越多，则其扫描的keys(也就是索引表)会越多，因此其查询也会越慢。
从上面的分析可以看出，如果某个用户粉丝很多，则其count性能会很慢。因此，我们可以使用一个幂等性计算的计数来存储粉丝总数和关注总数，这个数据访问量比较高，可以使用高性能的存储，例如Redis的来存储。幂等性的计算可以使用Redis的lua脚本来保证。
优化办法：粉丝数量是一个Redis的key，用lua脚本执行（计数key incrby操作与opuid_touid_op做key的setnx expire）来完成幂等性计算。
满足这个条件，则直接返回一个可能的计算过程的幂等性验证，设计一个可行的高可用方案进行处理，这个过程的处理过程可以整的明天，分片的查询性能的最大化功能，如何实现这个最大化过程的设计。
第二章：mongodb使用层面优化
该业务mongodb部署架构图如下：
![]()
如上图所示，K歌业务mongodb架构图客户端通过腾讯云VIP转发到代理mongos层，代理mongos接受到请求后，从config server(存储路由信息，架构图中未体现)获取路由信息，然后根据这条路由信息获取转发规则，最终转发该请求到对应的存储层分片。
在业务上线开发过程中，发现mongodb使用的一些不合理，通过对这些不合理的数据库使用方式优化，提升了访问mongodb的性能，最终提升了整个feed流系统用户体验。K歌业务mongodb访问优化点如下：
1. 最优片建及分片方式选择
前面提到信息流业务feed详情表、粉丝列表存储在mongodb中，两个表都采用用户 userId来做分片片建，分片方式采用hashed分片，并且提前进行预分片：
sh.shardCollection("xx.follower", {userId:"hashed"}, false, { numInitialChunks: 8192*分片数} )
sh.shardCollection("xx.feedInfo", {feedId:"hashed"}, false, { numInitialChunks: 8192*分片数} )
两个表分别选择feedId和userId做片建，并且采用hashed分片方式，同时提前对表做预分片操作，主要基于以下方面考虑：
通过提前预分片并且采用hashed分片方式，可以保证数据均衡的写入到不同分片，避免数据不均引起的moveChunk操作，充分利用了每个分片的存储能力，实现写入性能的最大化。
通过feedId查询某条feed详情和通过userId查询该用户的粉丝列表信息，由于采用hashed分片方式，同一个Id值对应的hash计算值会落在同一个shard分片，这样可以保证整个查询的效率最高。
说明：由于查询都是指定id类型查询，因此可以保证从同一个shard读取数据，实现了读取性能的最大化。但是，如果查询是例如feedId类的范围查询，例如db.feedInfo.find({feedId:{$gt: 1000，$lt:2000}})，这种场景就不适合用hashed分片方式，因为满足{$gt: 1000}条件的数据可能很多条，通过hash计算后，这些数据会散列到多个分片，这种场景范围分片会更好，一个范围内的数据可能落到同一个分片。所以，分片集群片建选择、分片方式对整个集群读写性能起着非常重要的核心作用，需要根据业务的实际情况进行选择。
2. 查询不带片建如何优化
上一节提到，查询如果带上片建，可以保证数据落在同一个shard，这样可以实现读性能的最大化。但是，实际业务场景中，一个业务访问同一个表，有些请求可以带上片建字段，有些查询没有片建，这部分不带片建的查询需要广播到多个shard，然后mongos聚合后返回客户端，这类不带片建的查询效率相比从同一个shard获取数据性能会差很多。
如果集群分片数比较多，某个不带片建的查询SQL频率很高，为了提升查询性能，可以通过建立辅助索引表来规避解决该问题。以feed详情表为例，该表片建为用户userId，如果用户想看自己发表过的所有feed，查询条件只要带上userId即可。
但是，如果需要feedId获取指定某条feed则需要进行查询的广播操作，因为feed详情表片建为userId，这时候性能会受影响。不带片建查询不仅仅影响查询性能，还有加重每个分片的系统负载，因此可以通过增加辅助索引表(假设表名：feedId_userId_relationship)的方式来解决该问题。辅助表中每个doc文档主要包含2个字段：
该字段和详情表的feedId一致，代表具体的一条feed详情。
该字段和详情表userId一致，代表该feedId对应的这条feed详情信息由该user发起。
feedId_userId_relationship辅助表采用feedId做为片建，同样采用前面提到的预分片功能，该表和feed详情表的隐射关系如下：
![]()
如上图，通过某个feedId查询具体feed，首先根据feedId从辅助索引表中查找该feedId对应的userId，然后根据查询到的userId+feedId的组合获取对应的详情信息。整个查询过程需要查两个表，查询语句如下：
1. //feedId_userId_relationship表分片片建为feedId，提前hashed预分片
2. db. feedId_userId_relationship.find({“feedId”: “375”}, {userId:1}) //假设返回的userId为”3567”
3. //feedInfo表分片片建为userId，提前hashed预分片
4. db. feedInfo.find({“userId”: “3567”})
如上，通过引入辅助索引表，最终解决跨分片广播问题。引入辅助表会增加一定的存储成本，同时会增加一次辅助查询，一般只有在分片shard比较多，并且不带片建的查询比较频繁的情况使用。
3. 读写分离
mongodb读策略默认支持多种访问策略，根不同业务需求，由客户端配置指定，通过readPreference配置选项进行设置，支持以下多种读策略：
读primary主节点，如果不做任何配置，默认为该配置。
优先读主节点，如果主节点异常，则读从节点。
读全部通过从节点读数据，减少主节点压力
从优先读，从异常后，读主节点
选择离自己网络延迟最小的节点访问，在跨可用区部署场景下，一般采用该配置
K歌业务在发展初期，采用默认的读primary主节点方式进行数据读操作，前期查询都很正常，但是随着K歌业务规模的增长，业务访问主节点开始出现瓶颈：“主节点卡死、备节点闲死”。
当前，业务的访问QPS已经超过数十万/秒，集群中的每个分片一主四从，从节点非常空闲，资源比较浪费。调整读策略为SecondaryPreferred配置后，主节点压力释放，业务访问不在抖动。
4. 数据备份过程业务抖动优化
![]()
腾讯云cmongo默认凌晨会定期对集群数据做全量备份和增量备份，并支持默认7天内的任意时间点回档。但是，随着集群数据量逐渐的增加，当前该集群数据量已经比较大，开始出现凌晨集群定期抖动，主要现象如下：
- 访问时延增加
- 慢日志增加
- CPU使用率增加
通过分析，发现问题和数据备份时间点一致，由于物理备份和逻辑备份期间需要对整实例进行数据备份，系统资源负载增加，最终影响业务查询服务。
优化方式：数据备份期间隐藏节点，确保该节点对客户端不可见。
5. 排序查询索引优化
在排序类查询中，经常出现慢查，以下面查询为例：
Db.feedInfo.find({userId: “353”, feedtype: 4 }).sort({userId: 1, feedtype: -1 })
提前对该查询加索引：{userId: 1, feedtype: 1 }
该SQL中查询条件是{userId: “353”, feedtype: 4 }，排序方式{userId: 1, feedtype: 1 }，字段一样，上线后发现很多慢查，通过分析其执行计划，发现该查询存在内存排序现象，因为某些用户满足查询条件的数据较多，甚至超过数万，加重了内存排序负担。该查询对应执行计划如下：
1. db.feedInfo.find({userId:"353","feedtype":4}).sort({"userId" : 1, "feedtype" :-1}).explain().queryPlanner.winningPlan
2. {
3. "stage" : "SORT",
4. "sortPattern" : {
5. "userId" : 1,
6. "feedtype" : -1
7. },
8. "inputStage" : {
9. "stage" : "SORT_KEY_GENERATOR",
10. "inputStage" : {
11. "stage" : "FETCH",
12. "inputStage" : {
13. "stage" : "IXSCAN",
14. "keyPattern" : {
15. "userId" : 1,
16. "feedtype" : 1
17. },
18. "indexName" : "userId_1_feedtype_1",
19. "isMultiKey" : false,
20. "multiKeyPaths" : {
21. "userId" : [ ],
22. "feedtype" : [ ]
23. },
24. "isUnique" : false,
25. "isSparse" : false,
26. "isPartial" : false,
27. "indexVersion" : 2,
28. "direction" : "forward",
29. "indexBounds" : {
30. "userId" : [
31. "[\"353\", \"353\"]"
32. ],
33. "feedtype" : [
34. "[4.0, 4.0]"
35. ]
36. }
37. }
38. }
39. }
40. }
从上面的查询可以看出，该查询走了userId_1_feedtype_1索引，其执行步骤如下：
步骤1：根据userId_1_feedtype_1查找满足{userId:"353","feedtype":4}条件的所有数据，这里满足条件的数据可能数万行。
步骤2：根据生成的排序key，按照{userId: 1, feedtype: -1 }排序规则，也就是userId正序，feedtype反序的方式对步骤1的数万行数据进行内存排序。
从上面的分析可以看出，整个查询因为内存排序过程繁琐响应比较慢，仔细分析查询条件和排序条件，于是优化索引，保持和sort排序条件一致，创建新的{userId: 1, feedtype: -1 }索引，其执行计划如下：
1. db.feedInfo.find({userId:"353","feedtype":4}).sort({"userId" : 1, "feedtype" :-1}).explain().queryPlanner.winningPlan
2. {
3. "stage" : "FETCH",
4. "inputStage" : {
5. "stage" : "IXSCAN",
6. "keyPattern" : {
7. "userId" : 1,
8. "feedtype" : -1
9. },
10. "indexName" : "userId_1_feedtype_-1",
11. "isMultiKey" : false,
12. "multiKeyPaths" : {
13. "userId" : [ ],
14. "feedtype" : [ ]
15. },
16. "isUnique" : false,
17. "isSparse" : false,
18. "isPartial" : false,
19. "indexVersion" : 2,
20. "direction" : "forward",
21. "indexBounds" : {
22. "userId" : [
23. "[\"353\", \"353\"]"
24. ],
25. "feedtype" : [
26. "[4.0, 4.0]"
27. ]
28. }
29. }
30. }
上面的执行计划相比前面内存排序更加简介，整个查询过程直接通过sort排序索引userId_1_feedtype_-1快速返回满足条件的数据。
排序索引调整后的时延对比如下：
![]()
关于作者
全民K歌后台开发一组：
ctychen，ianxiong
腾讯云mongodb：
腾讯云MongoDB当前服务于游戏、电商、社交、教育、新闻资讯、金融、物联网、软件服务等多个行业；MongoDB团队(简称CMongo)致力于对开源MongoDb内核进行深度研究及持续性优化(如百万库表、物理备份、免密、审计等)，为用户提供高性能、低成本、高可用性的安全数据库存储服务。后续持续分享MongoDb在腾讯内部及外部的典型应用场景、踩坑案例、性能优化、内核模块化分析。
