follows大道至简，道道相同，其实世界本没有那么复杂，不过人们把它描写的多样化了，他就那么复杂了，抽象到一定程度发现互不相关的东西都有他的共性，无论在任何领域都少不了change，有change都有质变，质变点就有极值点，min，max，在数学中尤为常见。但有时需要结合最大和最小结合运用才能创造出合理，譬如在web2.0时代颇为流行的newsfeed。twitter，facebook，其实googlereader等都一样，一个生产者，一个消费者。设计往往经常是大家谈论的两种，一种是存储一份，消费者就登陆时候就pull过来，例如你登陆豆瓣，就会看到你好多好友的信息，都是pull过来的，如果你比较强大可以把生产者的内容给每一个消费者发一份。但是也会面临瞬间分发的压力，虽然在发的时候有一定的延时性。但用户读取的时候就很容易，读跟自己相关的就可以了。目前好多有这种应用的都是这种操作。以下是facebooke的。

facebook newsfeed

    在看看一篇有关校内的http://www.54chen.com/uncategorized/net-new-to-live-for-all-to-share.html

    用的是一些key value的数据库。也是push的思想，即给所有的相关的好友dispatch一份。 但是想twitter这样的有些突发事件或者名人

    follows过多的话会有多大的压力无论是写还是读。 后来躲到一篇follows的论文，好像一个普林斯顿大学大学的人写的，专门解决这种臭名昭著的棘手问题，没看的太明白，但是大概思想是把生产者和消费者分类，因为有些生成者是高产者，而有些消费者是高消费者，无论单一的产用pull的方式

    或者是push的方式都不是太合适，他们会根据用户的生产效率和登录比率来判断到底给用pull的方式或者是push的方式，当然作者也说类似follows的应用时臭名昭著的应用

    难于设计扩展等，作者也做了性能优化方面的分析，用了yahoo的开源的pnuts的key value的一个系统。把用户的好友关系抽象成一张图，然后利用一定的算法来优化这种follows的应用。而且作者通过调用twitter的api进行了一些测试，测试效果还不错。

    仔细想想也是，以前总以为设计这种系统要么是是push给用户，要么是pull给用户，但是其实两者是可以结合的，相互弥补。

follows的pnuts应用

    看来世事没有绝对性有时候需要结合两个极端来思考问题，中庸也许是一种更好的解决办法。就像老子的思想那样，物极必反。事不能要一个极端。我会附加上作者的论文，本身我也

    不全明白，多读几篇follows pdf

建议继续学习：

1. 消息系统该Push/Pull模式分析    (阅读：5014)
2. Push Or Pull?    (阅读：3814)
3. iOS push服务    (阅读：3606)
4. APP的推送是咋回事    (阅读：3355)
5. Array的push与unshift方法性能分析    (阅读：2616)
6. Android最方便的推送框架    (阅读：2582)
7. 苹果iOS系统下的推送机制及实现    (阅读：2524)
8. 微信收费事件背后被广泛忽略的技术细节    (阅读：2464)
9. 苹果信息推送服务（Apple Push Notification Service）使用总结    (阅读：1700)