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

原打算在memcached的基础上开发（或者是使用它的协议），经考查有几个问题，就放弃掉了：

• memcached的slab划分方式，不利于大小数据混合，考虑一种极端情况：开始时写的数据全都是100字节的，把内存全部用完；此时再想分配 200字节，就没有内存可用，由于我们的数据量非常大，随着用户数据的增长很容易出现这种情况。它没有一种有效的内存碎片回收机制。
• memcached的文本协议没有流水号，只能同步阻塞方式调用。udp协议要自己实现许多功能，比如流量控制、丢失重传等。
• 双层冗余Cache池还设计了一套类似于分布式存储系统的快速迁移机制，一旦一台Cache挂掉后就直接放弃里面的所有数据，重启后直接从其它节点迁移过来填充，迁移效率取决于网络带宽，极短的时间就可以把命中率提高到正常水平，减少系统风险。由于有双层cache冗余，在扩容时cache失效率也接近0，比consistent hashing还要高，当然每层cache还是使用consistent hashing来减少扩容时的cache失效率。在memcached的代码上增加这些功能，得到的好处太少。

cache 是自己开发的，基于内存整理的回收方式。内存硬件的效率非常高，一般服务器内存带宽都可以达到几GB/s，因此没有太担心效率问题。一个page上的小块数据可以一起回收，多个逻辑连续的page分组进行空间整理，可以保证每个操作至多处理N个page（N<10）。内存整理的开销完全分摊，实际测试一次cache操作最快只要几微秒，最慢几百微秒，压力测试可以达到80万/秒，完全满足业务需要。

评论

4 楼 qiezi 2009-06-16  

iso1600 写道

文中讲了环境，但冗余是怎么样实现的，是双写还是服务自身去replication? 是用什么样的策略及算法，这个比较关注……另外文中提到“但把Cache持久化是否合适？”，但memcachedb不是memcache(虽然很多人误这样认为)，mcdb是用来存储持久数据的。

目前冗余是双写完成的，这样开发比较简单，可能会造成部分数据不一致，以后可能会增加简单事务提交，不过双写应该不会改变，G(oogle)FS也是双写〜

memcached没有持久化，它的分布式也较为简陋，宕机后对db造成冲击的例子应该很多。

memcachedb主要提供持久化存储，并不是cache服务，这里拿它比较可能不合适。

cachedb使用集中的持久化存储来加强cache，需要额外的后端，数据量一旦变得很大（这很容易出现），性能问题就不可避免，很难应付宕机风险。还有一种容易忽视的风险是"not found"，就是数据在cache中不存在，一旦有大量不存在的key访问，压力就会完全传递到qdbm上，当然也可以在应用层避开这个问题。

3 楼 iso1600 2009-06-16  

文中讲了环境，但冗余是怎么样实现的，是双写还是服务自身去replication? 是用什么样的策略及算法，这个比较关注……
另外文中提到“但把Cache持久化是否合适？”，但memcachedb不是memcache(虽然很多人误这样认为)，mcdb是用来存储持久数据的。

2 楼 qiezi 2009-06-15  

软件上保证的〜

1 楼 老熊 2009-06-15  

cache冗余应该是类似硬盘raid 0+1吧，是利用程序来保证冗余的？还是硬件？