论坛首页 Java企业应用论坛

如何提高缓存服务器的可用性

浏览 1637 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-05-23   最后修改:2009-05-23

上一篇我们讨论到了问题 ,现在我来讲讲我的解决方法。

 

首先要明确几点:

*缓存服务器不是数据库,是允许部分失败的,也是允许一定程度上的不一致的

*我们要解决的是分布式缓存的整体可用性,而不是单台服务器的可用性

 

如果场景不是这样,或者不同意我对缓存服务器的作用的假设,下面就没必要看了。

 

首先,我们肯定是在客户端来解决这个问题,在我看来,服务器端解决,让每个服务节点知晓其他的存在,这是把事情复杂化了,而且往往是吃力不讨好的。就像应用服务器的集群一样,只要你想想session复制这个问题,你就不会在有100个节点的情况下,是用服务器的集群了。

 

在客户端处理这个问题,有很多好处,服务器简单了,除了干缓存服务这件事情,其他什么都不管,简单就是美嘛。这也是我为什么特别欣赏memcached的原因,他的设计实在太简单了,功能也非常简单,几乎一点浪费都没有(当然,这是整体设计而言,实现细节有的地方还是需要改进,比如以前的文本协议,内部的锁等,都有改进的余地)。另外,在客户端处理其实更容易容错,毕竟在靠近数据的地方处理,总会在另外一端容易,我发送失败了还可以选择其他策略,如果在接收端处理,这个就麻烦多了,就算再回到客户端,这个效率都差很多。

 

然后,就是具体的策略问题了。2N的策略没必要,也不一定完全可靠,上一篇已经讨论过了,其实关键的是我们不需要完全 可靠。我们主要来探讨N+n(n<<N)的方案。这其实是讨论中二柱哥提到的方案,我这里简单的在这个场景描述一下,不知道理解是否正确,更专业的可以参考FEC(向前纠错)

 

在我们这里,所谓的N+n方案,实际上就是将系统的数据划分为N份,即提供N个节点,然后同时提供n个额外的节点,当根据原来的方案在N中找不到(N中的某节点挂了),这时候这个节点可以由n中的一个来顶替,当N中那个挂掉的节点恢复的时候,让他回到n中去,这样,就可以很大程度上保证整个farm的可用性,实际上应该比传统的每一台都一主一备的还好(2N方案)。当然,这是在N不算很小的时候才会有意义,否则N为1的话,就退化成主备的方案了。

 

在cache的客户端实现这个算法实际上并不困难,似乎方案很不错了,只需要适当调整n的大小就可以了。但是这里有一点漏洞,这一点,二柱哥也提到了(偶像啊),原话:

一个系统内,关于冗余的设计最好能单点控制, 不然容易出现震荡

如果没有这样的经历的话,很容易忽略掉这个问题,想象一下,如果按照我们上面的方案去做,我们需要在每个客户端去对N和n中的每个节点维护他的状态,记录是否可用,然后根据情况来执行算法,问题就在于每个客户端瞬时检测到的节点状态不一定一致,这时候就会发生震荡,因此我们需要想办法来在一个单点来控制这些冗余。

 

如何设计这个单点又是一个问题,我也没很好的想法,大家讨论讨论吧。

 

 

 

论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics