在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支持