大型微博应用Feed系统浅析 - Presentation Transcript
大型微博应用feed系统浅析bob/板子
什么是微博
大型?小型?
小型微博实现方案
推、拉
发表队列
分页
单条feed
新浪、腾讯猜想
微博 在切客
什么是微博
为了不让你感到受侮辱,不做解释了
小型、大型
大型、小型没有严格界限
我的应用算大型吗?
一两台机器,join搞不定的就算大型吧
有的应用今天是小型,明天是大型
有的应用注定就是小型
永远只根据自己的需要设计,过度设计会把自己陷入尴尬境地
不要见到大型就拍砖!要淡定!!
小型微博实现方式
Feed 表,User表,Relation表
1.Select * from feed,relation where feed.uid = relation.target_id and relation.uid = xxx
2. select target_id from relation where uid = xxx 查出 relation list,然后去feed表,通过 in (relation_list)取出结果
3. 还不够快?建立feed_index表,只存放feed_id,uid, 查出ID,去feed表找其他内容
4.还不够快?恭喜你,你的应用成“大型”了
推
用户1 发表记录一条
找出能看到用户1的所有用户(用户1的粉丝)
在 u_feed表(不一定是mysql哦)对于每个粉丝写入一条记录(u_feed根据uid分库表,uid为粉丝的id,单条记录表示某feed对于某uid可见)
添加/删除关注时,需要处理feed id
拉
用户1发表记录
u_feed表写入一条记录(uid为发表人id)
小型微博的实现方案即为拉,只是具体的实现需要更为巧妙
一次拉取请求,基本可拆分为:
取 attention uid list
每个uid取最新发表的page_size条feed id,然后合并排序
拉
以上方案听起来不可思议?
你知道有人关注了2000人,怎么拉?
在微博的世界,一个用户最多可关注2000用户
但是每个用户平均关注远小于2000
但是,通过一些巧妙设计,并非这样的关注2000人的用户每次拉取,都需要查询2000次
但是,即便真的需要查询2000次,也不是世界末日
但是。。
但是。。还是别用mongo db 吧
推、拉?
推:
优:
读压力小
缺:
明星用户发表feed 写压力巨大
实现逻辑复杂,如新关注一个人,新取消一个关注,都需要复杂逻辑支持
拉:
优:
发表面前,人人平等,写压力几乎没有
逻辑比较简单
缺:
读压力大,实时拉取feedlist,并发高时,似乎missiong impossible
那,到底是推还是拉?
新浪微博暂时应以推为主
腾讯微博应是拉的方式
切客目前也完成了从推到拉的转型
微博的特点是读固然多,写也不少
推、拉并不完全互斥,也可以通过一些巧妙的逻辑实现推、拉并用
没有完美的方案,只选合适你用的方案
发表队列
发表一条feed,通常需要复杂的逻辑支持,你确定当你系统有些延迟的时候,潘石屹愿意等待150秒,等待这条微博发布成功?
不确定的话,就加个队列吧
App只负责处理最简单的逻辑,重逻辑丢到处理队列异步处理
推荐:redis
分页
我们可以:
SELECT * FROM XXX WHERE …
LIMIT start,page_size;
需要数据:当前页,每页显示条目
优点:够传统
灵活(除了逐页翻动以外,还可以跳到任意页)
缺点:page较大时,查询吃力
页面数据变动快时(比如关注较多,或是在春晚时刻),翻页会有重复(下翻)或漏失(上翻)数据
分页
我们也可以:
SELECT * FROM XXX WHERE …
AND create_time < .. And feed_id < ..
LIMIT 0,page_size;
需要数据:
最后一条(第一条)feed id,create_time,每页显示条目
优点:上一页两个缺点的很好补充
缺点:只能上翻 或是下翻
分页
微博的特点:
大多数需求是只看最新,会往下翻几页,但不会太多,一般不需要直接去看第128页
在热点事件发生时,或是关注人较多时,也许你看完第一页,想看下一页,这一页的所有数据已经成了下一页
我们不关心第几页,只想看本条信息前的50条信息
所以我们选择第二种方式!
分页
不要臆想用户需求?
你确实需要有时候从第一页直接跳到第十页?
OK,我们新的方法,其实也可以提供这样的“时光穿越”,欢迎交流
单条feed
根据feed_id拆分库表
比如每个表限定存放数据1000万条,初期建库10个,每个库有表10个,10亿数据后再建100个表,具体拆分规则可根据自己的实际情况掌握
新的数据丢入内存
比如memcache?然后的工作就是努力提高缓存命中率吧
选择适当的粒度
不要所有数据都存入一条缓存
新浪、腾讯猜想
腾讯:
根据url的情况,以及可以拉出任意古老的下一页的情况来看,应是“拉”来实现的
新浪、腾讯猜想
新浪:
根据timyang的分享,以及一共只
提供10页数据查看的状况猜测,目前
新浪仍是以“推”为主
微博 在 切客(www.qieke.com)
Mongo db 还是建议不要大规模使用
Redis相对有些复杂,目前在切客用来支持队列
自主开发了一套基于b+ tree 的indexdb索引系统
目前feed系统采用全拉的方案实现
微博 在 切客(www.qieke.com)
我们正在变大
我们经历了 推 ->推拉结合 ->拉 的转变
我们还会改变
我们业务比微博更为复杂,还需要解决:
以地点为纬度,查看地点下的所有feed
查询附近的feed
查询附近的地点
。。。。
期待热爱挑战的您的加入 xiamingran@snda.com
bob/板子/56378301
谢谢!
2011/4/10
分享到:
相关推荐
综上所述,微博和知乎的feed流实现涉及到了多方面的技术,包括但不限于观察者模式、消息队列、分布式计算、数据库优化和算法应用。这些技术的综合运用保证了在大规模用户下的高效信息推送和个性化体验。
【Feed系统结构浅析】 Feed系统是社交网络服务(SNS)的核心组成部分,它负责将用户产生的内容(如状态更新、日志、照片等)高效地分发给相关的用户群体,确保用户能在第一时间获取到朋友们的最新动态。在这个过程...
在当今的社交网络中,微博作为一种信息传播迅速、交互性强的平台,它对feed系统的依赖程度极高。feed系统不仅仅是承载用户动态信息流的渠道,更是连接人与人之间信息共享的关键纽带。在大规模社交网络中,如何高效地...
【微博Feed系统的推(push)模式和拉(pull)模式及时间分区拉模式架构探讨】 微博Feed系统是社交媒体平台的核心组成部分,它负责展示用户关注的人或事物的最新动态。推模式和拉模式是两种常见的实现方式,各有优缺点,...
CSDN TUP Feed系统结构浅析 CSDN TUP Feed系统结构浅析 人人网
总结来说,新浪微博的架构设计经历了从快速原型到应对大规模用户的过程,涉及了推送模式优化、数据库拆分和索引策略的调整,以及系统的模块化和异步化处理。这些经验对于理解大规模社交网络的架构设计具有重要的参考...
在设计和优化feed流系统时,通常有两种主要的实现方式:拉模式(Read Diffusion)和推模式(Write Diffusion)。 **一、拉模式(读扩散)** 在拉模式中,数据的读取是扩散的。每个用户的feed队列只存储他们自己...
新浪微博开放平台中的Redis实践_大数据时代feed架构_微博消息系统架构演进_互联网公司技术架构资料.新浪微博.微博架构与平台安全_构建高性能的微博系统——再谈新浪微博架构 演讲视频,PPT,一些收集的博客地址等
【亿级访问量下的新浪微博系统架构】 新浪微博作为一个拥有亿级活跃用户的社交平台,其背后的技术架构需要具备高可用性、高并发处理能力和低延迟特性,以应对庞大的用户基数和业务需求。从最初的LAMP架构(Linux + ...
微博架构 feed 介绍,精彩不要错过~~
5. **Feed多级双机房缓存系统**: - 为了提高用户体验,微博平台采用多级缓存策略,如本地缓存、内存缓存和分布式缓存。 - 双机房部署可以提高服务的可用性和容灾能力,当一个机房出现问题时,另一个机房仍能提供...
【标题】:“android应用源码(精)新浪微博客户端源码” 涉及的知识点主要集中在Android应用开发和微博客户端的实现上。Android是Google公司推出的一种基于Linux内核的开源移动操作系统,广泛用于智能手机和平板电脑...
而分布式追踪系统Watchman和Feed多级双机房缓存系统的应用,则充分体现了微博在应对分布式系统复杂性和性能优化方面所做出的努力。通过这些技术和架构的优化,微博能够为亿级用户提供一个稳定、高效的服务平台,保证...
此外,微博架构中还包括了API服务层,通过这种方式,微博可以为其他应用程序或服务提供接口支持,促进了生态系统的开放性。 随着技术的不断进步,微博架构也在不断地进行优化和升级。微博在不同阶段的架构特点和...
胡忠想拥有丰富的分布式服务高可用性保障的线上实践经验,他主导或参与了微博计数器架构升级、春晚和奥运等大型活动的服务保障工作,以及首页信息流架构升级等项目。他当前的工作重点是微博跨平台业务服务化,包括...
开放平台是指允许第三方开发者创建应用程序并与该平台的数据和服务集成的系统。 ##### 6.2 Facebook开放平台 - 面向应用:应用程序可以在平台上拥有自己的地位和权限。 - 接口功能包括但不限于获取用户个人信息、...