微信朋友圈好友动态的实现

　　a、用户进入到动态页面（比如：朋友圈）；

　　b、获取好友列表；

　　c、把好友的动态按时间倒排并展示。

　　大家注意到没有，整个过程中，用户已经没有了那个mailbox，取而代之的是动态的去拉取好友的信息。相对于之前聊的主动推送而言，这个就是一个被动的拉取过程。

　　由于是这样的一个工作模式，所以他有他的优点：当我关注了多个大V的时候，这些大V发动态不再主动推送给我，所以就避免了上千万次的主动推送过程。转而是用户浏览的时候再去获取。这使得我们的系统不会因为大V发动态而变得忙碌。

　　不过，如果我们的登录用户很多 && 他们都关注了很多其他用户，我们的系统就会有很大压力了：因为，他们要动态获取被关注者的信息并且做聚合。那我们有哪些办法做优化么？来看老王的才艺展示：

　　a、限制关注的数量：大家可以看到，好多的动态系统一般都限制用户添加好友或者关注的数量。其中有一个原因就有可能是采用了这样拉取动态的手段。限制用户关注量以后，我们系统在合并的时候，就可以减少合并的数量，从而提升效率；

　　b、为每个用户建立动态的缓存：我们可以给每个用户建立一个动态的cache，如果关注他的人取拉取他的动态，就不用每次都从磁盘（或者数据库）拉取，而直接从缓存中获取。从而提升拉取的速度；

　　c、为聚合后的动态建立缓存：还是缓存方案，不过这次针对的不是产生动态的人，而是浏览动态的人。一旦拉取过一次以后，我们就将聚合过后的数据做一个缓存，下次再刷新的时候，就直接可以从缓存中获取（特别适合那种手不停的下拉刷新朋友圈的人——）

　　d、建立时间更新表：这个是个什么东东？如果我关注了500个人，如果平均每个人有10个动态，那一次给我5000个动态，对于我来讲，我会疯掉……所以，其实从产品上讲，没有必要将所有被关注者的动态都获取来展示，对吧。比如，我们可以获取最近有更新的20个或者50个被关注者，将他们的动态拉取做展示，对于绝大多数情况就非常适用。那种长期不更新的人，也没必要看，对吧—— 所以，我们可以为每个被关注者建立一个最后更新时间表，然后获取动态前，先看看哪些最近有更新，然后只拉取这些有更新的用户的动态做合并排序就可以了。

　　好了，动态用时方去拉，这种方法就差不多说到这儿。看懂了么？

　　在具体设计这个系统的时候，最好是根据产品业务形态、用户的数据规模等等综合来判断和考虑。两种方式各有优缺点，实现的成本也因规模不同。

　　a、如果规模小，用最简单的推就可以了；

　　b、如果规模中等，用简单优化过后的拉也可以了；

　　c、如果是规模比较大，可以适度考虑优化过后的推或者拉，甚至推拉结合。

　　没有一个完美的架构，只有更适合业务的方案。所以，一切都取决于你的选择——