在QCon北京2012听了人人缓存发展历程，实用的信息很多，记录如下：
2012年，cache数据：10T+，数据类型：object、 list、 text、count，cache server 300+ ,
调用：User 13w QPS Relation 4wQPS Auth：6wQPS
阶段一
07-08年，定制化的服务，每个需求都有相应的存储逻辑，数据结构也是定制的，通过client将调用后台服务获取数据，对cache和db的操作有后台服务管理。
优点：数据接口粒度细，定制化高，调用方便。
缺点：定制化的cache种类过多，不易管理。cache与逻辑耦合在一起，每次上线不易，只能在请求低峰期上线新功能，避免cache失效导致db压力大；如果cache有bug导致系统无法提供服务。
阶段二
分离cache和logic，提供cache service。
cache分类依据：
类型：k-v k-list
特性：调用量、访问频率
CAP：是否容忍不一致
分类：
core cache：例如登陆认证需要的用户信息
relation cache：k-list
Content cache：常见的文本信息
app cache：提供给第三方，不重要
阶段三
HA改造，cache冗余
cache请求增多，cache某个节点崩溃会导致雪崩效应，如果cache挂掉就会导致网站挂运维。重要数据、请求量的数据做冗余，好处：提高可用性，减小某些节点的压力；问题：某些数据可能有多份副本，如果更新数据，会有考虑一致性的情况，解决方案：记录这些数据的key，在访问低峰期进行数据定期同步。另外一个问题：内存使用量增加。
避免冗余的方式：
硬件
1、cache集群足够大
2、cache节点 failover
3、cache misses统计，当节点挂掉时可容忍的miss率
4、ssd提高数据库的响应能力，fushion-io提高吞吐量
cache策略：
热点数据做cache冗余，冷数据查db，普通数据合理的miss率
阶段四
2010年左右，迁移到memcached，废弃自实现的cache系统，节约了30%-40%的内存使用量。
遇见的问题：
不同大小的数据统统放到memcache中，memcache的slab allocation内存分配与管理机制导致内存不能被充分利用，频繁的迁入迁出操作。
建议：大小类似的数据分配到一个集群，预先定义好每个集群的slab的大小。规划cache容量与可容忍的cache miss。
阶段五
Tripod Cache，2012正在做。平台化、跨IDC数据同步。支持memcache和redis。通过MQ实现IDC数据同步；淘宝Tair的跨IDC解决方案是通过mysql binlog（光纤）来实现的，实时一致性性要求极高，人人的实时性要求低。
技术细节
1、按照热度、数据大小、miss容忍度来划分
2、多线程获取同一个key的cache，要注意线程同步，避免无用请求。
3、多key获取数据，通过multi get--xmemcache client支持