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

文章插图
7. 搜索
到此，我们已经介绍完了Feed流系统的主题架构， Feed流系统算是完成了。但是Feed流产品上还未结束，对于所有的feed流产品都需要有搜索能力，比如下面场景：

微博中的搜索用户。
搜索微博内容。
微信中搜索好友等。

这些内容搜索只需要字符匹配到即可，不需要非常复杂的相关性算法，所以只需要有能支持分词的检索功能即可，所以一般有两种做法：
使用搜索引擎，将存储库的内容和用户信息表内容推送给搜索系统，搜索的时候直接访问搜索系统。
使用具备全文检索能力的数据库，比如最新版的MySQL、MongoDB或者Tablestore 。
所以，选择的原则如下：

如果存储库使用了MySQL或者Tablestore ，那么直接选择这两个系统就可以了。
如果整个系统都没使用MySQL、Tablestore ，且已经使用了搜索系统，那么可以直接复用搜索系统，其他场景都不应该再额外加一个搜索系统进来，徒添复杂度。

如果使用Tablestore ，那么只需要在相应表上建立多元索引即可：

如果需要对用户名支持搜索，那么需要对user_table建立多元索引，其中的nick_name需要是Text类型，且单字分词。
如果需要对Feed流内容支持搜索，那么需要对存储库表：store_table建立多元索引，这样就能直接对Feed流内容进行各种复杂查询了，包括多条件筛选、全文检索等。

系统架构中加了搜索功能后的架构如下：

文章插图
8. 排序
目前的Feed流系统中的排序方式有两种，一种是时间，一种是分数。
我们常用的微博、朋友圈、私信这些都是时间线类型的，因为这些产品定义中，需要我们主动关注某些人后才会看到这些人发表的内容，这个时候，最重要的是实时性，而不是发布质量，就算关注人发布了一条垃圾信息，我们也会被动看到。这种类型的产品适用于按照时间线排序。这一篇我们介绍的架构都是基于时间类型的。
另外一种是不需要关注任何人，我们能看到的都是系统希望我们看到的，系统在后台会分析我们的每个人的爱好，然后给每个人推送差异化的、各自喜欢的内容，这一种的架构和基于时间的完全不一样，我们在后续的推荐类型中专门介绍。
9. 删除Feed内容
在Feed流应用中有一个问题，就是如果用户删除了之前发表的内容，系统该如何处理？因为系统里面有写扩散，那么删除的时候是不是也要写扩散一遍？这样的话，删除就不及时了，很难应对法律法规要求的快速删除。
针对这个问题，我们在之前设计的时候，同步表中只有消息ID ，没有消息内容，在用户读取的时候需要到存储库中去读消息内容，那么我们可以直接删除存储库中的这一条消息，这样用户读取的时候使用消息ID是读不到数据的，也就相当于删除的内容，而且删除速度会很快。除了直接删除外，另外一种办法是逻辑删除，对于删除的feed内容，只做标记，当查询到带有标记的数据时就认为删除了。
10. 更新Feed内容
更新和删除Feed处理逻辑一样，如果使用了支持多版本的存储系统，比如Tablestore ，那么也可以支持编辑版本，和现在的微博一样。
11. 总结
上面介绍了不同子功能的特点和系统要求，能满足需求的系统主要有两类，一类是阿里云的Tablestore单系统，一类是开源组件组成的组合系统。

开源组件组成的组合系统：包括MySQL、Redis、HBase等，这些系统单个都不能解决Feed流系统中遇到的问题，需要组合在一起，各司其职才能完成一个Feed流系统，适用于热衷开源系统，人多且喜欢运维操作的团队。
Tablestore单系统：只使用Tablestore单个系统就能解决上述的所有问题，这时候肯定有人要问？你是不是在吹牛？这里不是吹牛， Tablestore在三年前就已经开始重视Feed流类型业务，之前也发表过多篇文章介绍，功能上也在专门为Feed流系统特别定制设计，所以到今天，只使用Tablestore一款产品，是可以满足上述需求的。选择Tablestore做Feed流系统的用户具有以下一些特征：
产品设计目标规模大，千万级或亿级。
不喜欢运维，喜欢专注于开发。
高效率团队，希望尽快将产品实现落地。
- 上一页
- 1
- 2
- 3
- 4
- 5
- 6
- 下一页