关于APP的架构实现！微博和知乎中的 feed 流是如何实现的？
引自：https://www.zhihu.com/question/19645686/answer/85075806?from=profile_answer_cardphp
微博和知乎中的 feed 流是如何实现的？
在微博中每一个人关注的人会成百上千，在知乎上关注了人还关注话题关注特定主题，这些feed的输出，如何能有效下降系统查询负载，特别是知乎上feed流的结果还须要特定排序。不知道这些都是如何优化的，可否指点一二？
按投票排序按时间排序
6 个回答
简单来讲，Feeds这块主要包括两块内容，就是生成feeds和更新feeds。生成feeds是什么意思呢，好比咱们已经关注的人作了特定操做，咱们须要把这些活动加入你的feeds，让你接收到。更新feeds包括的内容比较多，一种就是你关注点作了更新，好比你新关注了一我的，须要把他的活动加入已有feeds，与此相似，取消关注也同样；另外一种就是你的关注点作了一些更新操做，好比你关注的一我的取消关注了一个问题。
咱们先来谈feeds生成，用户A作了某操做，好比关注了一个问题，这时候咱们首先找到用户A的全部关注者，而后给须要推送的关注者推送此操做，你们能够把每一个人的feeds简单想象为一个有序列表，推送很简单，就是在每一个人的列表末尾添加这个操做。怎么样，是否是很简单，:)
而后咱们谈feeds更新，第一种状况和第二种状况其实都是同样的，咱们须要针对这些活动更新来更新feeds，好比咱们新关注了一我的，这时候咱们须要取出此人的活动历史，而后按照时间顺序把这些历史塞到你的feeds中。此操做的复杂度会比较高，须要使用合适的数据结构来达到最佳性能，目前是O(log(N))。
固然，真实状况并无这么简单，还有不少其余逻辑和注意点，好比咱们的feeds须要对多人作一样的操做作合并（你们能够自行把以上的feeds有序列表变为有序集合），一样的内容的建立时间是要按最新操做的时间来计算的，一我的连续作不少操做须要对操做作合并等。全部你们看到的feeds相应的存储考虑到性能都会使用内存，除此以外全部的操做都须要作持久化存储，不然咱们也就无法更新feeds了:)
下面咱们谈谈这里面的技术挑战和相关技术，此部分与知乎目前的技术决策和使用技术无关，我给你们分享几个国外团队的工程决策和他们的优化手段。
先来谈谈strava，他们使用了Kafka分布式发布订阅消息系统，这个系统用来事件(event)发布，还使用了Storm分布式实时计算平台，这个计算集群会订阅Kafka的事件，而后完成相应的处理，在这块他们作了一个优化，就是一个事件不会推给全部关注者，只会推给活跃的用户（如何断定一个用户为活跃的，这就看实际状况和数据本身优化了）。
而后再来谈谈Instagram，他们产品的读写比例达到了100：1，事实上大部分互联网产品都是这样，因此这也是推技术更合适的缘由，推一次开销可能大一点，不过推（也就是写）发生次数大大少于读，由于有些大牛关注者很是多，达到几百上千万，为了进行可靠地推，这个过程都会异步后台执行。一样，咱们须要一个任务调度器和消息队列，任务调度他们选用了Celery，下面须要选择一个消息队列，Redis依赖订阅者轮询，不自带复制备份，并且强依赖内存是个硬伤，不合适；Beanstalk其余方面不错，可仍是不支持复制(Replication)，弃掉；最后他们选用了RabbitMQ，快，高效，支持复制，并且和Celery高度兼容。
接着谈谈Pinterest，重心在于建立一个智能化的feed，也就是feed会包括一些热点和推荐，并且会根据特定算法来排序。当事件发生后，会通过一系列流程最后才进入用户的内容feed，首先通过智能feed worker来处理，这些worker会接收事件并且根据特定用户给事件打分，而后这些事件会被插入到一个排好序的feed池中，不一样类型的事件会被插入各自的池中，目前他们使用HBase的基于key的排序实现了此优先队列，接着智能feed内容生成器接手了，它会从几个池中根据策略取出feeds甚至剔除一些feeds，最后面向用户的智能feed服务会整合旧的feed和新生成的feed，展示给用户看到的Home Feeds。
最后简单谈谈Facebook，用户量大了以后对工程团队要求会更高，每一个facebook用户都会有一个属于本身的独一无二的动态生成的首页。不少团队都会用用户ID为Key来把feeds存入Key-Value存储系统，好比Redis，问题是经过网络链接作远程过程调用很是慢，没法知足实时性的要求，因此facebook团队也开始使用了嵌入式数据库，他们也开源了本身在用的 RocksDB。
这些内容都在他们的技术博客里面有提到，连接在这里：
Strava Engineering
How Instagram Feeds Work: Celery and RabbitMQ
Making Pinterest
https://www.facebook.com/notes/10151822347683920/
就像电影特效是为剧情服务同样，技术是为产品服务的。针对不一样的业务场景，适合的技术也是不同的。随着产品的调整和业务规模的扩大，相应的技术都会作进化和调整。针对不一样的难题，须要提出不一样的技术方案，feeds的生成也是这样，若是有必要，咱们也会对这些方案作调整，目的都是同样，那就是又对又快又稳定。
若是有什么错误，但愿大神指出。若是有更好的方案或者建议，欢迎交流。
咱们先来谈feeds生成，用户A作了某操做，好比关注了一个问题，这时候咱们首先找到用户A的全部关注者，而后给须要推送的关注者推送此操做，你们能够把每一个人的feeds简单想象为一个有序列表，推送很简单，就是在每一个人的列表末尾添加这个操做。怎么样，是否是很简单，:)
而后咱们谈feeds更新，第一种状况和第二种状况其实都是同样的，咱们须要针对这些活动更新来更新feeds，好比咱们新关注了一我的，这时候咱们须要取出此人的活动历史，而后按照时间顺序把这些历史塞到你的feeds中。此操做的复杂度会比较高，须要使用合适的数据结构来达到最佳性能，目前是O(log(N))。
固然，真实状况并无这么简单，还有不少其余逻辑和注意点，好比咱们的feeds须要对多人作一样的操做作合并（你们能够自行把以上的feeds有序列表变为有序集合），一样的内容的建立时间是要按最新操做的时间来计算的，一我的连续作不少操做须要对操做作合并等。全部你们看到的feeds相应的存储考虑到性能都会使用内存，除此以外全部的操做都须要作持久化存储，不然咱们也就无法更新feeds了:)
下面咱们谈谈这里面的技术挑战和相关技术，此部分与知乎目前的技术决策和使用技术无关，我给你们分享几个国外团队的工程决策和他们的优化手段。
先来谈谈strava，他们使用了Kafka分布式发布订阅消息系统，这个系统用来事件(event)发布，还使用了Storm分布式实时计算平台，这个计算集群会订阅Kafka的事件，而后完成相应的处理，在这块他们作了一个优化，就是一个事件不会推给全部关注者，只会推给活跃的用户（如何断定一个用户为活跃的，这就看实际状况和数据本身优化了）。
而后再来谈谈Instagram，他们产品的读写比例达到了100：1，事实上大部分互联网产品都是这样，因此这也是推技术更合适的缘由，推一次开销可能大一点，不过推（也就是写）发生次数大大少于读，由于有些大牛关注者很是多，达到几百上千万，为了进行可靠地推，这个过程都会异步后台执行。一样，咱们须要一个任务调度器和消息队列，任务调度他们选用了Celery，下面须要选择一个消息队列，Redis依赖订阅者轮询，不自带复制备份，并且强依赖内存是个硬伤，不合适；Beanstalk其余方面不错，可仍是不支持复制(Replication)，弃掉；最后他们选用了RabbitMQ，快，高效，支持复制，并且和Celery高度兼容。
接着谈谈Pinterest，重心在于建立一个智能化的feed，也就是feed会包括一些热点和推荐，并且会根据特定算法来排序。当事件发生后，会通过一系列流程最后才进入用户的内容feed，首先通过智能feed worker来处理，这些worker会接收事件并且根据特定用户给事件打分，而后这些事件会被插入到一个排好序的feed池中，不一样类型的事件会被插入各自的池中，目前他们使用HBase的基于key的排序实现了此优先队列，接着智能feed内容生成器接手了，它会从几个池中根据策略取出feeds甚至剔除一些feeds，最后面向用户的智能feed服务会整合旧的feed和新生成的feed，展示给用户看到的Home Feeds。
最后简单谈谈Facebook，用户量大了以后对工程团队要求会更高，每一个facebook用户都会有一个属于本身的独一无二的动态生成的首页。不少团队都会用用户ID为Key来把feeds存入Key-Value存储系统，好比Redis，问题是经过网络链接作远程过程调用很是慢，没法知足实时性的要求，因此facebook团队也开始使用了嵌入式数据库，他们也开源了本身在用的 RocksDB。
这些内容都在他们的技术博客里面有提到，连接在这里：
Strava Engineering
How Instagram Feeds Work: Celery and RabbitMQ
Making Pinterest
https://www.facebook.com/notes/10151822347683920/
就像电影特效是为剧情服务同样，技术是为产品服务的。针对不一样的业务场景，适合的技术也是不同的。随着产品的调整和业务规模的扩大，相应的技术都会作进化和调整。针对不一样的难题，须要提出不一样的技术方案，feeds的生成也是这样，若是有必要，咱们也会对这些方案作调整，目的都是同样，那就是又对又快又稳定。
若是有什么错误，但愿大神指出。若是有更好的方案或者建议，欢迎交流。
恰好最近想写一个Feed机制的文章，就来回答一下吧。
楼上各位其实把大致的状况都已经说的很明白了，我来分享一下咱们目前线上一个feed实现机制，已经在生产环境运行了大半年。理论来讲，百万级别用户没有什么问题。
为了节省你们流量，全程无图（实际上是我懒得画 - - ），但愿你们能把省下的流量钱来给我发红包，鼓掌 。
首先，抛去数据库这一块，数据库我想你们确定知道怎么设计，可是查询确定是个麻烦事， 因此我使用了redis进行一个冗余设计，开始介绍以前，须要了解什么是推拉模式，楼上说的两篇文章 新浪微博架构和FEED架构分析--人人架构_paper0023_新浪博客 ，还有推拉模式以及时间分区拉模式的分析 微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨 其实已经足够了解了，请各位看官若是未对推拉模式了解，那么请先看文章，再来看个人回答，个人回答只是阐述具体实现，谢谢。
那么我如今说一下redis这块怎么来完成推拉模式，以及内存尽量节省，速度尽量提升吧（固然，只是我理解的节省内存跟速度提升，若是看官们有其余的意见，我就两点要求，1、轻喷，2、说完再喷）。
一、实现
首先，先解决发布跟接收的问题，目前有大致如下几种方式：
一、推模式
什么是推模式？推模式就是，用户A关注了用户B，用户B每发送一个动态，后台遍历用户B的粉丝，往他们粉丝的feed里面推送一条动态。
二、拉模式
与推模式相反，拉模式则是，用户每次刷新feed第一页，都去遍历关注的人，把最新的动态拉取回来。
可是，无论推模式仍是拉模式都存在若关注数量或者粉丝数量过多，致使遍历时间太长的问题，怎么去解决 ？这里就出现了第三种模式，推拉模式。
三、推拉模式
这是一种折中的解决方案，就是在线推，离线拉。粉丝几百上千万， 跟你发布动态同时在线的确定也就只有那么顶天几百几千几万，况且这类大V不多，只推给在线的粉丝，离线的粉丝上线后，再去拉取动态便可！可是，无论是什么模式，每一个用户都会维护一个相似发件箱跟收件箱的东西，保存本身发过的动态以及Feed动态（具体实现看下面），来完成推与拉。
而这里讲的，确定就是推拉模式，用户A关注了用户B ， 用户B发布动态则将动态推动用户A的feed，这里使用redis的zset实现，sort为time（记得以毫秒为时间戳，秒级在数据量达到必定程度后，会有读取不到的问题，好比以时间戳为分页页码），value为具体的动态 ID（为何是动态ID， 其实很简单， 就是由于动态的内容能够进行缓存，在redis里面所有走ID，修改动态内容也须要修改一处，动态内容能够保存在hash结构里）， 每一个用户维护一个zset保存我发布的动态，一个zset保存个人feed动态，过时时间3~7天看状况而定。为何要设计过时时间后面会细说。
OK，全局维护一个在线用户列表，怎么设计这个就本身琢磨了，为了防止用户挂后台致使与服务端为离线状态，因此最好是1~3小时未操做或者离线时间不大于3小时的，都当作在线处理，反正这个看状况定。
那么，当用户发了一条动态后，后台会有如下这些操做：
在线推： 异步遍历在线的粉丝，将动态ID，添加到粉丝的Feed中。
离线拉： 离线用户打开APP后，咱们是会请求一个公共的入口接口，主作统计以及其余初始化操做，在这里，咱们也开了一个异步线程，对用户进行Feed更新操做，防止用户进入APP后等待拉取时间过长，毕竟关注成千上万的人确定有（其实万单位如下遍历都很快）。拉取过程其实就是把本身最后一条Feed的时间戳取出，去遍历关注的人的feed，将大于该时间的ID所有拉取回来。用户进入APP后，刷新便可看到最新操做。
另：若是有Feed新消息数提示的需求，能够在推拉的同时进行增长， 刷新feed时清空便可。
其实到这里，发布接收的问题已经解决了，那么有一个问题，用户feed里面过长，占用内存怎么办？
我是这么处理的，一个用户的feed第一次拉取的时候，feed长度为500条，在咱们APP里，至关于50页，然后的数据，都走数据库。大页码翻页其实就是个伪需求并且耗性能的东西，用户除了第一次用这个APP，才会翻到底，第一次使用， 能有几个动态 ？而对于二次使用以上的用户，通常来说， 翻了几页就已经到达上一次看过的地方了，因此500条数据，在关注量通常的状况下，内容已经足够消费，甚至达到疲劳，可能有关注量很大的用户他的Feed天天可能有不少不少动态，可是，不用说，确定是作广告的，关注一堆人等着回粉，这种人更不会去消费内容，50页的内容，翻起来都累。固然，并非说放弃了这些人，feed找不到走数据库嘛~~~~爱走不走，想走就给我翻50页再说~
还有一个问题，每一个用户都维护本身的动态跟Feed队列，当用户上百万时，内存的占有量确定不小，要怎么释放内存才合适 ？
这里就回到上面那个问题了，为何要给feed的key设计过时时间？为何是设计3~7天过时时间？
缘由有如下：
1、一个用户3~7天不打开APP，可能已经对APP失去兴趣了，打开概率很小，或者已经被卸载了，没有存在的意义了。
2、3~7天未登录APP，关注的人发的动态也很多了，Feed未拉取回来的数据确定也很多，那么这时候去遍历其实拉取量很大，那么还不如直接所有从新拉一边或者拉取用户最后登录时间后产出的数据。
到这里，其实已经差很少了，大部分业务逻辑已经足够知足，而且速度也理想，目前咱们线上这种模式走了半年，feed通常都是10~80ms响应完毕。
好了，大概就是这样了。
最后说一句：
<?php
echo 'php 是世界上最好的语言！！！';
?>
楼上各位其实把大致的状况都已经说的很明白了，我来分享一下咱们目前线上一个feed实现机制，已经在生产环境运行了大半年。理论来讲，百万级别用户没有什么问题。
为了节省你们流量，全程无图（实际上是我懒得画 - - ），但愿你们能把省下的流量钱来给我发红包，鼓掌 。
首先，抛去数据库这一块，数据库我想你们确定知道怎么设计，可是查询确定是个麻烦事， 因此我使用了redis进行一个冗余设计，开始介绍以前，须要了解什么是推拉模式，楼上说的两篇文章 新浪微博架构和FEED架构分析--人人架构_paper0023_新浪博客 ，还有推拉模式以及时间分区拉模式的分析 微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨 其实已经足够了解了，请各位看官若是未对推拉模式了解，那么请先看文章，再来看个人回答，个人回答只是阐述具体实现，谢谢。
那么我如今说一下redis这块怎么来完成推拉模式，以及内存尽量节省，速度尽量提升吧（固然，只是我理解的节省内存跟速度提升，若是看官们有其余的意见，我就两点要求，1、轻喷，2、说完再喷）。
一、实现
首先，先解决发布跟接收的问题，目前有大致如下几种方式：
一、推模式
什么是推模式？推模式就是，用户A关注了用户B，用户B每发送一个动态，后台遍历用户B的粉丝，往他们粉丝的feed里面推送一条动态。
二、拉模式
与推模式相反，拉模式则是，用户每次刷新feed第一页，都去遍历关注的人，把最新的动态拉取回来。
可是，无论推模式仍是拉模式都存在若关注数量或者粉丝数量过多，致使遍历时间太长的问题，怎么去解决 ？这里就出现了第三种模式，推拉模式。
三、推拉模式
这是一种折中的解决方案，就是在线推，离线拉。粉丝几百上千万， 跟你发布动态同时在线的确定也就只有那么顶天几百几千几万，况且这类大V不多，只推给在线的粉丝，离线的粉丝上线后，再去拉取动态便可！可是，无论是什么模式，每一个用户都会维护一个相似发件箱跟收件箱的东西，保存本身发过的动态以及Feed动态（具体实现看下面），来完成推与拉。
而这里讲的，确定就是推拉模式，用户A关注了用户B ， 用户B发布动态则将动态推动用户A的feed，这里使用redis的zset实现，sort为time（记得以毫秒为时间戳，秒级在数据量达到必定程度后，会有读取不到的问题，好比以时间戳为分页页码），value为具体的动态 ID（为何是动态ID， 其实很简单， 就是由于动态的内容能够进行缓存，在redis里面所有走ID，修改动态内容也须要修改一处，动态内容能够保存在hash结构里）， 每一个用户维护一个zset保存我发布的动态，一个zset保存个人feed动态，过时时间3~7天看状况而定。为何要设计过时时间后面会细说。
OK，全局维护一个在线用户列表，怎么设计这个就本身琢磨了，为了防止用户挂后台致使与服务端为离线状态，因此最好是1~3小时未操做或者离线时间不大于3小时的，都当作在线处理，反正这个看状况定。
那么，当用户发了一条动态后，后台会有如下这些操做：
在线推： 异步遍历在线的粉丝，将动态ID，添加到粉丝的Feed中。
离线拉： 离线用户打开APP后，咱们是会请求一个公共的入口接口，主作统计以及其余初始化操做，在这里，咱们也开了一个异步线程，对用户进行Feed更新操做，防止用户进入APP后等待拉取时间过长，毕竟关注成千上万的人确定有（其实万单位如下遍历都很快）。拉取过程其实就是把本身最后一条Feed的时间戳取出，去遍历关注的人的feed，将大于该时间的ID所有拉取回来。用户进入APP后，刷新便可看到最新操做。
另：若是有Feed新消息数提示的需求，能够在推拉的同时进行增长， 刷新feed时清空便可。
其实到这里，发布接收的问题已经解决了，那么有一个问题，用户feed里面过长，占用内存怎么办？
我是这么处理的，一个用户的feed第一次拉取的时候，feed长度为500条，在咱们APP里，至关于50页，然后的数据，都走数据库。大页码翻页其实就是个伪需求并且耗性能的东西，用户除了第一次用这个APP，才会翻到底，第一次使用， 能有几个动态 ？而对于二次使用以上的用户，通常来说， 翻了几页就已经到达上一次看过的地方了，因此500条数据，在关注量通常的状况下，内容已经足够消费，甚至达到疲劳，可能有关注量很大的用户他的Feed天天可能有不少不少动态，可是，不用说，确定是作广告的，关注一堆人等着回粉，这种人更不会去消费内容，50页的内容，翻起来都累。固然，并非说放弃了这些人，feed找不到走数据库嘛~~~~爱走不走，想走就给我翻50页再说~
还有一个问题，每一个用户都维护本身的动态跟Feed队列，当用户上百万时，内存的占有量确定不小，要怎么释放内存才合适 ？
这里就回到上面那个问题了，为何要给feed的key设计过时时间？为何是设计3~7天过时时间？
缘由有如下：
1、一个用户3~7天不打开APP，可能已经对APP失去兴趣了，打开概率很小，或者已经被卸载了，没有存在的意义了。
2、3~7天未登录APP，关注的人发的动态也很多了，Feed未拉取回来的数据确定也很多，那么这时候去遍历其实拉取量很大，那么还不如直接所有从新拉一边或者拉取用户最后登录时间后产出的数据。
到这里，其实已经差很少了，大部分业务逻辑已经足够知足，而且速度也理想，目前咱们线上这种模式走了半年，feed通常都是10~80ms响应完毕。
好了，大概就是这样了。
最后说一句：
<?php
echo 'php 是世界上最好的语言！！！';
?>
先不考虑数据的物理分布，仅讨论下业务的设计。
有三种基本思路：
思路1，产生的全部动态，都在同一条索引上，上面承载全部的更新，以及读取。每一个用户都有本身的filter规则，这个规则包括「屏蔽了谁，关注了谁，屏蔽了哪一个问题」。
用户在读取feeds，即是使用本身的filter，按照时间顺序，从头遍历这个索引，直到获得足够的条目。
优势：业务逻辑上是最清晰，性能稳定。
缺点：技术难度最大。
思路2，读扩散。
每一个人有本身产生的feeds队列，打开本身的首页时，按照本身的关注列表和屏蔽规则，去读取其余用户的feeds队列，而后汇总、排序。
优势：实现最简单，关注列表 敏感性最高。
缺点：性能最差，并且差的很稳定。
思路3，写扩散。
每一个人有本身的产生的feeds队列和 待读取的feeds队列。每一个用户产生动态时，压入到关注者的 待读取feeds队列，压入前，须要根据屏蔽规则来判断下是否要压入。
优势：每一个用户页面打开的速度是最快的，性能最高。
缺点：关注列表变化时，敏感度略低，但读取队列的时候，再根据规则过滤一遍，也没啥太大问题。
我的推荐：思路1 。
根据我的的简单猜想， 知乎的首页，貌似是 思路3+思路2 。
猜想的理由：
1-当我取关时，刷新，页面还会有这个用户的动态，因此 思路3的可能性很大。
2-当我新关注一我的，刷新，页面上会有这个用户的动态，可能针对最近产生的关注行为作了特殊处理，少许的作了读扩散。
3-B关注了A。若是A帐号产生一条动态，好比 赞同，而后再取消赞同。此时A帐号的 所有动态 中，是没有刚才的赞同记录的，可是在 B 的首页上，仍是会有 A 的赞同行为。
-----------------------
update at 2014-12-08
我今天偶然的发现，我关注的某些人的回答，是没有出如今个人首页的。
我反复对比过，估计 大概是4天前的四、5条动态，没有出如今个人首页。
根据这个现象，知乎的首页应该是 写扩散更多些。
并且，在写扩散的时候，貌似写失败了，就拉倒了。
有三种基本思路：
思路1，产生的全部动态，都在同一条索引上，上面承载全部的更新，以及读取。每一个用户都有本身的filter规则，这个规则包括「屏蔽了谁，关注了谁，屏蔽了哪一个问题」。
用户在读取feeds，即是使用本身的filter，按照时间顺序，从头遍历这个索引，直到获得足够的条目。
优势：业务逻辑上是最清晰，性能稳定。
缺点：技术难度最大。
思路2，读扩散。
每一个人有本身产生的feeds队列，打开本身的首页时，按照本身的关注列表和屏蔽规则，去读取其余用户的feeds队列，而后汇总、排序。
优势：实现最简单，关注列表 敏感性最高。
缺点：性能最差，并且差的很稳定。
思路3，写扩散。
每一个人有本身的产生的feeds队列和 待读取的feeds队列。每一个用户产生动态时，压入到关注者的 待读取feeds队列，压入前，须要根据屏蔽规则来判断下是否要压入。
优势：每一个用户页面打开的速度是最快的，性能最高。
缺点：关注列表变化时，敏感度略低，但读取队列的时候，再根据规则过滤一遍，也没啥太大问题。
我的推荐：思路1 。
根据我的的简单猜想， 知乎的首页，貌似是 思路3+思路2 。
猜想的理由：
1-当我取关时，刷新，页面还会有这个用户的动态，因此 思路3的可能性很大。
2-当我新关注一我的，刷新，页面上会有这个用户的动态，可能针对最近产生的关注行为作了特殊处理，少许的作了读扩散。
3-B关注了A。若是A帐号产生一条动态，好比 赞同，而后再取消赞同。此时A帐号的 所有动态 中，是没有刚才的赞同记录的，可是在 B 的首页上，仍是会有 A 的赞同行为。
-----------------------
update at 2014-12-08
我今天偶然的发现，我关注的某些人的回答，是没有出如今个人首页的。
我反复对比过，估计 大概是4天前的四、5条动态，没有出如今个人首页。
根据这个现象，知乎的首页应该是 写扩散更多些。
并且，在写扩散的时候，貌似写失败了，就拉倒了。
早在人人火了，UChome出来的时候你们就在研究各类feed流的实现，到微博这会儿应该已经没啥人在讨论了，各类推和拉模式，网上搜搜就知道了。
关于排序又是另外一个问题了，这个方面你们都在探索吧。
（我的观点不表明公司立场）
关于排序又是另外一个问题了，这个方面你们都在探索吧。
（我的观点不表明公司立场）
这里看到一篇新浪微博作的技术分享，值得一看。虽然没有太多的技术实现细节，不过大的框架已经说明的差很少了。仍是好几年前的分享，如今应该架构变化又大了不少，不过一个小网站参考的话，这些已经足够了。
新浪微博架构和FEED架构分析--人人架构_paper0023_新浪博客
另一篇，一名网友对推拉模式以及时间分区拉模式的分析 微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨
另一篇，一名网友对推拉模式以及时间分区拉模式的分析 微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨
相关文章
- 1. 经常使用Feed流架构实现
- 2. Python爬取微博和知乎热榜的简单实现
- 3. 如何实现微服务架构中的服务发现？
- 4. 如何实现微服务架构中的服务发现
- 5. 新浪微博RSS Feed实现中的问题
- 6. 探讨微博时间流的实现
- 7. 唯品会架构师是如何实现架构重构的
- 8. 惟品会架构师是如何实现架构重构的
- 9. 基于node.js的微博博客实现
- 10. 如何实现微服务架构
- 更多相关文章...
- • 现实生活中的 XML - XML 教程
- • 使用Redis和Lua的原子性实现抢红包功能 - 红包项目实战
- • ☆基于Java Instrument的Agent实现
- • Spring Cloud 微服务实战(三) - 服务注册与发现
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 外部其他进程嵌入到qt FindWindow获得窗口句柄 报错无法链接的外部符号 [email protected] 无法被([email protected]@[email protected]@@引用
- 2. UVa 11524 - InCircle
- 3. The Monocycle（bfs）
- 4. VEC-C滑窗
- 5. 堆排序的应用-TOPK问题
- 6. 实例演示ElasticSearch索引查询term,match,match_phase,query_string之间的区别
- 7. 数学基础知识 集合
- 8. amazeUI 复择框问题解决
- 9. 背包问题理解
- 10. 算数平均-几何平均不等式的证明,从麦克劳林到柯西
欢迎关注本站公众号,获取更多信息
相关文章
- 1. 经常使用Feed流架构实现
- 2. Python爬取微博和知乎热榜的简单实现
- 3. 如何实现微服务架构中的服务发现？
- 4. 如何实现微服务架构中的服务发现
- 5. 新浪微博RSS Feed实现中的问题
- 6. 探讨微博时间流的实现
- 7. 唯品会架构师是如何实现架构重构的
- 8. 惟品会架构师是如何实现架构重构的
- 9. 基于node.js的微博博客实现
- 10. 如何实现微服务架构