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

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

 

首先要明确几点：

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

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

 

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

 

首先，我们肯定是在客户端来解决这个问题，在我看来，服务器端解决，让每个服务节点知晓其他的存在，这是把事情复杂化了，而且往往是吃力不讨好的。就像应用服务器的集群一样，只要你想想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中的每个节点维护他的状态，记录是否可用，然后根据情况来执行算法，问题就在于每个客户端瞬时检测到的节点状态不一定一致，这时候就会发生震荡，因此我们需要想办法来在一个单点来控制这些冗余。

 

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