1006大设计翻译版-以周末微博Feed系统与实现

DesignandimplementationofMicroblogFeedAuthor:ZhouMoWiththedevelopmentoftheInternetespeciallymobileInternet,somemicroblogging-typedapplications,forexample,SinaWeiboand ,are partofpeople’slives.Peoplegetawidevarietyofinformationfromtheseapplications,enrichingtheirlives.Intheseapplications,thecoresystemiscalledfeedsystem.Iparticipatedinthedevelopmentofthecompany'snewprojectandlearnedrelatedresearchbecauseofmyinternship.Inapaperentitled“FeedingFrenzy:SelectivelyMaterializingUsers’EventFeeds”publishedbyYahooscientists,authorshasdonealotofresearchonFeedsystem.Inthispaper,distributionofevents,withtechnology,sortingdisplay,storageandotheraspectswerediscussedandsomeconclusionshaveguidingsignificance.AndinpracticalapplicationssuchasSinaWeiboand ,Feedsystemdesignideaissimilartothepaper,buttherearemanydifferencesinthespecificimplementation,andthesedifferencesareassociatedwiththerealneeds.AfteracertainunderstandingoftheFeedSystem,accordingtotheneedsofourproject,Idesignedrequestinterfaces,datastructuresoftheFeedsystem,andachievedamicrobloggingFeedSystembyprogrammingaccordingtomydesign.TheFeedsystemIdesignedisaprototypesystem,whichcanmeetteral,relativelysimpleneeds.Ifwewanttoapplyittoactualprojects,someimprovementsneedtobedone.WhatIamcurrentlyngissomepreliminarywork,andonthenextjob,Iwillenhancetheusefulnessofthesystem.：Microblog,Feedsystem,push/pul................................................................................................................................................... 绪 项目来 项目需 研究目标与内 总体要 具体研究内 的组织结 相关技术分 理论研 实际应用分 Feed系统 人人网Feed系 各Feed系统的对比分 Feed系统的设计与实现 需求分 设 设计总 数据结构设 数据库设 常量约 数据请求接口设 实 与登 查看及全局.................................................................................................关注与取消关 发布与转发.................................................................................................查看详 评论....................................................................................................................查看消 退出登 测试验 发布、转发与查看......................................................................................评论...........................................................................................................................小 总 致 参考文 绪论2013年7月，我有幸申请到易玩（原麦圈）的实习如何建立联系勋章模私信模通如何建立联系勋章模私信模通知模物品模用户模麦圈换FeedFeed 图1.1于目前流行使用第登录如、等，所以我们并不是要做一个独立的用户系统，只是提取第的一些基本信息用作如利用第平台进行推广等，这是非常有用而且非常方便的。因而也不会有更改这样的隐私操作存在于我们平台之内，这些操作都是在第平台中可以完成的，我们对此是不关心的。另外，由于我们平台的机制，防止用户领取奖励，我们会对用户的登录设备进行记录，同一设备领取过之后便不能再领易的信息是非常重要的，用户（我们可以称之为买家）想换取你的闲置物知其它变化，如、产品升级等。私信模块：用于用户之间在应用内进行直接沟通。该功能模块类似于、等通讯工具，用户可以使用该功能与其它用户沟量交易事宜等，但是功在这种情况下，我们可以将双方在沟通时的查找出来，这样有助于得勋章模块：用于用户完成某些任务而获得的象征。该模块只是机制的些，除此之外并没有，但是在对外宣传方面可能会有一定的推广事件信息。在社交类，我们称之为Feed系统。feed的原意是饲料，饲养，广播等，在Feed系词来表示，以区别于其它类订阅应用术经验为主要目的。所以，实际上我做的工作是对Feed系统进行原型研究，对相Feed系统进行同一级别的比较，但是我可以从验证结果中说明，我设计的微博Feed系统是正确的、可用的。我会对我设计中的每一项功能进行详细说明。A与用BA在上10:00BfeedAA在上午10：00发布了一个新的闲置物品。这看似是一个非常简单的过程。当用户A产生新的事件时，只需要将这个事件向A用通俗的语言描述这一过程是非常容易的，描述上述问题实际上也只用了几。一个点。确定了策略之后，我们便需要考虑如何向用户展示这些事件。用户A10：00生B还关注了用户CC10:01时也产生了一个新A10:02B10:03feed时，他->->。但是考虑到事件和事件是同一用户A产生的，那么是否可以紧接着展示而排在的前面？或者由于用户B更喜欢关注A的事件，那么和是否也应该一起展示？这这个问题是需要仔细考虑的。数据就会使用到数据库，目前比较流行的数据库主要分为关系型数据库和非关系型数据库。关系型数据库技术比较成熟，处理数据的性能比变动，一致性要求是非常高的，是否会导致未知的损失，给用户和银行带来不可估计的SINTERuser1_friendsSINTERuser1_friendsSINTER表示求两个集合的交集，user1_friendsuser2_friends表示两个用户以上我要的内容都是比较独立的，但是在实际中，一个应用往往比较复杂，涉员进行修改与指正，但这些并不会影响我对这项技术的。1.4的组织结本文的主要目的是根据实际需求实现一个简单Feed原型系统。在对项目来源、任务及国内外相关研究的分析之后，使用比较成技术和设计思路来完成设计与实现，并对任务做一些总结。的介绍与分析。第三章主要是明确项目需求，然后根据项目需求，使用比较成设计思路来设计原型系统，最后使用编程段来实现。第四章主要是对已实现的相关技术分析、Feed系统现在用得非常之广，如国外的 人人网等，这些都是很著名类应用或。不管是应用还是，本质都是相同的，只是用于展示的形式不同而已。关于Feed系统的也是非常多，但是可能是因名公司Feed系统的设计详细，只有一些比较宽泛的设计思路。不过，或许这些设计思路已经足够了。在众多的资料中，我找到一篇雅虎科学家的名为《FeedingFrenzy:SelectivelyMaterializingUsers’EventFeeds》[1]。我认为该对Feed系统进行了、application等。在这类应用中，我们把产生事件的用户（或其它实体）称之为生产者，把100个用户的状态更新都会影响到该用户的feed所有消费者的feed列表中。当相关的消费者需要获取自己的feed时，便可以从自己的虑生产者生产新事件的频率和消费者获取feed的频率了。如果消费者获取feed的频率文中将生产者和消费者的关系定义为一个有向图G(V,F)，每个顶点是一个生产者或者消费者，如果消费者点关注了生产者（如接收了的事件），则有一条顶点到的边。社交网络是这类连接网络中的一个例子。如上相互关注文中把上述的关系网络看作关系图ConnectionNetwork(Producer,Consumer).。通常，连接网络都明确地以支持生产者、消费者或者两者都能有效查询的形式。例如，把生产者的事件其关注了的消费者推送，须在生产者网络中查找，然后取得关注了该事件的消费者的集合，即{: }。另一方面，消费者要拉取事件，我们必须在网络中查询，然后取得该消费者关注了的生产者集合，即{ 一个例子中，我们可以把关系定义为ConnectionNetwork(Consumer,Producer)来支持消费者聚合。如果我们要支持两种获取方式，须在ConnectionNetwork关系之外额外每个生产者产生我们可以为之建立关系模型 (EvntID，imtamp，Pyload)流当想一用的fd列表，须执行 的fd查询。对于fd查询有两种可能。第一种是消费者想查看他所有关注的生产者的最近k个事件我们称这种选择为全局聚合，并定义该查询为1：个最近事 个最近如果Timestamp( )<Timestamp( )，则发生在之前。产生了两个事件和feed当消费者查询获取一次feed时，更新频率较高的生产者的事件将占大部分，而更新频率这样的体验是非常不好的。文中将这个问题称之为多样性问题，定义为：feed中必须包Candidate(Pt)t单位时间的生产者P的事件数量，定Count(p)PCfeed中展示的数量。Feed系统此部分根据杨卫华的[2]整理而成是国内比较流行应用。发展到今天，总共对Feed系统进2.1所示，运行起来非常快，实现起来也非常快。因为Feed系统主要就是处理订阅和发布的问题，像上面提到的，有推和拉统把这条向该用户的所有关注者推送，没有其它额外的操作。这个版本使用了典型LAMPMPSS（Multi-PortSingleServer），优点是速度非常快，而且可以把多个端送量就比较大。如果我们专门对用户发布时的延迟进行处理的话，就可能影响的影响。问题的根源是在推模式上。要解决严重的延迟问题，肯定就要改进Feed处理模式。另外，考虑到用户之间数据规模有很大差距（如用户拥有数十万关注者而普图2.1第一版结图2.2第二版结2.2所库、统计索引、进入，如果把所有索引都做完再向用户返回结果，那么用户将会在是实际上可能已经入库成功了。使用异步模式后，如果用户成功了，则提示用户还了一个重要的产品叫做MemcacheQ。时，有时并不需要把这条推送给100个关注者，因为有可能其中80个关注都并不会马上浏览。如果使用同步模式把这条推送给这80个关注者，那么这部浪将用户数据按照时间进行拆分，把的内容和索引拆分（如的地址是索引，内容就是内容）。数据按时间拆分就是把每隔一定时间建立一张新的表来用户和数据，而把内容和索引拆分就变成了一种key-value模式，key-value数据是一种最容易扩展的数据，像redis这样的非关系型数据库便是一种图2.3第三版结 ID来拆分或许更从上述内容中可以看出，Feed系统的设计与Yahoo！中的理论设计计自己Feed系统。图2.4cache设此部分根据人人网张铁安的[3]人人网将feed称为新鲜事。其FeedNewsFeedIndexUserInteractionSortingalgorithm&FriendMiniFeedIndexFeedContentRenderingEngine(data+Dispatch就是新鲜事分发系统，里面就包含了推/拉模式的选择。在对推、拉模式进一些地方进行了权衡，减少不必要的开销。NewsFeed索户反馈、排序算法是跟新FeedContent就是新鲜事本身的内容，如用户表现了一个日志新鲜事，那么内容便是这个日志新鲜的几十个字的简短。NewsFeedIndexPersistence即新鲜事索引持久化。新鲜事对于索引数据是非常庞大的。当用户查询新鲜事的时候，会先去查询索引，然后根图2.5是对新鲜事处理的过程图。该图包含了主要的过程而并全部。用户了日不同的系统中：NewsFeedIndexCache、MiniFeedIndexCacheMemcachePorxy。MiniFeed是自己的新鲜事，相对而言数据量比较少。MemcachePorxy的工作是将新鲜2.5会有数十万的好友，这样的查询操作是非常耗时的。使用缓存后，第一次查询到数据库，人人网还使用Flyweight（享元模式）思想设FeedCache做了内存优化。人人在有些情况下，内存cache重启后无法快速恢复。为了解决这个问题，人人网设计了索引持久化系统。该系统将写操作合并，通过日志文件来恢复数据，使用异步I/0来读写文件，使用SSD解决大量的并发。可以看出，人人网的Feed系统在设计上也与Yahoo!的理论设计有差异，与新浪微博有的相似，但是不同之处也比较明显，比如在对用户新鲜事排序方面，人人网在这方面做了很多工作，以向用户提供智能化的体验。在下一小节中做一些比较。推/拉模式的选己的介绍[4]，其更喜欢拉模式。也是推拉共用[5]。在另外一篇关于设计自己的关feed的排案有的工作，至少在用户的主页上情况是这样的，在其它地方如热门倒是可以看到其它排序的结果。这也许是和对自己的定位有关。目前是一个社交媒体的定位，因此对于事件更看重，也就是对时间很敏感，所以主要以时间为排序依缓存设Yahoo中并没有提到关于缓存设计的信息，只是对如何优化查询过程有。 Feed系统的设计与实现结果，我将设计一些辅助功能。Feed系统是以用户为中心，所以功能需求都将从用户登录之后，能够查看自己关注的用户事件。该事件列表中应该包含自己用户可以查看整个系统中所有用户。此需求与查看用户关注人的事件相似，用户可以发布，产生事件。目前可以只支持纯文本。用户发布后，关注了该用户的其它用户则应该能看到这条。展示时应该包含但不限于发布的用户、内容、。考虑到用户发布使用的时间可能不，如没有查看详详情包括的展示和与之相关的评论。展示评论时应该以时间为排序依据，发时可以添加转发理由，同样的纯文本，在转发成功后，转发理由应该是转发后要说明的是，用户不能关注自己；自己可以评论自己，但是不应该收到通知。消上面的任何操作，必须通过登录或者过程。以上便是Feed原型的全部需求，这些需求与公司的应用中对应关系，如在对、人人网的Feed系统设计进行了考查之后，我决定使用推模式配合库。在考虑了易用性、稳定性，以及咨询了公司的技术之后，我决定使用redis数鉴于此，决定使用redis数据库还是明智的。JSON格式的数据本质上字符串，客户端使用专门的JSON对服务器返回的字符串 用户数的数量及消息等，具体细节如表3.1所示。3.1用户数据结构字段名含约备量求增加一个字段auth，该字段的值是一个32位由数字和英文字母组成的字符串。这个证这个值是否与用户的auth值相同。如果相同，则继续相关请求操作。如果不相同，则2)数考虑到需求fd中信息该包括、事件内容这些都是显式的，即用户可见的。但为了配合其它操作，应该增加字段以完善功能，具体如下表3.2所表3.2数据结字段名含约备1、2与相关的还有对的评论，由于在展示时并不要求连同评论一起展示，所以我将评论与拆分，单独。评论信息包括评论人、评论内容、评论时间，具体如下表3.3所示。3)消息数消息。消息应该包含消息时间、消息内容等，具体如下表3.4所示。3.3评论数据结构字段名含约备3.4消息数据结构字段名含约备设计原则为目标，以发挥redis数据库的优势。1)用户数据用户数据使用一张哈希（Hashs）表来，哈希表的名称（在redis称为键key）为uname:info，表中的键为用户名，值为用户信息，结构如表3.5所示。另外，由于用户的码auth会经常使用，所以单独。对每个用户都生成一个字表3.5用户数据键值（已转换为JSON格式{"uname":"passwd":"passwd",}{"uname":"passwd":"passwd",}2)数据用户接收到的普通列表；“uname:用户名:special_feeds”，表示用户接收到的特别表3.6数据键值（已转换成JSON格式[]{}"id":7,[]{}"id":7,评论数据 表3.7评论数据键值（已转换为JSON格式[{o}][{{}]消息数据我们为每个用户建立列表型键值对来用户的消息，其中键的格式为“uname: 表3.8消息数据键值（已转换成JSON格式[{"content":" oFeed"{"contentTom关注了你"}]关注者数据的的集合。样例如表3.9所示。表3.9关注者数据键值（已转换成JSON格式["Tom",["Tom",用于区分该结果是否客户端想要的结果。返回码常量约定如表3.10所示。3.10返回码常量约定常量名值含01234表3.11数据常量约常量名值含123用户登录（a{{":"}3.12通用错误数据字段字含说如果在系统中没有名为Tom的用户，则成功，返回类似如下的结果{{"user":{"feed_count":}表3.13成功返回数据字字含说码据{{}{{"user":{"feed_count":}各字段含义与时相同，只是增加了新字段new_notice，此字段也是通用字段，查/get_feed.php?auth=autuame/get_feed.php?auth={{{"id":7, o}}对应3.2.2中规定的字段。关注与取消关另外，可选参数为是否特别关注（special，值为true或false），请求格式如下：{{}关注的用户（unfollower），请求格式如下查看{{{}第二个请求是获取用户数据，请求格式如下查看全局发、、 标题（title）、内容（content），其中title为可选参数。请求格式如下：、、 户粉丝的feed中。查看详评论需求两个参数：作者（uname）和这条的相对编码（feed_id）。请求格式评 （a（_ 转该请求与用户自己发布相同，只是将参数type的值设为2（即查看消{{{"title":"系统消息","id":7}}消息数据中的各字段与3.2.2中的设计字段相对应。退出登{{}$redis=new//redis$redis->connect('',{$ret['code']=$ret['detail已存在的用户名';return$ret;}根据请求传入的参数uname和passwd，做相应操作。对$redis=new//redis$redis->connect('',{$ret['code']=$ret['detail已存在的用户名';return$ret;}functiongen_auth($len={$chars=其中gen_auth()函functiongen_auth($len={$chars=$auth$auth=for($i=0;$i<$len;$i{$auth.=$chars[mt_rand(0,strlen($chars)-}return}$info$info=unserialize($redis->hGet('uname:info',$uname));if($info==null){$ret['code']=return}if($info['passwd']!={$ret['code']=错误return}查看及全局$len1=$redis-由于来源可能是普通用户，也可能是被特别关注的用户，所以返回数$len1=$redis-$len2=$len2=$redis-$feed2=$redis->lRange("uname:$uname:feeds",0,$len2);foreach($feed1as&$f){$f=}foreach($feed2as{$f=}$feed=array_merge($feed1, ，只需返回“global:feeds”列表中的数据即可foreach($feedas&$f){$f=}//if//if($special=={}{}//将$follower$notice=$notice['ts']=$notice['id']=$info=$info=if($info=={{$ret['code']=}{if($looker!=null){//}}发布与转发$client=new$workload=$workload['uname']=$workload['feed']=$client->addServer('',$client=new$workload=$workload['uname']=$workload['feed']=$client->addServer('',foreach($followersas$f){}查看详ment",$ret['code']=//$ret['list']=$ret['length']=//if($_REQUEST['uname']!=ment",此过程是将评论添加到相//if($_REQUEST['uname']!=ment",$ret$ret=if($feedInfo=={$feedInfo=$feedInfo['comment']=}//$len$len=$redis-foreach($feedas&$f){$f=}$ret=$ret['list']=测试验证在完成对Feed系统的设计与实现之后，我们便要对这个系统的正确性进行验操作系统：CentOS6.364位（阿里云服务器(CPU：1客户端为为该系统所编写的，使用进试，配置详情如下操作系统：Android4.2.1CPU：44.14.1、登录与退出登{{"}图4.2未用户登录结 {{"user":{}图4.3正常结{{}4.4{"user":{我们再使用刚的Bil用{"user":{}我们再用Bil用户名进行操作，返回结果为{{":"}我们使passwd=pass，返回数据为{{}4.1为进行后面的测试，在系统中添加两个用户，用户名为Tom、Alice，使用passwd。图4.6错误结{"new_notice":0}{"new_notice":0}表4.1与登录汇参测试点期望结果实际结是否通过测试册册是是是户名再次是录是{{"feed_count":"followed":false}

4.7{{}我们再对Alice{{}}4.8{"user":{"feed_count":{"user":{"feed_count":}{{"title{{"title":"系统消息","id":3}}4.94.2发布、转发与查看{}{}4.2搜索、关注与取消关注参测试点期望结果实际结是否通过测试户在是是是是是无为0为0是 {{{"id":1, }}图4.10获取列{{}}{{{"id":2, {"id":1, }}图4.11转发后刷新列{{"id":1,我们再以Alice的登录系统，发布，内容为“oFeed”。此时我们再以{{"id":1,