系统架构——从Memcache单点说起

      要回答“文章摘要”里面的单点问题，其实回头想想，也不难。但是，这种系统架构的东西，不要为解决问题而解决问题，需要衡量一下这个改动对系统性能方面的影响。

1、系统架构的演变

     余浩东（具体是谁，不认识）撰写的《最新大型网站技术架构探讨.ppt》（下载地址：http://pan.baidu.com/s/1sj6jujF），很好地诠释了从单一服务到多层次架构的演变，每次演变都有自己的用武之地，不能一概而论，谁好谁不好！演变过程如下：

1. Web动静态资源分离及其与DB物理分离
2. 采取缓存处理
3. 增加机器做HA、数据库读写分离
4. CDN、分布式缓存、分库
5. 多个数据中心，向分布式存储和计算的架构体系迈进。

    最后形成的大型网站架构图：

这里讲的Memcache单点问题就位于“Distributed Data Cache”这一层。

2、回到单点问题

如果某个大型网站的设计像最后一张图那样复杂，退一步讲，即使Memcache宕机了，访问数据库，人家前边不还有一个DAL（多个Read）吗？所以， 复杂的架构从某种角度上来说基本保证了服务的高可用性。但是，架构师的作用就是保证每个节点都是高可用的，这就要你要能骑三个轮子的车，也要能骑两个轮子的车，特殊情况下，更要具备骑一个轮子的车。

3、单点问题的解决方案

其实，所有的单点问题都可以归结为多机解决方案（我当时怎么就想不到呢？）。比较典型的思路是Master/Slave解决方案。（注意：下面的方案都未验证，个人也没有测试可用性怎么样）

1. Magent代理的解决方案，示意图如下：

   
   

2. Repcached 解决方案——repcached是日本人开发的实现memcached复制功能，它是一个单 master单 slave的方案，但它的 master/slave都是可读写的，而且可以相互同步，如果 master坏掉， slave侦测到连接断了，它会自动 listen而成为 master；而如果 slave坏掉， master也会侦测到连接断，它就会重新 listen等待新的 slave加入。（这个方案似乎更简练些，以简单为美，个人如果要想修复这个单点问题会首选它）
两种方案的优缺点网上都有介绍，自行斟酌。

4、为什么Memcache自己不提供M/S

Memcache的官方说法是不提供容错处理。先来看看Memcache集群的存储原理。

memcached是怎么工作的？ Memcached的神奇来自两阶段哈希（two-stage hash）。Memcached就像一个巨大的、存储了很多<key,value>对的哈希表。通过key，可以存储或查询任意的数据。 客 户端可以把数据存储在多台memcached上。当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点；客户端将 请求发送给选中的节点，然后memcached节点通过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）。 举个列子，假设有3个客户端1, 2, 3，3台memcached A, B, C： Client 1想把数据”barbaz”以key “foo”存储。Client 1首先参考节点列表（A, B, C），计算key “foo”的哈希值，假设memcached B被选中。接着，Client 1直接connect到memcached B，通过key “foo”把数据”barbaz”存储进去。Client 2使用与Client 1相同的客户端库（意味着阶段一的哈希算法相同），也拥有同样的memcached列表（A, B, C）。 于是，经过相同的哈希计算（阶段一），Client 2计算出key “foo”在memcached B上，然后它直接请求memcached B，得到数据”barbaz”。

Memcache这样设计的好处：

Memcached最大的好处就是它带来了极佳的水平可扩展性，特别是在一个巨大的系统中。由 于客户端自己做了一次哈希，那么我们很容易增加大量memcached到集群中。memcached之间没有相互通信，因此不会增加 memcached的负载；没有多播协议，不会网络通信量爆炸（implode）。memcached的集群很好用。内存不够了？增加几台 memcached吧；CPU不够用了？再增加几台吧；有多余的内存？在增加几台吧，不要浪费了。

通过阅读上面的文字，我们可以理解为什么Memcache不提供M/S。M/S成倍增加的数量，在大型网站的设计来说，维护就更加困难了。第三方提供的插件，我们不好在性能上、可用性等方面评价M/S设计的方案的优劣。

5、后记

      其实，在架构的技术选型的过程中，基本上都是选用某个组件的擅长的方面在使用，组件不擅长的功能一般都会忽略。个人觉得，既然选用Memcache作为分布式缓存，就应该清楚它的脾气。所以，Memcache的单点问题在选型的时候就不应该考虑的，否则可以尝试选用其他没有单点问题的分布式缓存系统如：Redis。Redis与Memcache都是内存行数据库，但Redis没单点问题，本身系统就是支持的。

      从阿里面试的那个问题来说，我没答上来是事实，在思考问题的时候或规划的时候，应该想想系统的应用场景，分角色选型技术，不要绕道系统的胡同中去，往外面跳一步，往往得到的更开阔的答案。

PS：在技术选型上，最好不要选用Haproxy作为反向代理软件，我用过两个网站提供Haproxy代理的可用性都不太好。

此文，谨以向阿里的大牛致敬！