关于微博feed系统推拉模式的一些想法

最近看了一些关于微博feed系统推拉模式及时间分区拉模式的架构，结合之前自己所开发的，提出一些想法，之前的项目也是采用推模式，但没太注重数据储存这块，但当一些明星用户或被关注的粉丝达到一个量级时所产生的数据量真是不敢想像的

当看到时间分区拉模式时，突然想到了很早之前的一个想法， 或许可以结合着一起使用，采用推模式虽然速度快，性能高，但他会产生大量的数据，系统越大，所产生的数据量就越惊人，而时间分区拉模式呢，虽然解决了数据量的问题，但对于feeds表来说压力会很大，性能也不如推模式，不过缓存或许可以减小一些压力和提高一些性能，但用uid in(followinguidlist)，要是followinguid(关注者)很大时，这条sql该怎么写？

所以我想可以简单改变一下，按需提取，在系统中每一个用户有一个ID列表(所有一个微薄都只用一个ID识别)，当用户刷新当前的数据列表时，读取的时候只要读出这些ID的信息就行，而不是读所有关注者的数据，

比如：A发表信息后通知粉丝B(当然还有其他所有粉丝，所以这里可以用后端脚本来跑)需要更新，B在读取的时候先读缓存，再读需要更新的数据列表(这里就跟时间分区拉模式差不多，根据缓存时间去相应的feeds表里读取)，再写入缓存，当然这里还可以当某个用户的需更新的数据列表达到某一数据，直接交给另一个服务，让他自动更新其缓存，可以避免一些长时间不登录者的数据列表过大。这里还有其他问题，比如我是用memcached做缓存的(或许可以不用存在内存里)，如果down机怎么办，还有缓存结构，并发等，但我觉的如采用传统的推拉模式一样也有这些问题(推模式会相对好些)

以上只是我的一些个人想法，或许有很多问题，希望大家看了后能给我好的建议