本文次要讲述 vivo 评论中台在数据库设计上的技术摸索和实际。

一、业务背景

随着公司业务倒退和用户规模的增多，很多我的项目都在打造本人的评论性能，而评论的业务状态根本相似。过后各我的项目都是各自设计实现，存在较多反复的工作量；并且不同业务之间数据存在孤岛，很难产生分割。因而咱们决定打造一款公司级的评论业务中台，为各业务方提供评论业务的疾速接入能力。在通过对各大支流 APP 评论业务的竞品剖析，咱们发现大部分评论的业务状态都具备评论、回复、二次回复、点赞等性能。

具体如下图所示：

波及到的外围业务概念有：

【主题 topic】评论的主题，商城的商品、利用商店的 APP、社区的帖子
【评论 comment】用户针对于主题发表的内容
【回复 reply】用户针对于某条评论发表的内容，包含一级回复和二级回复

二、数据库存储的抉择

团队在数据库选型设计时，比照了多种支流的数据库，最终在 MySQL 和 MongoDB 两种存储之进行抉择。

因为评论业务的特殊性，它须要如下能力：

【字段扩大】业务方不同评论模型存储的字段有肯定差别，须要反对动静的主动扩大。
【海量数据】作为公司中台服务，数据量随着业务方的增多成倍增长，须要具备疾速便捷的程度扩大和迁徙能力。
【高可用】作为中台产品，须要提供疾速和稳固的读写能力，可能读写拆散和主动复原。

而评论业务不波及用户资产，对事务的要求性不高。因而咱们选用了 MongoDB 集群 作为最底层的数据存储形式。

三、深刻理解 MongoDB

3.1 集群架构

因为单台机器存在磁盘/IO/CPU等各方面的瓶颈，因而以 MongoDB 提供集群形式的部署架构，如图所示:

次要由以下三个局部组成：

mongos：路由服务器，负责管理利用端的具体链接。利用端申请到mongos服务后，mongos把具体的读写申请转发到对应的shard节点上执行。一个集群能够有1~N个mongos节点。
config：配置服务器，用于分存储分片汇合的元数据和配置信息，必须为复制集(对于复制集概念戳我) 形式部署。mongos通过config配置服务器合的元数据信息。
shard：用于存储汇合的分片数据的mongod服务，同样必须以复制集形式部署。

3.2 片键

MongoDB 数据是存在collection(对应 MySQL表)中。集群模式下，collection依照片键（shard key）拆分成多个区间，每个区间组成一个chunk，依照规定散布在不同的shard中。并造成元数据注册到config服务中治理。

分片键只能在分片汇合创立时指定，指定后不能批改。分片键次要有两大类型：

hash分片：通过hash算法进行散列，数据分布的更加均匀和扩散。反对单列和多列hash。
范畴分片：依照指定片键的值散布，间断的key往往散布在间断的区间，更加适用范围查问场景。单数据散列性由分片键自身保障。

3.3 评论中台的实际

3.3.1 集群的扩大

作为中台服务，对于不同的接入业务方，通过表隔离来辨别数据。以comment评论表举例，每个接入业务方都独自创立一张表，业务方A表为 comment_clientA ，业务方B表为 comment_clientB，均在接入时创立表和相应索引信息。但只是这样设计存在几个问题：

单个集群，不能满足局部业务数据物理隔离的须要。
集群调优(如split迁徙工夫)很难业务个性差异化设置。
程度扩容带来的单个业务方数据过于扩散问题。

因而咱们扩大了 MongoDB的集群架构：

扩大后的评论MongoDB集群减少了【逻辑集群】和【物理集群】的概念。一个业务方属于一个逻辑集群，一个物理集群蕴含多个逻辑集群。
减少了路由层设计，由利用负责扩大Spring的MongoTemplate和连接池治理，实现了业务到MongoDB集群之间的切换抉择服务。
不同的MongoDB分片集群，实现了物理隔离和差别调优的可能。

3.3.2 片键的抉择

MongoDB集群中，一个汇合的数据部署是扩散在多个shard分片和chunk中的，而咱们心愿一个评论列表的查问最好只拜访到一个shard分片，因而确定了范畴分片的形式。

起初设置只应用单个key作为分片键，以comment评论表举例，次要字段有{"_id":惟一id,"topicId":主题id,"text":文本内容,"createDate":工夫} ,思考到一个主题id的评论尽可能间断散布，咱们设置的分片键为 topicId。随着性能测试的染指，咱们发现了有两个十分致命的问题：

jumbo chunk问题
惟一键问题

jumbo chunk：

官网文档中，MongoDB中的chunk大小被限度在了1M-1024M。分片键的值是chunk划分的惟一根据，在数据量继续写入超过chunk size设定值时，MongoDB 集群就会主动的进行决裂或迁徙。而对于同一个片键的写入是属于一个chunk，无奈被决裂，就会造成 jumbo chunk 问题。

举例，若咱们设置1024M为一个chunk的大小，单个document 5KB计算，那么单个chunk可能存储21W左右document。思考热点的主题评论(如微信评论)，评论数可能达到40W+，因而单个chunk很容易超过1024M。超过最大size的chunk仍然可能提供读写服务，只是不会再进行决裂和迁徙，短暂以往会造成集群之间数据的不均衡.

惟一键问题：

MongoDB 集群的惟一键设置减少了限度，必须是蕴含分片键的；如果_id不是分片键，_id索引只能保障单个shard上的唯一性。

You cannot specify a unique constraint on a hashed index
For a to-be-sharded collection, you cannot shard the collection if the collection has other unique indexes
For an already-sharded collection, you cannot create unique indexes on other fields

因而咱们删除了数据和汇合，调整 topicId 和 _id 为联结分片键从新创立了汇合。这样即突破了chunk size的限度，也解决了唯一性问题。

3.4 迁徙和扩容

随着数据的写入，当单个chunk中数据大小超过指定大小时(或chunk中的文件数量超过指定值)。MongoDB集群会在插入或更新时，主动触发chunk的拆分。

拆分会导致汇合中的数据块散布不平均，在这种状况下，MongoDB balancer组件会触发集群之间的数据块迁徙。balancer组件是一个治理数据迁徙的后盾过程，如果各个shard分片之间的chunk数差别超过阈值，balancer会进行主动的数据迁徙。

balancer是能够在线对数据迁徙的，然而迁徙的过程中对于集群的负载会有较大影响。个别倡议能够通过如下设置，在业务低峰时进行（更多见官网）

db.settings.update({ _id: "balancer" },{ $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } },{ upsert: true })

MongoDB的扩容也非常简单，只须要筹备好新的shard复制集后，在 Mongos节点中执行：

sh.addShard("<replica_set>/<hostname><:port>")

扩容期间因为chunk的迁徙，同样会导致集群可用性升高，因而只能在业务低峰进行

四、写在最初

MongoDB集群在评论中台我的项目中已上线运行了一年多，过程中实现了约10个业务方接入，承载了1亿+评论回复数据的存储，体现较为稳固。BSON非结构化的数据，也撑持了咱们多个版本业务的疾速降级。而热门数据内存化存储引擎，较大的进步了数据读取的效率。

但对于MongoDB来说，集群化部署是一个不可逆的过程，集群化后也带来了索引，分片策略等较多的限度。因而个别业务在应用MongoDB时，正本集形式就能撑持TB级别的存储和查问，并非肯定须要应用集群化形式。

以上内容基于MongoDB 4.0.9版本个性，和最新版本的MongoDB细节上略有差别。

参考资料：https://docs.mongodb.com/manual/introduction/

作者：vivo 官网商城开发团队