在容量足够的情况下,当然是越大越好,但这样会造成浪费.不考虑这种情况.我们一般的情况是:
- 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