《微博feed系统的push和pull模式和时间分区拉模式架构探讨》由会员分享，可在线阅读，更多相关《微博feed系统的push和pull模式和时间分区拉模式架构探讨（7页珍藏版）》请在金锄头文库上搜索。
1、微博 feed 系统的 push 和 pull 模式和时 间分区拉模式架构探讨摘要: sns系统，微博系统都应用到了 feed （每条微博或者sns里的新鲜事等我 们称作feed）系统，不管是或者国内的新浪微博，人人网等，在 各种技术社区，技术大会上都在分享自己的feed架构，也就是推拉模式（timyang 上次也分享了新浪微薄的模.全球唯一显示温度纯钢钛戒指吕60度超炫液晶，老外狂订sns系统，微博系统都应用到了 feed （每条微博或者sns里的新鲜事等我们称作 feed）系统，不管是或者国内的新浪微博，人人网等，在各种技术 社区，技术大会上都在分享自己的feed架构，也就是推拉模式（ti
2、myang上次 也分享了新浪微薄的模式）。下面我们就微博的feed推拉（push,pull）模式做一 下探讨，并提出新的时间分区拉模式。众所周知，在微博中，当你发表一篇微博，那么所有关注你的followers （粉丝） 都会在一定的时间内收到你的微薄，这有点像群发一封邮件，所有的抄送者都会 在一定的时间内收到。到这里，你可能觉得没有什么难度。我们看下下面的截图：测试版 劭新浪微博 鶯工丿J珈w 545 关注 2594751 掛丝 2085姚晨新浪认证涪員.（潜伏田窣萍怖涪者图一：新浪微博姚晨FenngFollowing 通，Lists-Also followed by freevpnin；D,
3、 isllei, (houzhyu, and 1C- othersName FenngLocation3O.209214J20L19&216 Web http:/ Bio做技术的，浣起来r也弩 =Ad Work at DXY.cn as CTO ( aka.打杂的， Evangelist Database Geek Web 2.0 Web Arch Unix OpenSource Al ip ay OW) JobsDigg Twitter.2,52519,869856oilowing followers listed图二：twitter上冯大辉新浪微博的姚晨粉丝有 2594751，她发表任何一
4、篇微博，都需要2594751个粉丝 在一定的时间内收到，twitter的冯大辉发表一篇的话，需要19868个followers 收到。相反，姚晨需要收到他关注的 545 个人的所有更新，冯大辉需要收到他关注的 2525 个人的所有更新。到这里，你是不是感觉到有那么一点点小挑战呢？面我们看下微博一般的整体结构图：图三：微博整体结构图中展示了微博的整体数据流程，先了解下整体的数据结构，没有涉及到followers等的推拉模式处理。下面我们再看下推模式（push）：液苜发表臥列feed 5 ( shandEng ),类G玉件的出图四：推模式结构 推模式需要把一篇微博推送给所有关注他的人（推给所有的粉
5、丝），比如姚晨， 我们就需要推送给2594751个用户的feeds表中。当然，feeds表可以很好的进 行sharding，存储也都是一些数字型的字段，存储空间可能不是很大，用户在查 询自己关注的所有人的feed时，速度快，性能非常高，但是推送量会非常大， 姚晨发表一篇，就会产生 200 多万条数据。试想，一个大量用户的微薄系统通过 使用推模式，是不是会产生非常惊人的数据呢？F面看下拉模式（pull）减寻id傩一识 丽实低内容图五：拉模式 拉模式只需要用户发表微博时，存储一条微博数据到feeds表中（feeds表可以 是一个临时表，只保存近期可接受范围的数据）用户每次查询feed时都会去查 询
6、feeds表。比如姚晨打开自己的微薄首页，就产生：SELECT id FROM feeds where uid in（following uid list） ORDER BY id DESC LIMIT n（查询最新的 n 条）， 缓存到 memcached uidlis t二da ta:id lis t,t imeline:上次查询出来的最新的一条数据的时间再次刷新： SELECT id FROM feeds where uid in（following uid list） AND timeline（memcached 存储的上次的 timeline） ORDER BY id DESC LI
7、MIT n这种模式实现起来也是比较简单和容易的，只是在查询的时候需要多考虑下缓存 的结构。但是 feeds 表会产生很大的压力，怎么说 feeds 表也要保存最近十天半 个月的数据吧，对于一个大点的系统，这会产生比较大的数据，如果following 的人数比较多，数据库的压力就会非常大。而且一般在线的用户，客户端都会定 期扫描，又会增加很大的压力，这在查询性能上没有推模式的效率高。面我们在对拉模式做一下改进优化SELECT id -ROM feedswhere uid in fol loving uid list AND timeline （last query time）/fe?ds/ 币册
8、护歸（蘇的 | querytime硝走要査询的 表）feeds遢近时闫的微專日uthor uidtimeline废表时间feeds （近期的）微專日uthor uidtimeline饯表时间feeds （比较长时期）SSd微4専author uidtimeline血表时间图五：拉模式（pull）-改进（时间分区拉模式）meme achedkey（uid list）valueddatazlast query data tirneline:last query time）拉模式的改进主要是在 feeds 的存储上，使用按照时间进行分区存储。分为最近 时间段（比如最近一个小时），近期的，比较长时期等
9、等。我们再来看下查询的 流程，比如姚晨登陆微博首页，假设缓存中没有任何数据，那么我们可以查询比 较长时期的 feeds 表，然后进入缓存。下一次查询，通过查询缓存中的数据的 timeline，如果timeline还在最近一个小时内，那么只需要查询最近一个小时 的数据的 feed 表，最近一个小时的 feeds 表比图四的 feeds 表可要小很多，查 询起来速度肯定快几个数量级了。改进模式的重点在于 feeds 的时间分区存储，根据上次查询的 timeline 来决定 查询应该落在那个表。一般情况下，经常在线的用户，频繁使用的客户端扫描操 作，经常登录的用户，都会落在最近的 feeds 表区间
10、，查询都是比较高效的。只 有那些十天，半个月才登录一次的用户需要去查询比较长时间的 feeds 大表，一 旦查询过了，就又会落在最近时间区域，所以效率也是非常高的。关于时间的分区，需要根据数据量，用户访问特点进行一个合理的切分。如果数 据发表量非常大，可以进行更多的分区。上面介绍的推模式和拉模式都有各自的特点，个人觉得时间分区拉模式弥补了图 四的拉模式的很大的不足，是一个成本比较低廉的解决方案。当然，时间分区拉 模式也可以结合推模式，根据某些特点来增加系统的性能。后记：本文的目的是介绍时间分区拉模式，本人对新浪微博和 twitter 等的推拉 模式的细节并不清楚。文章作者：孙立 链接：http:/
