Memcached集群/分布式的单点故障

我看到过这样一段文字
“
memcached如何处理容错的？
不处理！:) 在memcached节点失效的情况下，集群没有必要做任何容错处理。如果发生了节点失效，应对的措施完全取决于用户。节点失效时，下面列出几种方案供您选择：
* 忽略它！ 在失效节点被恢复或替换之前，还有很多其他节点可以应对节点失效带来的影响。
* 把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下（余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！因为哈希参照的节点列表变化了，大部分key会因为哈希值的改变而被映射到（与原来）不同的节点上。
* 启动热备节点，接管失效节点所占用的IP。这样可以防止哈希紊乱（hashing chaos）。
”
  同学们，根据上面的说法，memcached其中一个节点失效以后，memcached本身是没有任何策略维持失效转发的，这对于大型系统是一个无法接受的事实。

    Memcached分布式每个服务器端本身没有相互相连的关系，数据分布是由客户端来维持的，也可以说Memcached还没有为集群提供真的高可用方案，因为从集群的定义上来说需要满足：1.压力分载 2.失效转发。

   在项目组中lianjie.you同学问我如果在分布式中的其中一台Memcached节点down掉了，应该如何解决？我当时愣住了，一时之间还不能给出任何完整的答案。

   今早在座公车来上班的路上用手机上网Google了一下，发现原来在网上有很多人与我们有相同的问题，我Google的关键字是“Memcached 单点”  、“Memcached 单点故障”。给出的搜索结果都不算让人满意，我才打算写一篇关于解决集群中Memcached单点故障的文章。Javabloger只向大家提供2种解决 思路，暂时不提供具体代码。

  现象描述：
    在客户端连接的部分写入多个服务器端的ip地址，客户端将会自动的把缓存数据分布的放在每个不同的机器上，如图所示：

查看大图请点击这里

现象后果：
    如果其中一个缓存节点的机器down机，那么客户端存入的缓存数据将会丢失一部分，就是图中红色字体描述的“Losed 33% Cache Data”，也就是说那部分数据彻底没有了！如果是用户的关键性信息那么就玩大了，如图所示：
查看大图请点击这里

解决方案1：本地备份缓存
    在本地放一份缓存，同时也在分布式Memcached上放一份缓存，如果当其中一台节点当机了，客户端程序直接读取本地的缓存，本地客户端维护一个 HashMap即可，这样的方案虽然很简陋，但是可以满足一部分场景的需要，当你很急需的时候可以作为临时方案暂时替代一下。

解决方案2：采用缓存代理服务器
    采用 Magent 缓存代理，防止单点现象，缓存代理也可以做备份，通过客户端连接到缓存代理服务器，缓存代理服务器连接缓存服务器，缓存代理服务器可以连接多台Memcached机器可以将每台Memcached机器进行数据同步。这样的架构比较完善了，如果其中一台缓存代理服务器down机，系统依然可以继续工作，如果其中一台Memcached机器down掉 ，数据不会丢失并且可以保证数据的完整性，以上描述的系统架构如图所示：

查看大图请点击这里

还是那句话：没有任何架构是最完美的，只是最合适的，任何架构都不可能一步到位，都是经过一步一步演变过来的。

–end–