Memcache 的一些问题及解决方法

xuke123

　　为了规避内存碎片问题，Memcached采用了名为SlabAllocator的内存分配机制。内存以Page为单位来分配，每个Page分给一个特定长度的Slab来使用，每个Slab包含若干个特定长度的Chunk。实际保存数据时，会根据数据的大小选择一个最贴切的Slab，并把数据保存在对应的Chunk中。如果某个Slab没有剩余的Chunk了，系统便会给这个Slab分配一个新的Page以供使用，如果没有Page可用，系统就会触发LRU机制，通过删除冷数据来为新数据腾出空间，这里有一点需要注意的是：LRU不是全局的，而是针对Slab而言的。
　　

　　

新版本中Page可以调配给其它的Slab：

shell> memcached -o slab_reassign,slab_automove

　　


Cache失效后的拥堵问题

通常我们会为两种数据做Cache，一种是热数据，也就是说短时间内有很多人访问的数据；另一种是高成本的数据，也就说查询很很耗时的数据。当这些数据过期的瞬间，如果大量请求同时到达，那么它们会一起请求后端重建Cache，造成拥堵问题，就好象在北京上班做地铁似的，英文称之为：stampeding
herd，老外这里的用词还是很形象的。

一般有如下几种解决思路可供选择：

首先，我们可以主动更新Cache。前端程序里不涉及重建Cache的职责，所有相关逻辑都由后端独立的程序（比如CRON脚本）来完成，但此方法并不适应所有的需求。


　　

还有一些特殊情况没有考虑到：设想一下服务重启；或者某个Cache里原本没有的冷数据因为某些情况突然转换成热数据；又或者由于LRU机制导致某些键被意外删除，等等，这些情况都可能会让上面的方法失效，因为在这些情况里就不存在所谓的旧数据，等待用户的将是一个空页面。




好在我们还有Gearman这根救命稻草。当需要更新Cache的时候，我们不再直接查询数据库，而是把任务抛给Gearman来处理，当并发量比较大的时候，Gearman内部的优化可以保证相同的请求只查询一次后端数据库


　　

　　


Multiget的无底洞问题

Facebook在Memcached的实际应用中，发现了Multiget无底洞问题，具体表现为：出于效率的考虑，很多Memcached应用都已Multiget操作为主，随着访问量的增加，系统负载捉襟见肘，遇到此类问题，直觉通常都是通过增加服务器来提升系统性能，但是在实际操作中却发现问题并不简单，新加的服务器好像被扔到了无底洞里一样毫无效果。

为什么会这样？让我们来模拟一下案发经过，看看到底发生了什么：

我们使用Multiget一次性获取100个键对应的数据，系统最初只有一台Memcached服务器，随着访问量的增加，系统负载捉襟见肘，于是我们又增加了一台Memcached服务器，数据散列到两台服务器上，开始那100个键在两台服务器上各有50个，问题就在这里：原本只要访问一台服务器就能获取的数据，现在要访问两台服务器才能获取，服务器加的越多，需要访问的服务器就越多，所以问题不会改善，甚至还会恶化。






为什么会这样？让我们来模拟一下案发经过，看看到底发生了什么：

我们使用Multiget一次性获取100个键对应的数据，系统最初只有一台Memcached服务器，随着访问量的增加，系统负载捉襟见肘，于是我们又增加了一台Memcached服务器，数据散列到两台服务器上，开始那100个键在两台服务器上各有50个，问题就在这里：原本只要访问一台服务器就能获取的数据，现在要访问两台服务器才能获取，服务器加的越多，需要访问的服务器就越多，所以问题不会改善，甚至还会恶化。




如何解决这个棘手的问题呢？只要保证Multiget中的键只出现在一台服务器上即可！比如说用户名字（user:foo:name），用户年龄（user:foo:age）等数据在散列到多台服务器上时，不应按照完整的键名（user:foo:name和user:foo:age）来散列的，而应按照特殊的键（foo）来散列的，这样就保证了相关的键只出现在一台服务器上。