大型网站技术架构——缓存

1、使用缓存有两个前提条件，（P20页）1、数据访问热点不均衡，28定律。2、数据在某个时间段内有效，不会很快过期而产生脏读。
2、微博的架构模式（P24
发微博时，异步推拉结合

，发布者发送后写入消息队列，立即返回。在线订阅者收到推送，非在线订阅者上划刷新拉取更新内容，这样数据库的读写就就不会一时间全部进行。

刷微博，缓存策略，热门明星和热门微博都作为缓存存在微博服务器上。

推送模式， push mode
这个对于用户来说查询性能是最好的， 他只需要扫描关注人是他的timeline数据就可以了. sql语句是 where 关注人 = xxx and publish_time > xxx limit 100 , 索引也是最优的…. 如果想使用这种高效的sql查询，必然会造成数据冗余的问题。 另外推送量级过大必然会造成一定的推送延迟 . 其实据我所知，大多数应用采用 Push的方法多一点 .
这样我们拿微博第一红人姚晨来说，他的粉丝有将近几百万人。那如果使用推送的模式的化，姚晨发了一个信息，那么我们后端就要给100w的粉丝发送订阅提醒。 100w条记录呀， 还有我们知道有僵尸粉这个说法，虽然有不少人关注了姚晨，但是那些僵尸粉最多几个月登陆一次，甚至以后就不登陆了，这样的信息推送必然是浪费空间的…. 对于这么大的数据是必须考虑分库分表，毕竟 一个名人一个信息 就100w条记录…. 分库分表可以按照 用户ID来切分，或者 发表时间来切分…. 我建议使用用户ID来切分，这样能降低数据的热点问题， 这里就不详细阐述分库分表了，有兴趣的朋友可以看看我写过的mysql文章.
100w的推送量肯定不能用单线程来处理，这时候我们可以扩展分布式消息队列, 不要把100w个订阅人推送到MQ里面，因为生成任务推送也是有时间消耗的，最好的方法是 扔给每个worker一个区间 , 每个worker拿到自己的区间并推送 .
拉取模式， pull mode

看起来他跟 push推送模式差不多，只是多了不少订阅的时间区间表 . 他的优点在于减少了数据的冗余，在推送模式下你需要把信息发给所有的订阅人，他的时间复杂度是 O( N ) . 所谓的Pull模式就是当用户登陆的时候再去从这些表里面拿出订阅信息…
feeds表时间区间可划分为 最近7天，最近一个月，近三个月 及所有时间数据. 姚晨每次发信息我们确保会入库到 近一周数据表， 然后通过消息队列异步刷新到其他几个表. 为了保持数据的时效性，需要写个脚本来刷新删除过期的数据.
需要明确的一点，订阅信息是可以适量丢失的，当然还是要尽量保证数据稳定性的….
当用户登陆的时候，我们通过用户的上次的登录时间确定他适合查询那个区间表。 对于每天都登录的用户定位到近一周表 ！半个月登录一次的，定位到一个月表。 以此类推呀！！！
不需要过度依次去查询，只跳跃一个表，一周没有的，就去近一个月订阅表瞅瞅！ 一般来说是不需要再去三个月订阅表. 一般应用的订阅信息流是推广信息，个性推荐，广告参杂一起的，所以更加没必须要一定要把关注的信息拿到.

Pull模式最大的优点在于节省存储空间，缺点就是 性能不在地… 因为你的sql查询语句是 where sender in ( uid1, uid2, uid3 … … ) and publish_time > xxxx ; sql的in性能是让人无语的， 当sql操作符不确定时索引利用率是最低的。 这样的查询注定是花费时间的，解决方法是在业务层面异步加载数据，当你打开App的时候，我们可以预先就去拉取他的数据， 这样当用户打开订阅功能时， 就可以及时看到订阅信息了。