QCon北京2012-人人网缓存系统架构的发展总结

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