1、memcached能接受的key的最大长度是多少？ (250字符)
key的最大长度是250个字符。需要注意的是，250是memcached服务器端内部的限制，如果您使用的客户端支持"key的前缀"或类似特性，那么key（前缀+原始key）的最大长度是可以超过250个字符的。我们推荐使用使用较短的key，因为可以节省内存和带宽。 （我们对key+value的总长度控制在64kb，没有对key单独做限制）
2、memcached对item的过期时间有什么限制？ （最大过期时间30天）
过期时间最大可以达到30天。memcached把传入的过期时间（时间段）解释成时间点后，一旦到了这个时间点，memcached就把item置为失效状态。这是一个简单但obscure的机制。(我们不限制，到2038年)
3、memcached最大能存储多大的单个item？ (1MB)
1MB。如果你的数据大于1MB，可以考虑在客户端压缩或拆分到多个key中。
（我们对key+value的总长度控制在64kb，没有对key单独做限制）
4、为什么单个item的大小被限制在1M byte之内？
简单的原因：因为内存分配器的算法就是这样的。
详细的原因：Memcached的内存存储引擎（引擎将来可插拔...），使用slabs来管理内存。内存被分成大小不等的slabs chunks（先分成大小相等的slabs，然后每个slab被分成大小相等chunks，不同slab的chunk大小是不相等的）。chunk的大小依次从一个最小数开始，按某个因子增长，直到达到最大的可能值。
如果最小值为400B，最大值是1MB，因子是1.20，各个slab的chunk的大小依次是：slab1 - 400B slab2 - 480B slab3 - 576B ...
slab中chunk越大，它和前面的slab之间的间隙就越大。因此，最大值越大，内存利用率越低。Memcached必须为每个slab预先分配内存，因此如果设置了较小的因子和较大的最大值，会需要更多的内存。
还有其他原因使得您不要这样向memcached中存取很大的数据...不要尝试把巨大的网页放到mencached中。把这样大的数据结构load和unpack到内存中需要花费很长的时间，从而导致您的网站性能反而不好。
如果您确实需要存储大于1MB的数据，你可以修改slabs.c:POWER_BLOCK的值，然后重新编译memcached；或者使用低效的malloc/free。其他的建议包括数据库、MogileFS等。
5、我可以在不同的memcached节点上使用大小不等的缓存空间吗？这么做之后，memcached能够更有效地使用内存吗？
Memcache客户端仅根据哈希算法来决定将某个key存储在哪个节点上，而不考虑节点的内存大小。因此，您可以在不同的节点上使用大小不等的缓存。但是一般都是这样做的：拥有较多内存的节点上可以运行多个memcached实例，每个实例使用的内存跟其他节点上的实例相同。
6、memcached的内存分配器是如何工作的？为什么不适用malloc/free！？为何要使用slabs？
实际上，这是一个编译时选项。默认会使用内部的slab分配器。您确实确实应该使用内建的slab分配器。最早的时候，memcached只使用malloc/free来管理内存。然而，这种方式不能与OS的内存管理以前很好地工作。反复地malloc/free造成了内存碎片，OS最终花费大量的时间去查找连续的内存块来满足malloc的请求，而不是运行memcached进程。如果您不同意，当然可以使用malloc！只是不要在邮件列表中抱怨啊:)
slab分配器就是为了解决这个问题而生的。内存被分配并划分成chunks，一直被重复使用。因为内存被划分成大小不等的slabs，如果item的大小与被选择存放它的slab不是很合适的话，就会浪费一些内存。Steven Grimm正在这方面已经做出了有效的改进。
7、一致性Hash算法的目的有两点：一是节点变动后其他节点受影响尽可能小；二是节点变动后数据重新分配尽可能均衡 。
8、为什么要运行 memcached ？
如果网站的高流量很大并且大多数的访问会造成数据库高负荷的状况下，使用 memcached 能够减轻数据库的压力。
9、适用memcached的业务场景？
1）如果网站包含了访问量很大的动态网页，因而数据库的负载将会很高。由于大部分数据库请求都是读操作，那么memcached可以显著地减小数据库负载。
2）如果数据库服务器的负载比较低但CPU使用率很高，这时可以缓存计算好的结果（ computed objects ）和渲染后的网页模板（enderred templates）。
3）利用memcached可以缓存session数据、临时数据以减少对他们的数据库写操作。
4）缓存一些很小但是被频繁访问的文件。
5）缓存Web 'services'（非IBM宣扬的Web Services，译者注）或RSS feeds的结果.。
10、不适用memcached的业务场景？
1）缓存对象的大小大于1MB
Memcached本身就不是为了处理庞大的多媒体（large media）和巨大的二进制块（streaming huge blobs）而设计的。
2）key的长度大于250字符
3）虚拟主机不让运行memcached服务
如果应用本身托管在低端的虚拟私有服务器上，像vmware, xen这类虚拟化技术并不适合运行memcached。Memcached需要接管和控制大块的内存，如果memcached管理的内存
被OS或 hypervisor交换出去，memcached的性能将大打折扣。
4）应用运行在不安全的环境中
Memcached为提供任何安全策略，仅仅通过telnet就可以访问到memcached。如果应用运行在共享的系统上，需要着重考虑安全问题。
5）业务本身需要的是持久化数据或者说需要的应该是database
11、能够遍历memcached中所有的item吗？
不能，这个操作的速度相对缓慢且阻塞其他的操作（这里的缓慢时相比memcached其他的命令）。memcached所有非调试（non-debug）命令，例如add, set, get, fulsh等无论
memcached中存储了多少数据，它们的执行都只消耗常量时间。任何遍历所有item的命令执行所消耗的时间，将随着memcached中数据量的增加而增加。当其他命令因为等待（遍历所
有item的命令执行完毕）而不能得到执行，因而阻塞将发生。
12、memcached的cache机制是怎样的？
Memcached主要的cache机制是LRU（最近最少用）算法+超时失效。当您存数据到memcached中，可以指定该数据在缓存中可以呆多久Which is forever, or some time in the
future。如果memcached的内存不够用了，过期的slabs会优先被替换，接着就轮到最老的未被使用的slabs。
13、memcached如何实现冗余机制？
不实现！Memcached应该是应用的缓存层，从设计本身来京就不带有任何冗余机制。如果一个memcached节点失去了所有数据，应该可以从数据源（比如数据库）再次获取到数据。应
用系统应该可以容忍节点的失效。如果担心节点失效会大大加重数据库的负担，那么可以采取一些办法。比如您可以增加更多的节点（来减少丢失一个节点的影响），热备节点（在其他节
点down了的时候接管IP）等等。
14、memcached如何处理容错的？
在节点失效的情况下，集群没有必要做任何容错处理。如果发生了节点失效，应对的措施完全取决于用户。
节点失效时，下面列出几种方案供您选择：
1）忽略它！ 在失效节点被恢复或替换之前，还有很多其他节点可以应对节点失效带来的影响。
2）把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下（余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！因为哈希参照的节点列表变化
了，大部分key会因为哈希值的改变而被映射到（与原来）不同的节点上。
3）启动热备节点，接管失效节点所占用的IP。这样可以防止哈希紊乱（hashing chaos）。
4）如果希望添加和移除节点，而不影响原先的哈希结果，可以使用一致性哈希算法（consistent hashing）。
5）两次哈希（reshing）。当客户端存取数据时，如果发现一个节点down了，就再做一次哈希（哈希算法与前一次不同），重新选择另一个节点（需要注意的时，客户端并没有把down
的节点从节点列表中移除，下次还是有可能先哈希到它）。如果某个节点时好时坏，两次哈希的方法就有风险了，好的节点和坏的节点上都可能存在脏数据（stale data）。
15、如何将memcached中item批量导入导出？
不应该这样做！Memcached是一个非阻塞的服务器。任何可能导致memcached暂停或瞬时拒绝服务的操作都应该值得深思熟虑。向memcached中批量导入数据往往不是您真正想要
的！想象看，如果缓存数据在导出导入之间发生了变化，您就需要处理脏数据了；如果缓存数据在导出导入之间过期了，您又怎么处理这些数据呢？
因此，批量导出导入数据并不像想象中的那么有用。不过在一个场景倒是很有用。如果您有大量的从不变化 的数据，并且希望缓存很快热（warm）起来，批量导入缓存数据是很有帮助
的。
16、但是我确实需要把memcached中的item批量导出导入，怎么办？？
如果需要批量导出和导入，最可能的原因一般是重新生成缓存数据需要消耗很长的时间或者数据库坏了让您饱受痛苦。
如果一个memcached节点down了让您很痛苦，那么必须对数据库做一些优化工作。比如处理"惊群"问题（ memcached节点都失效了，反复的查询让数据库不堪重负）或者存在优化不
好的查询等。Memcached 并不是逃避优化查询的借口和方案。
这里给出一些提示：
使用MogileFS（或者CouchDB等类似的软件）在存储item，把item计算出来并dump到磁盘上。MogileFS可以很方便地覆写item，并提供快速地访问。甚至可以把MogileFS中的item
缓存在memcached中，这样可以加快读取速度。 MogileFS+Memcached的组合可以加快缓存不命中时的响应速度，提高网站的可用性。
重新使用MySQL。MySQL的 InnoDB主键查询速度非常快。如果大部分缓存数据都可以放到VARCHAR字段中，那么主键查询的性能将更好。从memcached中按key查询几乎等价于
MySQL的主键查询：将key 哈希到64-bit的整数，然后将数据存储到MySQL中。您可以把原始（不做哈希）的key存储都普通的字段中，然后建立二级索引来加快查询...key被动地失效，
批量删除失效的key，等等。
17、memcached是如何做身份验证的？
没有身份认证机制！memcached是运行在应用下层的软件（身份验证应该是应用上层的职责）。memcached的客户端和服务器端之所以是轻量级的，部分原因就是完全没有实现身份验
证机制。这样，memcached可以很快地创建新连接，服务器端也无需任何配置。如果您希望限制访问，您可以使用防火墙，或者让memcached监听unix domain socket。
18、memcached的多线程是什么？如何使用它们？
线程就是定律（threads rule）！在Steven Grimm和Facebook的努力下，memcached 1.2及更高版本拥有了多线程模式。多线程模式允许memcached能够充分利用多个CPU，并在
CPU之间共享所有的缓存数据。memcached使用一种简单的锁机制来保证数据更新操作的互斥。相比在同一个物理机器上运行多个memcached实例，这种方式能够更有效地处理multi
gets。如果系统的负载并不重，那么不需要启用多线程工作模式。