苏州官网网站首页,旅游网站建设与规划,制作链接怎么做,私密浏览器在线观看Timeline Feed服务 一、概述1、分类2、功能 二、设计原理1、拉模式与用户发件箱2、推模式与用户收件箱3、推拉模式结合 三、关键技术1、内容与用户收件箱的交互#xff08;推模式#xff09;2、推送拆分子任务3、收件箱模型设计 内容总结自《亿级流量系统架构设计与实战》 一… Timeline Feed服务 一、概述1、分类2、功能 二、设计原理1、拉模式与用户发件箱2、推模式与用户收件箱3、推拉模式结合 三、关键技术1、内容与用户收件箱的交互推模式2、推送拆分子任务3、收件箱模型设计 内容总结自《亿级流量系统架构设计与实战》 一、概述
1、分类
Feed 流的功能在当今的互联网应用和网络社交平台中非常重要它是一种以时间线为基础的信息流展示形式把用户感兴趣的内容呈现在用户的Feed页面上。如果你使用过一些互联网应用就会发现很多互联网应用的主页都是Feed页面它们把Feed流当作自己的“门面”。Feed 流在内容聚合维度上包括但不限于如下几种形式。
推荐 Feed 流按照你的浏览兴趣菜合内容你可能不认识 Feed 流内容的发布者但是他发布的内容你可能很感兴趣。关注 Feed 流你关注的用户发布的内容被聚合为 Feed 流并且按照内容的发布时间从近到远展示你所关注的那些人最近发布的内容。按照内容的发布时间排序也就是遊循时间线所以这种 Feed 流是一种 Timeline Feed 流。徽信朋友閣和微博首页都是典型的对关注 Feed 流的应用。附近 Feed 流顾名思义就是你附近的用户最近发布的内容这对于社交类应用来说较为常见。推荐 Feed 流的重点是推荐算法附近 Feed 流的重点是地理位置判断其相关技术差异巨大不具备通用性 2、功能
Timeline Feed 流提供的数据应该是我们所关注的人在指定的时问段内发布的内容列表并且内容按照时间由近及远排序。
用户在客户端浏览Timeline Feed页面时一般有如下两种操作方式。
下拉操作刷新Feed流拉取当前时间最新的 N条 Feed 流。上滑操作拉取更早时间的 N条Feed 流。 总之Timeline Feed 服务主要负资两种读取数据的方式下拉与上滑。
其中下拉负责拉取用户从未看过的最新内容列表上滑负资拉取更早的内容列表并限制所能拉取到内容最大数量。无论是何种读取方式内容列表均找照内容的发布时间从近到远排序。 二、设计原理
1、拉模式与用户发件箱
较为符合我们直觉的实现Timeline Feed服务的方式是拉模式。每个内容发布者都有自己的“发件箱”每当用户发布一个内容时就把内容存放到发件箱中由其他用户来拉取内容 在拉模式下用户每刷新一次Feed流系统就需要读取N个用户的发件箱这里的N指用户关注的人数这意味着一次用户请求会放大产生N倍的读请求故而这种模式也被称为“读扩散”。如果用户量级较大那么获取Feed流会是一个高并发场景而且用户关注的人数也会较多。所以这种扩散读会增加用户请求延迟并可能击垮存储用户内容列表的服务器 2、推模式与用户收件箱
与拉模式相反在推模式下每个用户都有一个“收件箱”当某个用户成功发布了内容时系统会将该内容推送到其每个粉丝用户的收件箱中。粉丝用户在获取Feed流时直接从收件箱中读取内容即可。在推模式下用户获取Feed流的性能比在拉模式下好。 缺点
存储压力大每个用户都有收件箱势必增加收件箱存储开销用户越多收收件箱占用的存储资源也越多写扩散某用户存在100w粉丝当发布完内容后需要推送到100w粉丝的收件箱即会产生100w个写请求。巨量写请求会击垮收件箱所依赖的数据库 3、推拉模式结合
推模式和拉模式优缺点互补可以相互结合。大V的内容就拉模式推模式要推的人太多普通内容推模式拉模式牵涉的人数太多 用户-区分活跃用户
大V在发布内容后我们依然可以采用推模式但是现在仅将内容推送给粉丝列表中的部分活跃用户因为这些用户使用 Timeline Feed 流功能的频常相对较高所以将内容主动推送到他们的收件箱中更有可能提高获取Timeline Feed流的性能。至于那些很长时间都没有打开应用的用户则完全没有必要把内容存储到他们的收件箱中。如果有一天这些用户登录应用并使用Timeline Feed流功能那么保持采用推拉结合模式结合来获取数据就好。
综上所述对推拉模式的结合方式总结如下
如果内容的发布者是普通用户则完全可以采用推模式把内容推送到全部粉丝的收件箱中如果内容的发布者是大V则进一步区分活跃用户和非活跃用户。对于活跃用户采用推模式对于非活跃用户则采用拉模式 三、关键技术
1、内容与用户收件箱的交互推模式
内容发布服务需要与Timeline Feed服务解耦而且要尽可能提高推送的可用性最好的办法就是在这两个服务之间建立消息队列通道。我们可以创建一个消费者服务负责接收内容发布服务的内容变更事件如果发现有新内容发布则执行遍历推送操作 2、推送拆分子任务
Timeline消费者遍历推送毕竟是串行操作如果需要将一条内容推送给更多的粉丝那么遍历推送可能会消耗更长的时间进而造成内容发布服务与Timeline消费者之间的消息队列中的消息积压导致内容到用户收件箱的投递延迟。我们可以将对大量粉丝的遍历推送拆分为多个并行执行的子任务每个子任务负责对一批粉丝的推送。
比如需要将内容A推送给3000个粉丝且粉丝的用户ID是1~3000那么可以将这个任务拆分为3个子任务
子任务1负责将内容发送给粉丝1~1000子任务2负责将内容发送给粉丝1001~2000子任务3负责将内容发送给粉丝2001~3000 3、收件箱模型设计
用户查询时的业务动作含义是以某个时间点为基准向前或者向后获取当前用户关联的内容id
1使用数据库
新增表inbox
字段名类型含义idbigint主键user_idbigint用户idcontent_idbigint内容idpublish_timedatetime内容发布时间
idx_feed(user_id,publish_time,content_id)
每个用户的收件箱内容都会按照publish_time从小到大排列当publish_time相同时再进一步按照content_id从小到大排列所以从后向前扫描索引正好与Timeline Feed流内容的排序规则相吻合
2使用ZSET
key为inbox_{用户ID}表示一个ZSET对象是哪个用户的收件箱Member为内容idScore为内容发布时间。ZSET可以按照内容发布时间从小到大排列内容ID
不断获取内容ID的方案
根据last_content_id 直接定位下一条内容但这种方案不适合推拉结合模式先获取发布时间小于或等于ts的全部内容再过滤筛选对第二种方案的优化把内容ID格式化为 20 位长度的字符串用作Member 字段保证在ZSET中发布时间相同的内容按照内容ID的数值从小到大排列这样一来在ZSET中从后向前扫描就与Timeline Feed流内容的排序规则相吻合了。
