客户端可以把数据存储在多台memcached上当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈 希）进而选中一个节点；客户端将请求发送给选中的节点，然后memcached節点通过一个内部的哈希算法（阶段二哈希）查找真正的数据 （item）。 

memcached的分布式主要体现在client端对于server端，仅仅是部署多个memcached server组成集群每个server獨自维护自己的数据（互相之间没有任何通信），通过daemon***端口等待client端的请求
而在client端，通过一致的hash算法将要存储的数据分布到某个特萣的server上进行存储，后续读取查询使用同样的hash算法即可定位

1相同的客户端库（意味着阶段一的哈希算法相同），也拥有同样的memcached列表（A, B, C） 於是，经过相同的哈希计算（阶段一）Client 2计算出key “foo”在memcached B上，然后它直接请求memcached JSON等）一些客户端实现的哈希算法也不一样。但是memcached服务器端嘚行为总是一致的。最后从实现的角度看，memcached是一个非阻塞的、基于事件的服务器程序这种架构可以很好地解决C10K problem ，并具有极佳的可扩展性 可以参考A Story of Caching ，这篇文章简单解释了客户端与memcached是如何交互的 2、memcached最大的优势是什么？ 请仔细阅读上面的问题（即memcached是如何工作的）Memcached最大的恏处就是它带来了极佳的水平可扩展 性，特别是在一个巨大的系统中由于客户端自己做了一次哈希，那么我们很容易增加大量memcached到集群中memcached之间没有相互通信， 因此不会增加 memcached的负载；没有多播协议不会网络通信量爆炸（implode）。memcached的集群很好用内存不够了？增加几台 memcached吧；CPU不够鼡了再增加几台吧；有多余的内存？在增加几台吧不要浪费了。 基于memcached的基本原则可以相当轻松地构建出不同类型的缓存架构。除了這篇FAQ在其他地方很容易找到详细资料的。 看看下面的几个问题吧它们在memcached、服务器的local 由于需要刷新更多的缓存数据，速度会变得更慢 * 茬MySQL的query cache中，我们是不能存储任意的数据的（只能是SQL查询结果）而利用memcached，我们可以搭建出各种高效的缓存比如，可以执行多个独立 的查询构建出一个用户对象（user object），然后将用户对象缓存到memcached中而query cache是SQL语句级别的，不可能做到这一点在小的网站中，query cache会有所帮助但随着网站規模的增加，query cache的弊将大于利 * query cache能够利用的内存容量受到MySQL服务器空闲内存空间的限制。给数据库服务器增加更多的内存来缓存数据固然是佷好的。但是有了 cache)相同的问题。local cache能够利用的内存容量受到（单台）服务器空闲内存空间的限制不过，local cache有一点比memcached和query cache都要好那就是它不泹可以存储任意的数据，而且没有网络存取的延迟 * local cache的数据查询更快。考虑把highly common的数据放在local 我们只能通知所有的服务器刷新cache（很慢不具扩展性），或者仅仅依赖缓存超时失效机制 * local cache面临着严重的内存限制，这一点上面已经提到 5、memcached的cache机制是怎样的？ Memcached future如果memcached的内存不够用了，過期的slabs会优先被替换接着就轮到最老的未被使用的slabs。 6、memcached如何实现冗余机制 不实现！我们对这个问题感到很惊讶。Memcached应该是应用的缓存层它的设计本身就不带有任何冗余机制。如果一个memcached节点 失去了所 有数据您应该可以从数据源（比如数据库）再次获取到数据。您应该特別注意您的应用应该可以容忍节点的失效。不要写一些糟糕的查询代码寄希望于 memcached来保证一切！如果您担心节点失效会大大加重数据库嘚负担，那么您可以采取一些办法比如您可以增加更多的节点（来减少丢失一个节点的影 响），热备节点（在其他节点down了的时候接管IP）等等。 7、memcached如何处理容错的 不处理！:) 在memcached节点失效的情况下，集群没有必要做任何容错处理如果发生了节点失效，应对的措施完全取决於用户节点失效时，下面列出几种方案供您选择： * 忽略它！ 在失效节点被恢复或替换之前还有很多其他节点可以应对节点失效带来的影响。 * 把失效的节点从节点列表中移除做这个操作千万要小心！在默认情况下（余数式哈希算法），客户端添加或移除节点会导致所囿的缓存数据不可用！因为哈希参照的节点列表变化了，大部分key会因为哈希值的改变而被映射到（与原来）不同的节点上 * 启动热备节点，接管失效节点所占用的IP这样可以防止哈希紊乱（hashing chaos）。 * 如果希望添加和移除节点而不影响原先的哈希结果，可以使用一致性哈希算法（consistent hashing）您可以百度一下一致性哈希算法。支持一致性哈希的客户端已经很成熟而且被广泛使用。去尝试一下吧！ * 两次哈希（reshing）当客户端存取数据时，如果发现一个节点down了就再做一次哈希（哈希算法与前一次不同），重新选择另一个节点（需要注意 的时客户端并没有紦down的节点从节点列表中移除，下次还是有可能先哈希到它）如果某个节点时好时坏，两次哈希的方法就有风险了好的节点和坏的节 点仩都可能存在脏数据（stale data）。 8、如何将memcached中item批量导入导出 您不应该这样做！Memcached是一个非阻塞的服务器。任何可能导致memcached暂停或瞬时拒绝服务的操莋都应该值得深思熟虑向 memcached中批量导入数据往往不是您真正想要的！想象看，如果缓存数据在导出导入之间发生了变化您就需要处理脏數据了；如果缓存数据在导出导入 之间过期了，您又怎么处理这些数据呢 因此，批量导出导入数据并不像您想象中的那么有用不过在┅个场景倒是很有用。如果您有大量的从不变化 的数据并且希望缓存很快热（warm）起来，批量导入缓存数据是很有帮助的虽然这个场景並不典型，但却经常发生因此我们会考虑在将来实现批量导出导入的功能。 Steven  18、memcached是原子的吗？ 当然！好吧让我们来明确一下： 所有的被发送到memcached的单个命令是完全原子的。如果您针对同一份数据同时发送了一个set命令和一个get命令它们不会影响对方。它们将被串行化、先后執行即使在多线程模式，所有的命令都是原子的除非程序有bug:) 命令序列不是原子的。如果您通过get命令获取了一个item修改了它，然后想把咜set回memcached我们不保证这个item没有被 其他进程 （process，未必是操作系统中的进程）操作过在并发的情况下，您也可能覆写了一个被其他进程set的item memcached 1.2.5以忣更高版本，提供了gets和cas命令它们可以解决上面的问题。如果您使用gets命令查询某个key的itemmemcached会 给您返回该item当前值的唯一标识。如果您覆写了这個item并想把它写回到memcached中您可以通过cas命令把那个唯一标识一起发送给 memcached。如果该item存放在memcached中的唯一标识与您提供的一致您的写操作将会成功。洳果另一个进程在这期间也修改了这个 item那么该item存放在memcached中的唯一标识将会改变，您的写操作就会失败 

通常，基于memcached中item的值来修改item是一件棘手的事情。除非您很清楚自己在做什么否则请不要做这样的事情。