在容量足够的情况下,当然是越大越好,但这样会造成浪费.不考虑这种情况.我们一般的情况是:
- memcache集群一开始创建会根据存储的数据量与访问量进行容量大小的估算.再算一个20%的冗余.
- 在网站快速增长的情况下,如果容量不够会带来性能的影响.如何提前感知memcache容量不足的情况,又如何确定要再扩容多少?
- 另外一开始如果估算得太多了,又如何来缩减这个容量.
思考:
- 从stats出发,可以通过查看mc的状态,像命中率, evictions 的多少决定了mc的容量是否足够,但是不同的mc的使用,淘汰的策略可能不一样,导致这个方法好像不够有通用性.最关键的问题,如果知道这个集群的容量不够了,又如何来判断应该再扩容多少.
- 另外mc的扩容其实不是很方便的,内存数据可能需要重做,当然像facebook那是有一整套的mc集群方案了,这里还是只讨论原生的基础上能做的一些事情.
- 是否有成熟的通用的方案?
- 涉及的数值有"淘汰率 Cache命中率 命中率日变化 内存使用量",不能单看一个数据,该如何综合考虑.
- 如果在大访问量的集群里,采用一致性hash,对于mc的扩容与缩减,都是相当恶心的,一般都会采取哪些办法做到最小影响的平滑过渡.
可能说得有些乱,集思广益.谢谢.
引用:
Scaling Memcache At Facebook
http://www.oschina.net/translate/scaling-memcache-facebook?cmp
简单说一下我的看法
1） 采用consistent hash来scaling memcache节点还是可取的，如果每一个节点相对来说比较小，对整体的影响不会很大，还算是一种比较经济的方案，而且client端的支持也挺容易的
2） 根据memcache的淘汰率问题来监控cache是否饱和和memcahce的slab的配置以及存储的长度的相关性很大，如果memcache存储的东西长度都差不多的话，整体的使用率不高的时候某些内容的淘汰率就很高了