高可用性Cache池

前段时间开发上线了一个Cache池，使用双层Cache池冗余，宕掉一台机器的Cache失效从1/N降到1/N^2。如果2层Cache池分开机器部署，失效率将会降到0。上线不久刚好碰上一次宕机事故，效果很好。该应用有16台Cache服务器，高峰时每秒访问约20万次，平时的命中率约为99.95%，宕掉一台会给8台db造成1.25万次/秒访问（因为命中率很高所以只计算宕机造成的Cache失效率），基本上不可能承受，以往遇到此类问题时，只能干等着高峰慢慢过去、压力降下来、同时Cache命中率缓慢提高，影响时间至少4 小时以上。使用双层冗余Cache池以后，单台Cache宕机给DB造成的压力是1/256，约780次/秒，分摊到8台db上就没多少压力了，对业务没有造成任何影响。

Cache是有状态服务，增加、删除服务器都要考虑数据一致性、对命中率的影响，这方面[url=http://blog.s135.com/post/320/]memcachedb[/url]、[url=http://blog.s135.com/post/329/]dbcached[/url]都是使用bdb/qdbm来做持久化存储，但把Cache持久化是否合适？后端数据量太大以后，也会因为io太大而性能低下，bdb性能会从几十万/秒降到几百/秒，更新操作很可能会丢弃或延迟，意味着牺牲了一致性，虽然有异步更新但也无法解决性能问题。运营中发现cache容量从每台30GB(bdb)降到2－4GB，cache命中率下降其实很少，性能却提高了不少，可以完全放在内存中。

原打算在memcached的基础上开发（或者是使用它的协议），经考查有几个问题，就放弃掉了：
[list]
[*]memcached的slab划分方式，不利于大小数据混合，考虑一种极端情况：开始时写的数据全都是100字节的，把内存全部用完；此时再想分配 200字节，就没有内存可用，由于我们的数据量非常大，随着用户数据的增长很容易出现这种情况。它没有一种有效的内存碎片回收机制。
[*] memcached的文本协议没有流水号，只能同步阻塞方式调用。udp协议要自己实现许多功能，比如流量控制、丢失重传等。
[*] 双层冗余Cache池还设计了一套类似于分布式存储系统的快速迁移机制，一旦一台Cache挂掉后就直接放弃里面的所有数据，重启后直接从其它节点迁移过来填充，迁移效率取决于网络带宽，极短的时间就可以把命中率提高到正常水平，减少系统风险。由于有双层cache冗余，在扩容时cache失效率也接近0，比consistent hashing还要高，当然每层cache还是使用consistent hashing来减少扩容时的cache失效率。在memcached的代码上增加这些功能，得到的好处太少。
[/list]
cache 是自己开发的，基于内存整理的回收方式。内存硬件的效率非常高，一般服务器内存带宽都可以达到几GB/s，因此没有太担心效率问题。一个page上的小块数据可以一起回收，多个逻辑连续的page分组进行空间整理，可以保证每个操作至多处理N个page（N<10）。内存整理的开销完全分摊，实际测试一次cache操作最快只要几微秒，最慢几百微秒，压力测试可以达到80万/秒，完全满足业务需要。