memcached全面剖析

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


一个Slab可以有多个Page，这就好比在古代一个男人可以娶多个女人；一旦一个Page被分给某个Slab后，它便对Slab至死不渝，犹如古代那些贞洁的女人。但是女人的数量毕竟是有限的，所以一旦一些男人娶得多了，必然另一些男人就只剩下咽口水的份儿，这在很大程度上增加了社会的不稳定因素，于是乎我们要解放女性。

好在Memcached已经意识到解放女性的重要性，新版本中Page可以调配给其它的Slab：

shell> memcached -o slab_reassign,slab_automove

换句话说：女人可以改嫁了！这方面，其实Memcached的儿子Twemcache革命得更彻底，他甚至写了一篇大字报，以事实为依据，痛斥老子的无能，有兴趣的可以继续阅读：Random Eviciton vs Slab Automove。

了解Memcached内存使用情况的最佳工具是：Memcached-tool。如果我们发现某个Slab的Evicted不为零，则说明这个Slab已经出现了LRU的情况，这通常是个危险的信号，但也不能一概而论，需要结合Evict_Time来做进一步判断。


Multiget的无底洞问题

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

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

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


不过，作为被告方，Memcached官方开发人员对此进行了辩护：

请求多台服务器并不是问题的症结，真正的原因在于客户端在请求多台服务器时是并行的还是串行的！问题是很多客户端，包括Libmemcached在内，在处理Multiget多服务器请求时，使用的是串行的方式！也就是说，先请求一台服务器，然后等待响应结果，接着请求另一台，结果导致客户端操作时间累加，请求堆积，性能下降。

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