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

原创
2014/02/04 16:12
阅读数 622

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

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代理的可用性都不太好。

此文,谨以向阿里的大牛致敬!


展开阅读全文
打赏
0
5 收藏
分享
打赏
0 评论
5 收藏
0
分享
返回顶部
顶部