万字21图！手把手教你设计一个超级牛逼的 Feed 流系统( 四 ) ★★★建议星标我们★★★2

我们接下来逐一来看。
4.1 用户详情和列表
主要是用户的详情，包括用户的各种自定义属性和系统附加的属性，这部分的要求只需要根据用户ID查询到就可以了。
可以采用的分布式NoSQL系统或者关系型数据库都可以。
如果使用NoSQL数据库Tablestore ，那么用户详情表设计结构如下：
文章插图
4.2 关注或好友关系
这部分是存储关系，查询的时候需要支持查询关注列表或者粉丝列表，或者直接好友列表，这里就需要根据多个属性列查询需要索引能力，这里，存储系统也可以采用两类，关系型、分布式NoSQL数据库。

如果已经有了关系型数据库了，且数据量较少，则选择关系型数据库，比如MySQL等。
如果数据量比较大，这个时候就有两种选择：

使用具有索引的系统，比如云上的Tablestore ，更简单，吞吐更高，扩容能力也一并解决了。
需要分布式事务，可以采用支持分布式事务的系统，比如分布式关系型数据库。

如果使用Tablestore ，那么关注关系表设计结构如下：
Table：user_relation_table

文章插图
多元索引的索引结构：

文章插图
查询的时候：

如果需要查询某个人的粉丝列表：使用TermQuery查询固定user_id ，且按照timestamp排序。
如果需要查询某个人的关注列表：使用TermQuery查询固定follow_user_id ，且按照timestamp排序。
当前数据写入Table后，需要5~10秒钟延迟后会在多元索引中查询到，未来会优化到2秒以内。

除了使用多元索引外，还可以使用GlobalIndex 。
4.3 推送session池
思考一个问题，发送者将消息发送后，接收者如何知道自己有新消息来了？客户端周期性去刷新？如果是这样子，那么系统的读请求压力会随着客户端增长而增长，这时候就会有一个风险，比如平时的设备在线率是20%~30% ，突然某天平台爆发了一个热点消息，大量休眠设备登陆，这个时候就会出现“查询风暴” ，一下子就把系统打垮了，所有的用户都不能用了。
解决这个问题的一个思路是，在服务端维护一个推送session池，这个里面记录哪些用户在线，然后当用户A发送了一条消息给用户B后，服务端在写入存储库和同步库后，再通知一下session池中的用户B的session ，告诉他：你有新消息了。然后session-B再去读消息，然后有消息后将消息推送给客户端。或者有消息后给客户端推送一下有消息了，客户端再去拉。
这个session池使用在同步中，但是本质还是一个元数据，一般只需要存在于内存中即可，但是考虑到failover情况，那就需要持久化，这部分数据由于只需要指定单Key查询，用分布式NoSQL或关系型数据库都可以，一般复用当前的系统即可。
如果使用Tablestore ，那么session表设计结构如下：

文章插图
5. 评论
除了私信类型外，其他的feed流类型中，都有评论功能，评论的属性和存储库差不多，但是多了一层关系：被评论的消息，所以只要将评论按照被被评论消息分组组织即可，然后查询时也是一个范围查询就行。这种查询方式很简单，用不到关系型数据库中复杂的事务、join等功能，很适合用分布式NoSQL数据库来存储。
所以，一般的选择方式就是：

如果系统中已经有了分布式NoSQL数据库，比如Tablestore、Bigtable等，那么直接用这些即可。
如果没有上述系统，那么如果有MySQL等关系型数据库，那就选关系型数据库即可。
如果选择了Tablestore ，那么“评论表”设计结构如下：

文章插图
如果需要搜索评论内容，那么对这张表建立多元索引即可。
6. 赞
最近几年， “赞”或“like”功能很流行，赞功能的实现和评论类似，只是比评论少了一个内容，所以选择方式和评论一样。
如果选择了Tablestore ，那么“赞表”设计结构同评论表，这里就不再赘述了。
系统架构中加了元数据系统后的架构如下：