一种非Timeline的feeds流架构
摘要:
有如下一个场景: 用户关注的都是大V,用户看到的feeds流内容,会根据大V的发帖数目、帖子被转发数目、大V活跃指数等规则,进行打分计算排序后展示;且计算的内容有一个时间窗口(比如只计算最近72小时内的内容)。
这是一种非Timeline的feeds流展示,如果按传统的拉模式、推模式、推拉结合模式设计,计算排序会比较复杂。搜索架构可以满足计算rank的要求,但把内容限定在一个时间窗口内计算,实现比较困难。而实时计算正好可以满足非Timeline的计算需求,如图1所示:
图1:一种非Timeline的feeds流架构
关键词:
feeds流,非Timeline,实时计算,消息
正文:
一.非Timeline的feeds流的架构设计
图2所示的feeds流,跟传统的按时间排序的feeds流有所不同。
图2 非Timeline 的feeds展示样式
图2中,横向上,按一个大V最新发布的内容展示;纵向上,按关注大V的打分值进行排序。打分规则为72小时内,大V的发帖数、活跃度、帖子被转发数等因子进行计算,得分高的显示在前面,它不再是按照时间顺序显示的feeds流。
同时对大V的打分计算,有三点要求,1)计算的数据需要限定在一个窗口期内;2)每n分钟重新进行一次计算排名; 3)计算因子的权重、打分的规则会变化。
本质上讲,feeds流系统,就是一个计算过程,将发布的内容聚合计算后给关注的用户看,当然,feeds内容的时效性有一定的要求(不然,离线的大数据计算更合适了)。经过选型,实时计算正好能满足这些要求。
输入架构:大V产生的动作,如发帖、活跃、被转发等,会按统一的格式,通过异步消息,发送到实时计算平台(实时计算平台使用了阿里云的blink),成为计算分数的因子,如图3所示:
图3:数据输入到实时计算平台
输出架构:实时计算平台对这些因子进行计算后,将结果输出存储。结果数据可以用K-V结构表示,key=粉丝id,value是关注的大V列表(按分值排序),比较适合用redis的zset存储,如图4 所示:
图4:数据从实时计算平台输出
二.实时计算平台的打分计算流程
大V用户的数据,输入到实时计算平台后, 会根据大V的Id(用extraUserId表示), 统计不同计算因子(用actionType表示)的次数,然后乘上该因子的权重,计算出单个因子的分值;再将该大V所有计算因子的分数求和,得到该大V用户的总分值。其伪代码如图5所示:
图5:大V用户分值的计算过程
代码中包含了一个滑动窗口Hop,可以实现“每n时间间隔计算一次m时间段内”的数据,这正好满足了第一节中提出的计算要求。
每个大V的总分计算好后,再与关注大V的粉丝进行join,得到{fansId,extraUserId, totalScore},其伪代码如图6所示:
图6:每个粉丝关注的大V分值
然后将此结果输出到的redis中,redis使用zset存储。key =fansId, score = totalScore, member=extraUserId。最后,通过fansId,可以取出一份按分值排序的大V用户列表,实现图2中feeds的展示要求。
三. 架构的优化
在第二节中,计算完所有的大V得分后,如果每个用户能看到的大V都一样,业务就简化为排行榜,这个对实时计算来讲,在合适不过了。但因为每个用户关注的大V不同,最终的结果是关系数据与排行数据做join,业务变的更像是feeds流。
如果关系数据量不大,则join的过程放在实时计算里做,也没有问题。如果关系数据很大,一是join的计算时间增加,二是每次join后得到的结果数据,还需要输出到Redis中,输出的时间会变长,Redis集群写的压力也会增大。
最简单的优化就是调整计算的时间间隔,比如每5分钟计算一次,改为每10分钟计算一次。其次就是实时计算平台上,只计算大 V的排行数据,而将join+rank的过程外置,由其他外部系统来做(比如:搜索系统),其结构变为如图7所示:
图7 大规模用户下的架构优化
结语:
本文从具体的场景出发,描述了基于实时计算的非Timeline feeds架构设计。该业务场景有3个特点:1)非TimeLine模式,计算过程比较复杂;2)计算的数据需要限定在一个窗口时间内;3)对内容的时效性有一定的要求,需要每隔n分钟就更新一次。实时计算比较适合这个场景,但当计算的数据量比较大,特别是关注数据做join(用户量基数大),消耗的计算资源成本会很大。
闲鱼技术团队是一只短小精悍的工程技术团队。我们不仅关注于业务问题的有效解决,同时我们在推动打破技术栈分工限制(android/iOS/Html5/Server 编程模型和语言的统一)、计算机视觉技术在移动终端上的前沿实践工作。作为闲鱼技术团队的软件工程师,您有机会去展示您所有的才能和勇气,在整个产品的演进和用户问题解决中证明技术发展是改变生活方式的动力。
简历投递:guicai.gxy@alibaba-inc.com
识别二维码,关注【闲鱼技术】公众号
一种非Timeline的feeds流架构相关推荐
- 如何开发一个Feeds流系统——写扩散模式为例
一.了解Feeds流 在学习如何开发Feeds流应用前,我们需要先了解什么是Feeds流. 1. 什么是Feeds流 Feeds流是一个持续更新并展示给用户的信息流.它将用户主动订阅的若干消息源组合在 ...
- 视频监控系统中的流媒体服务器,视频监控系统中的流媒体服务器、直写和全切换三种取流架构方案...
原标题:视频监控系统中的流媒体服务器.直写和全切换三种取流架构方案 一.流媒体服务器架构 前摄像头视频信号通过转发流媒体服务器转发至上壁面显示和终端接入,视频存储磁阵列通过流媒体存储服务器写入.实时流 ...
- 数据人看Feed流-架构实践
背景 Feed流:可以理解为信息流,解决的是信息生产者与信息消费者之间的信息传递问题. 我们常见的Feed流场景有: 1 手淘,微淘提供给消费者的首页商品信息,用户关注店铺的新消息等 2 微信朋友圈, ...
- 浅析主流视频直播系统的推拉流架构、传输协议
随着移动网络网速的提升与资费的降低,视频直播作为一个新的娱乐方式已经被越来越多的用户逐渐接受.特别是最近这几年,视频直播已经不仅仅被运用在传统的秀场.游戏类板块,更是作为电商的一种新模式得到迅速成长. ...
- 视频直播技术干货:一文读懂主流视频直播系统的推拉流架构、传输协议等
1.引言 随着移动网络网速的提升与资费的降低,视频直播作为一个新的娱乐方式已经被越来越多的用户逐渐接受.特别是最近这几年,视频直播已经不仅仅被运用在传统的秀场.游戏类板块,更是作为电商的一种新模式得到 ...
- 视频直播技术分享:一文读懂主流视频直播系统的推拉流架构、传输协议等
本文由蘑菇街前端开发工程师"三体"分享,原题"蘑菇街云端直播探索--启航篇",有修订. 1.引言 随着移动网络网速的提升与资费的降低,视频直播作为一个新的娱乐方 ...
- NS-CIM:一种电流模式的内存计算架构,支持智能物联网视觉节点的近传感器处理
摘要: 近年来,神经网络(NNs)在创新应用方面呈现出巨大的潜力.然而,能源效率仍然是一个挑战,在边缘部署的神经网络.在这种情况下,内存计算(CIM)架构成为节能硬件设计领域的一个新兴趋势,因为它显著 ...
- 从项目到产品: 软件时代需要价值流架构师 | IDCF
译者:无敌哥 原文地址: https://thenewstack.io/the-age-of-software-needs-value-stream-architects/ 本文翻译仅供学习交流之用. ...
- 基于docker微服务架构_使用基于微服务的流架构更好地进行大规模的复杂事件处理(第1部分)...
基于docker微服务架构 基于微服务的流架构与开源规则引擎相结合,使实时业务规则变得容易 这篇文章旨在详细介绍我将OSS业务规则引擎与Kafka风格的现代流消息传递系统集成在一起的项目. 该项目的目 ...
最新文章
- BIO 三位标注 (B-begin,I-inside,O-outside)
- 自己面试大厂iOS开发的心得以及一些面试题
- 三十二、数据库设计的三范式【完】
- word 替换 增加引号_如何在Word 2013文档中替换部分(不是全部)智能引号
- csdn颜色字体的改变
- (链表 栈 队列 递归)
- 【EasyNetQ】- 使用Future Publish调度事件
- php魔术方法 效率,PHP常用魔术方法的性能探究
- Ivan and Burgers(CF-1100F)
- Android数据存储——内部存储
- 迁移solaris ufs根文件系统至zfs根文件系统
- 国务院《政务信息资源共享管理暂行办法》带来哪些新商机?
- linux安装gcc9.1
- AD7705在STM32F103RBT6上的移植[硬件SPI]
- python实现手写字识别_pytorch实现MNIST手写体识别
- 七大行星排列图片_八大行星排列顺序(八大行星排列顺序图)
- 苹果ID申请开发者 双重认证问题?
- 技术人该如何选择未来职业方向?一起听听这几位美团同学的故事
- 几何图形变化(Codevember)
- hdu 1757(矩阵快速幂)