本章节主要为您介绍使用表格存储搭建Feed流的方案原理。
方案架构图

存储模块
如架构图所示,Feed流中的以下内容使用表格存储进行存储。
- 个人页Timeline:每个用户的发件箱,也就是自己的个人页页面。
- 关注页Timeline:每个用户的收件箱,也就是自己的关注页页面,内容都是自己关注人发布的消息。
- 关注列表:保存账号关系,例如朋友圈中的好友关系、微博中的关注列表等。
- 虚拟关注列表:主要用来个性化和广告。
发布及读取流程
- 拉结合流程
- 发布Feed
- Feed消息先进入一个队列服务。
- 先从关注列表中读取到自己的粉丝列表,以及判断自己是否是大V。
- 将自己的Feed消息写入个人页Timeline(发件箱)。如果是大V,写入流程到此结束。
- 如果是普通用户,还需要将自己的Feed消息写给自己的粉丝,如果有100个粉丝,那么就要写给100个用户,包括Feed内容和Feed ID。
- 第三步和第四步可以合并在一起,使用BatchWriteRow接口一次性将多行数据写入表格存储。
- 发布Feed的流程结束。
- 读取Feed流
- 先读取自己关注的大V列表。
- 通过GetRange读取自己的收件箱。范围起始位置是上次读取到的最新Feed的ID;结束位置可以是当前时间,也可以是MAX,建议是MAX值。
- 如果有关注的大V,则再次并发读取每一个大V的发件箱。如果关注了10个大V,那么则需要10次访问。
- 合并2和3步的结果,然后按时间排序,返回给用户。
至此,使用推拉结合方式的发布、读取Feed流的流程结束。
- 发布Feed
- 推模式流程
如果只是用推模式了,流程更简单。
- 发布Feed流:不用区分是否大V,所有用户的流程都一样。
- 读取Feed流:不需要第1步,也不需要第3步,只需要第2步即可,将之前的2 + N(N是关注的大V个数)次网络开销减少为1次网络开销。读取延时大幅降级。
个性化和定向广告
个性化和定向广告是需求度很高的两个功能。个性化可以服务好用户,增大产品竞争力和用户粘性。定向广告可以为产品增加盈利渠道,而且不引起用户反感。在Feed流里这两种功能的实现方式类似,我们以实现定向广告的流程为例来说明。
- 通过用户特征分析对用户分类,例如今年刚上大学的新生(新生类)。
说明 具体的用户特征分析可以依靠表格存储 + MaxCompute。
- 创建一个广告账号:新生广告。
- 让这些具有新生特征的用户虚拟关注新生广告账号。
说明 用户看不到这一层关注关系。
- 从七月份开始就通过新生广告账号发送广告。
每个用户可能会有多个特征,那么就可能虚拟关注多个广告账号。
方案优势
使用表格存储架构实现Feed流具有以下优势。
- 只使用1种系统,架构、实现简单。不再需要访问多个系统,架构、开发、测试、运维都能节省人力时间。
- 表格存储主键自增列功能性能极优。表格存储主键列自增不需要表锁和行锁,性能要远远高于关系型数据库。
- 表格存储采用分布式存储,可以存储所有Feed。
- 表格存储的存储成本低,您无须将Feed ID和内容分开存储。
- 全托管服务,无运维操作,更无需分库分表。
- 磁盘型数据库,成本低。
- 可靠性10个9,数据更可靠,更不易丢失。
- 大V和普通用户的切分阈值更高,读取大V的次数更少,整体延时更低。
缺陷及优化方法
如果使用大V/普通用户的切分方式,大V使用拉模式,普通用户使用推模式,那么这种架构就会存在一种很大的风险。例如某个大V突然发了一个很有话题性的Feed,那么就有可能导致整个Feed产品中的所有用户都没法读取新内容,以下是粉丝读取流程:
- 大V发送Feed消息。
- 大V使用拉模式。
- 大V的活跃粉丝(用户群A)开始通过拉模式读取大V的新Feed。
- Feed内容太有话题性,快速传播。
- 未登录的大V粉丝(用户群B)开始登录产品,登录进去后自动刷新,再次通过读3步骤读取大V的Feed内容。
- 非粉丝(用户群C)去大V的个人页Timeline里面去围观,再次需要读取大V个人的Timeline,同读3。
结果就是,平时正常流量只有用户群A,结果现在却是用户群A + 用户群B + 用户群C,流量增加了好几倍,甚至几十倍,导致读3路径的服务模块被打到server busy或者机器资源被打满,导致读取大V的读3路径无法返回请求,如果Feed产品中的用户都有关注大V,那么基本上所有用户都会卡死在读取大V的读3路径上,然后就没法刷新了。
所以设计时需重点关心下面两点:
- 单个模块的不可用,不应该阻止整个关键的读Feed流路径。如果大V的无法读取,但是普通用户的要能返回,等服务恢复后,再补齐大V的内容即可。
- 当模块无法承受这么大流量的时候,模块不应该完全不可服务,而应该能继续提供最大的服务能力,超过的拒绝掉。
优化方法
- 方法一:不使用大V/普通用户的优化方式,而使用活跃用户/非活跃用户的优化方式,这种优化方式能把用户群A和部分用户群B分流到其他更分散的多个路径上去。而且即使读3路径不可用,仍然对活跃用户无任何影响。
- 方法二:完全使用推模式可以彻底解决这个问题,但会增大存储量,并增长大V微博发送总时间,从发给第一个粉丝到发给最后一个粉丝可能要几分钟时间(一亿粉丝,100万行每秒,需要100秒),还需要为最大并发预留好资源(如果使用阿里云表格存储,则不需要考虑预留最大额度资源的问题)。
在文档使用中是否遇到以下问题
更多建议
匿名提交