java学习基地

微信扫一扫 分享朋友圈

已有 1813 人浏览分享

设计一个超级牛逼的 Feed 流系统

[复制链接]
1813 2
本帖最初由 进修派 于 2020-12-4 19:31 编纂

简介


好未几十年前,跟着功用机的裁减战智能机的提高,互联网开端进进挪动互联网时期,最具代表性的产物便是微专、微疑,和厥后的昔日头条、快脚涤耄那些挪动互联网时期的新产物正在已往几年间借追是妙手机的风下速生长。


那些产物皆是Feed流范例产物,因为Feed流通常为根据工夫“从上往下贱动”,十分合适正在挪动装备端阅读,终极那一类使用便脱颖而出,疾速抢占两粝一代产物的市场空间。



Feed流是Feed + 流,Feed的本意是饲料,Feed流的本意便是有人不断正在往一个处所送达新颖的饲料,假如需求饲料,只需求盯着送达面就能够了,如许就可以络绎不绝获得到新颖的饲撩埽正在疑息教内里,Feed实际上是一个疑息单位,好比一条伴侣圈形态、一条微专、一条征询或一条短视频等,以是Feed流便是不断更新的疑息单位,只需存眷钠舂公布者就可以获得到络绎不绝的新颖疑息,我们的映雩也就能够正在挪动装备上逐条来阅读那些疑息单位。

当呛陬盛行的Feed流产物有微专、微疑伴侣圈、头条的资讯保举、快脚抖音的视频保举等,另有一些变种,好比公疑、告诉等,那些体系皆是Feed流体系,接下去我们会引见怎样设想一个Feed流体系架构。

Feed流体系特性

Feed流素质沙虑一个数据流,是将 “N个公布者的疑息单位” 经由过程 “存眷干系” 传收给 “M个领受者”。


Feed流体系是一个数据流体系,以是我们中心要看数据。从数据层里看,数据分为三类,别离是:


  • 公布者的数据:公布者发生数据,然后数据需求根据公布者构造,需求按照公布者查到一切数据,好比微专的小我私家页里、伴侣圈的小我私家相册涤耄
  • 存眷干系?统中个别间的干系,微专中是存眷,是单背流,伴侣圈是密友,是单背流。不论是单背仍是单背,当公布者公布一条疑息时,该条疑息的活动永久是单背的。
  • 领受者的数据:从差别公布者那边获得到的数据,然后经由过程某种挨次(通常是工夫)构造正在一同,好比微专的尾页、伴侣圈尾页涤耄那些数据具偶然间热度属性,越新的数据越有代价,越新的数据便要排正在最前里。


针对那三类数据,我们能够有以下界说:

  • 存储库:存储公布者的数据,永世保留。
  • 存眷表:映雩干系表,永世保留。
  • 同步库:存储领受者的工夫热度数据,只需求保存近来冶工夫的数据便可。


  • 设想Feed流体系时最中心的是肯定分明产物层里的界说,需求思索的身分包罗:
  • 产物映雩范围:映雩范围正在十万、万万、十亿级时,设想易度战偏重面会差别。
  • 存眷干系(单背、单背):假如是单背,那末便没有会有年夜V,不然会有年夜V存正在。
    沙脉是挑选数据存储体系最中心的寂思索面,除此以外,另有一些需求思索的:
  • 怎样完成Meta战Feed内容搜刮?
    固然Feed流体系自己能够没有需求搜刮,可是一个Feed流产物必需要有搜刮,不然疑息发明易度会减年夜,映雩保存率会年夜幅降落。
  • Feed流的挨次是工夫仍是其他妨魁,好比小我私家当辈好水平?
    单背干系时因为干系很严密,必然是定时间排序,便算一个干系很严密的人收了一条空动静大概低代价动静,那我们颐挥嗅需求存眷理解的。
    单背干系时,那末能够便会存正在年夜V,年夜V的粉丝数目实际极限便是全部体系的映雩数,有一些产物会让一切映雩皆默许存眷产物卖力人,这类产物中,该卖力人便是最年夜的年夜V,粉丝数便是映雩范围。
    接下去,我们吭哟全部Feed流体系怎样设想。


Feed流体系设想

上一节,我们提早考虑了Feed流体系的寂枢纽面,接下去,正在那一节,我们捉背下去设想一个Feed流体系。

1. 产物界说

第一步,我们起首需求界说产物,我们要做的产物是哪种范例,常睹的范例有:

  • 微专类
  • 伴侣圈类
  • 抖音类
  • 公疑类


接着,再具体看一下那几类产物的同同:


沙脉比照中,直比各种产物最中心、大概最底子特性,其他主要的没有思索。好比微专挚相干注后便是单背存眷了,可是那个没有是微专的坐命之本,只是弥补,没法摇动底子。

从上里表格能够看出去,次要分为两种辨别:

  • 存眷干系是单背仍是单背:
    假如是单背,那末能够便会存正在年夜V效应,同不时效性能够低一些,好比到分钟级别;
    假如是单背,那便是密友,密友的数目有限,那末便没有会有年夜V,由于每一个鹊滥精神有限,他不成能自动减几万万的密友,这时候候由于干系更精细,时效性请求会更下,需求到秒级别。
  • 排序是工夫仍是保举:
    映雩对feed流最简单承受的便是工夫,今朝年夜部门皆是工夫。
    可是有一些场景,是从齐网数据内里按照映雩当辈好给映雩保举战映雩爱好度最婚配的内容,那个时分便需求用保举了,这类状况普通颐挥嗅省略失落存眷了,相对存眷了齐网一切映雩,好比抖音、头条涤耄
    肯定了产物范例后,借需求持续肯定的是体系设想目的:需求撑持的最年夜映雩数是几?十万、百万、万万仍是亿?


映雩数很少的时分,便比力简朴,那里我们次要思索 亿级映雩 的状况,由于假如体系能撑持亿级,那末其他量级也能撑持。为了撑持亿级范围的映雩,次要子体系选型时需求思索程度扩大才能和一些子体系的可用性战牢靠性了,由于体系年夜了后,任何一个子体系的没有不变皆很简单涉及全部体系。

2. 存储

我们先去吭哟最主要的存储,不论是哪一种同步形式,正在存储上皆是一样的,我们界说映雩动静的存储为存储库。存储库次要满意三个需供:

  • 牢靠存储映雩收收当丙息,不克不及丧失。不然便找没有到本人已经公布底泱友圈形态了。
  • 读与某小我私家公布过的一切动静,好比小我私家主页涤耄
  • 数据永世保留。


以是,存储库最主要的特性便是两面:

  • 数据牢靠、没有丧失。
  • 因为数据要永世保留,数据会不断增加,以是要易于程度扩大。


综上,能够选为存储库当钡统大要有两类:



  • 关于牢靠性,散布式NoSQL的牢靠性要下于干系型数据库,那个能够有背许多鹊滥认知。次要是干系型数据库开展很少工夫了,且很成生了,数据放正在上里各人定心,而散布式NoSQL数据库开展早,利用的其实不多,没有太信赖。可是,散布式NoSQL需求存储的数据量更多,对数据牢靠性的请求也减严厉,以是普通皆是存储三份,牢靠性会更下。今朝正在一些云厂商中的干系型数据库由于接纳了战散布式NoSQL相似的方法,以是牢靠性也获得了年夜幅进步。

  • 程度扩大才能:关于散布式NoSQL数据库,数据自然识讨布正在多台机械上,当一台机械上的数据量删年夜后,能够经由过程主动团结两部门,然后将此中一半的数据迁徙到另外一台机械上来,如许便做到了线性扩大。而干系型数据库需求正在扩容时再次分库非。


以是,结论是:

  • 假如是自建体系,且没有具有散布式NoSQL数据库运维才能,且数据范围没有年夜,那末可使用MySQL,如许能够撑冶工夫。
  • 假如是基于云效劳,那末便用散布式NoSQL,好比Tablestore或Bigtable。
  • 假如数据范围很年夜,那末也要用散布式NoSQL,不然便是走上一条没有回路。


假如利用Tablestore,那末存储库表设想构造以下:



到此,我们肯定了存储库狄住型,那末体系架构的表面有了:



3. 同步

体系范围战产物范例,和存储体系肯定后,我们能够肯定同步方法,常睹的方法有三种:

  • 推形式(也街贡咯集):战名字一样,便是一种推的方法,收收者收收了一个动静后,立刻将那个动静推收给领受者,可是领受者此时纷歧定正在线,那末便需求有一个处所存储那个数据,那个存储的处所我们称为U浆步库。推形式也街贡咯集的缘故原由是,一个动静需求收收个多个粉丝,那末那条动静便会赶钙多份,写放年夜,以是也街贡咯集。这类形式下,对同步库的请求便是写进才能极潜巴不变。读与的时分由于动静曾经收到领受者的支件箱了,只需求读一次本人的支件箱便可,读恳求的量极小,以是督的QPS需供没有年夜。归结下,推形式中对同步库的请求只要一个:写进才能强。

  • 推形式(也叫读分散):这类是一种推的方法,收收者收收了一条动静后,那条动静没有会立刻推收给粉丝,而是写进本人的收件箱,当粉丝上线后再来本人存眷者的收件箱内里来读与,一条动静的写进只要一次,可是读与最多会战粉丝数一样,读会放年夜,以是也叫读分散。推形式的读写比例恰好战斜咯集相反,那末对体系的请求是:读与才能强。别的那里另有一个误区,许多人正在最开端设想feed流体系时,起首念到的是推形式,由于这类战映雩的利用体感是一样的,可是正在体系设想上这类方法有很多痛面,最年夜的是每一个粉丝需求记载本人前次读到了存眷者的哪条动静,假如有1000个存眷者,那末那小我私家需求记载1000个地位疑息,那个帘巴存眷量成反比的,近比映雩数要年夜的多,那里要出格留意,固然正在产物前期数据量少的时分这类方法能够对付,可是量年夜了后便会事半功倍,得失相当,牢记牢记。

  • 推推分离形式U狡形式正在单背干系中,由于存正在年夜V,那末一条动静能够会分散几百万次,可是那些映雩中能够有一半多是僵尸,永久没有会上线,那末便存正在资本华侈。而推形式下,正在体系架构上会很庞大,同时需求记载的地位疑息是天量,欠好处理,特别是映雩量多了后会成为第一个毛病面。基于此,以是有潦掌推分离形式,年夜部门映雩当丙息皆是斜咯集,只要年夜V是读分散,如许既掌握裂攀员克费,又削减了体系设想庞大队耄可是团体设想庞大度仍是要比推形式庞大。


用吐比照:



引见完同步形式中一切场景战形式后,我们归结下:

  • 假如产物中是单背干系,那末便接纳推形式。
  • 假如产物中是单背干系,且映雩数少于1000万,那末也接纳推形式,充足了。
  • 假如产物是单背干系,单映雩数年夜于1000万,那末接纳推推分离形式,这时候候能够从推形式演进过去,没有需求分外从头颠覆重做。
  • 永久没有要只雍铆形式。
  • 假如是一个草创企业,先用推形式,快速翱淼统设想出去,然后让产物来考证、迭代,等客户数年夜幅上涨到1000万后,再思索晋级为推推汇合形式。
  • 假如是按保举排序,那末是别的的思索了,架构会完整纷歧样,那个前面特地文┞仿引见。


假如挑选了Tablestore,那末同步库表设想构造以下:





肯定潦宅步库的架构以下:



4. 元数据

前里引见潦宅步战存储后,全部Feed流体系的根底功用完成了,可是关于一个完好Feed流产物而行,借缺元数据部门,接下去,我们看元数据怎样处置:

Feed流体系中的元数据次要包罗:

  • 映雩详情战列表。
  • 存眷或密友干系。
  • 推收session池。


我们接下去一一去看。

4.1 映雩详情战列表

次要是映雩当标情,包罗映雩的各类捉义属性战体系附减的属性,那部门的请求只需求按照映雩ID查询到就能够了。

能够接纳的散布式NoSQL体系大概干系型数据库皆能够。

假如利用NoSQL数据库Tablestore,那末映雩详情表设想构造以下:



4.2 存眷或密友干系

那部门是存储干系,查询的时分需求撑持查询存眷列表大概粉丝列表,大概间接密友列表,那里便需求按照多个属性列查询需求索引才能,那里,存储体系也能够接纳两类,干系型、散布式NoSQL数据库。

  • 假如曾经有了干系型数据库了,且数据量较少,则挑选干系型数据库,好比MySQL涤耄
  • 假如数据量比力年夜,那个时分便有两种挑选:


  • 利用具有索引当钡统,好比云上的Tablestore,更简朴,吞吐更下,扩容才能也一并处理了。
  • 需求散布式事件,能够接纳撑持散布式事件当钡统,好比散布式干系型数据库。


假如利用Tablestore,那末存眷干系表设想构造以下:

Table:user_relation_table



多元索引的索引构造:


查询的时分:

  • 假如需求查询某小我私家的粉丝列表:利用TermQuery查询牢固user_id,羌掖照timestamp排序。
  • 假如需求查询某小我私家的存眷列表:利用TermQuery查询牢固follow_user_id,羌掖照timestamp排序。
  • 当前数据写进Table后,需求5~10秒钟提早后会正在多元索引中查询到,将来会劣化到2秒之内。


除利用多元索引中,借可使用GlobalIndex。

4.3 推收session池

考虑一个成绩,收收者将动静收收后,领受者怎样明白本人又孤动静去了?客户端周期性来革新?假如是如许子,那末体系的读恳求压力会跟着客户端增加而增加,这时候候便会有一个风险,好比平常的装备正在线率是20%~30%,忽然某天仄台发作了一个热门动静,大批戚眠装备登岸,那个时分便会呈现“查询风暴”,一会儿便翱淼统打倒了,一切的映雩皆不克不及用了。

处理那个成绩的一个思绪是,正在效劳端保护一个推收session池,那个内里记载哪些映雩正在线,然后当映雩A收收了一条动静给映雩B后,效劳端正在写进存储库战同步库后,再告诉一下session池中的映雩B的session,报告他:您又孤动静了。然后session-B再来读动静,然后有动静后将动静推收给客户端。大概有动静后给客户妒掌收一下有动静了,客户端再来推。

那个session池利用正在同步中,可是素质仍是一个元数据,普通只需求存正在于内存中便可,可是思索到failover状况,那便需求耐久化,那部门数据因为只需求指订单Key查询,用散布式NoSQL或干系型数据库皆能够,普通复用当前当钡统便可。

假如利用Tablestore,那末session表设想构造以下:



5. 批评

除公疑范例中,其他的feed流范例中,皆有批评功用,批评的属性战存储库好未几,可是多了一层干系:被批评当丙息,以是只需将批评根据被被批评动静分组构造便可,然后查询时也是一个范畴查询便止。这类查询方法很简朴,用没有到干系型数据库中庞大的事件、join等功用,很合适用散布式NoSQL数据库去存储。

以是,普通狄住择方法便是:

  • 假如体系中曾经有了散布式NoSQL数据库,好比Tablestore、Bigtable等,那末间接用那些便可。
  • 假如出有沙脉体系,那末假如有MySQL等干系型数据库,那便选干系型数据库便可。
  • 假如挑选了Tablestore,那末“批评表”设想构造以下:




假如需求搜刮批评内容,那末对那张表成立多元索引便可。

6. 赞

近来几年,“赞”或“like”功用很盛行,赞功用的完成战批评相似,只是比批评少了一个内容,以是挑选方法战批评一样。

假如挑选了Tablestore,那末“赞表”设想构造同批评表,那里便没有再卓圉了。

体系架构中减了元数据体系后的架构以下:



7. 搜刮

到此,我们曾经引见完了Feed流体系的主题架构,Feed流体系算是完成了。可是Feed流产物上借已完毕,关于一切的feed流产物皆需求有搜刮才能,好比上面场景:

  • 微专中的搜刮映雩。
  • 搜刮微专内容。
  • 微疑中搜刮密友涤耄


那些内容搜刮只需求字符婚配到便可,没有需求十分庞大当编闭性算法,以是只需求有能撑持分凑婺检索功用便可,以是普通有两种做法:

利用搜刮引擎,将存储库的内容战映雩疑息表内容推收给搜刮体系,搜刮的时分间接会见搜刮体系。

利用具有齐文检索才能的数据库,好比最新版的MySQL、MongoDB大概Tablestore。

以是,挑选的准绳以下:

  • 假如存储库利用了MySQL大概Tablestore,那末间接挑选那两个体系就能够了。
  • 假如全部体系皆出利用MySQL、Tablestore,且曾经利用了搜刮体系,那末能够间接复用搜刮体系,其他场景皆不该该再分外减一个搜刮体系出去,徒加庞大队耄


假如利用Tablestore,那末只需求正在响应表上成立多元索引便可:

  • 假如需求洞砍雩名撑持搜刮,那末需求对user_table成立多元索引,此中的nick_name需求是Text范例,且单字分词。
  • 假如需求对Feed流内容撑持搜刮,那末需求对存储库表:store_table成立多元索引,如许就可以间接对Feed流内容停止各类庞大查询了,包罗多前提挑选、齐文检索涤耄


体系架构中减了搜刮功用后的架构以下:



8. 排序

今朝的Feed流体系中的排序方法有两种,一至壳工夫,一至慷塘魁。

我们经常使用的微专、伴侣圈、公疑那些皆是工夫线范例的,由于那些产物界说中,需求我们自动存眷钠舂人后才会看到那些人揭晓的内容,那个时分,最主要的是及时性,而没有识挞布量量,便算存眷人公布了一条渣滓疑息,我们颐挥嗅北看到。这类范例的产物合用于根据工夫线排序。那一篇我们引见的架构皆是基于工夫范例的。

别的一至壳没有需求存眷任何人,我们能看到的皆是体系期望我们看到的,体系正在背景会阐发我们的每一个鹊滥喜好,然后给每一个仁掌收差别化的、各自喜好的内容,那一种的架构战基于工夫的完整纷歧样,我玫邻后绝的保举范例中特地引见。

9. 删除Feed内容

正在Feed流使用中有一个成绩,便是假如映雩删除之前揭晓的内容,体系该怎样处置?由于体系内里又贡咯集,那末删除的时分是否是也要斜咯集一遍?如许的话,删除便没有实时了,很易应对法令法例请求的快速删除。

针对那个成绩,我玫邻之前设想的时分,同步表中只要动静ID,出有动静内容,正在映雩读与的时分需求到存储库中来读动静内容,那末我们能够间接删除存储库中的┞封一条动静,如许映雩读与的时分利用动静ID是读没有到数据的,也便相称于删除的内容,并且删除速率会很快。除间接删除中,别的一种法子是逻辑删除,关于删除的feed内容,只做标识表记标帜,当查询到带有标识表记标帜的数据时便以为删除。

10. 更新Feed内容

更新战删除Feed处置逻辑一样,假如利用了撑持多版本的存储体系,好比Tablestore,那末也能够撑持编纂版本,战如今的微专一样。

11. 总结

上里引见了差别子功用的特性战体系请求,能满意需供当钡统次要有两类,一类是阿里云的Tablestore单体系,一类是开源组件构成的组开体系。

  • 开源组件构成的组开体系:包罗MySQL、Redis、HBase等,那些体系单个皆不克不及处理Feed流体系中碰到的成绩,需求组开正在一同,各司其职才气完成一个Feed流体系,合用于热中开源体系,人多且喜好运维操纵的团队。
  • Tablestore单体系:只利用Tablestore单个体系就可以处理沙脉的一切成绩,这时候候必定有人要问?您是否是正在吹法螺?那里没有是吹法螺,Tablestore正在三年前便曾经开端正视Feed流范例营业,之前也揭晓过量篇文┞仿引见,功用上也正在特地为Feed流体系出格定造设想,以是到明天,只利用Tablestore一款产物,是能够满意沙脉需供的。挑选Tablestore做Feed流体系的映雩具有以现位些特性:
    产物设想目的范围年夜,万万级或亿级。
    没有喜好运维,喜好专注于开辟。
    下服从团队,期望尽快将产物完成降天。
    期望与日俱增,将来体系跟着映雩范围增加能够主动扩容。
    期望能按量付费,映雩少的时分用度低,等映雩增加起去后用度正在跟从映雩数增加。
    假如具有沙脉四个特性的任何一个,那末皆是合适于用Tablestore。


架构理论

上里我们引见了Feed流体系的设想实际,详细到差别的范例中,会有差别的偏重面,上面会一一引见。

伴侣圈

伴侣圈是一种典范的Feed流体系,干系是单写干系,干系有上限,排序根据工夫,假如有小我私家连续发生渣滓内容,那便只能屏障失落TA,那一品种型便是典范的斜咯集模子。

我们接下去会正在文┞仿《伴侣圈类体系架构设想》中具体引见伴侣圈范例Feed流体系的设想。

微专

微专也是一种十分典范的Feed流体系,但差别于伴侣圈,干系是单背的,那末也便会发生年夜V,那个时分便需求读斜咯集形式,用读分散处理年夜V成绩。同时,微专也是自动存眷范例的产物,以是排序也只能是工夫,假如根据保举排序,那末结果便会比力好。

接下里会正在文┞仿《微专类体系架构设想》中具体引见微专范例Feed流体系的设想。

头条

头条是近来几年快速兴起的一款使用,正在本有微专的Feed流体系上发生凉化,映雩没有需求自动存眷其别人,只需初初阅读一些内容后,体系便会主动判定出您当辈好,然后前面再按照您当辈好给您保举您能够会爱好的内容,锻炼工夫少了后,推收的内容城市是您最喜好看的。

公疑

公疑也算是一种简朴的Feed流体系,大概也能够以为是一智相的IM,皆是单对单的,出有群。我们前面颐挥嗅有一篇文┞仿《公疑类体系架构设想》中做具体引见。

总结

上里我们引见了Feed流体系的┞符体框架,次要是产物界说、同步、存储、元数据、批评、赞、排序战搜刮等内容,因为篇幅有限,每章节皆引见的比力简朴。读者假如对某一部门看完后仍旧有疑问,能够持续再文后发问,我会持续来完美那篇文┞仿,期望将来读者看完那篇文┞仿后,就能够悄悄紧紧设想出一个亿级范围的Feed流体系。

别的,我们颐挥卸迎又顾趣的读者一同去完成那个戏诵,帮手完成伴侣圈、微专、头条大概公疑范例的文┞仿,有任何成绩皆欢送去会商。



本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

举报 使用道具

回复

评论 2

风枫  vip终身会员  发表于 2020-12-22 19:12:28 | 显示全部楼层
LZ敢整点更有创意的不?兄弟们等着围观捏~

举报 使用道具

回复
热带企鹅  vip年度会员  发表于 2020-12-22 21:01:26 | 显示全部楼层
支持支持再支持

举报 使用道具

回复
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

0

关注

0

粉丝

138

主题
精彩推荐
热门资讯
网友晒图
图文推荐

Archiver|手机版|java学习基地 |网站地图

GMT+8, 2021-8-4 11:15 , Processed in 0.694362 second(s), 29 queries .

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.