让memcached分布式 &分布式设计与开发（二）------几种必须了解的分布式算法

转自：http://blog.csdn.net/cutesource/archive/2010/08/29/5848253.aspx

memcached是应用最广的开源cache产品，它本身不提供分布式的解决方案，我猜想一方面它想尽量保持产品简单高效，另一方面cache的key-value的特性使得让memcached分布式起来比较简单。memcached的分布式主要在于客户端，通过客户端的路由处理来搭建memcached集群环境，因此在服务端，memcached集群环境实际上就是一个个memcached服务器的堆积品，环境的搭建比较简单。下面从客户端做路由和服务端集群环境搭建两方面来谈如何让memcached分布式

客户端做路由

客户端做路由的原理非常简单，应用服务器在每次存取某key的value时，通过某种算法把key映射到某台memcached服务器nodeA上，因此这个key所有操作都在nodeA上，结构图如下所示：

存储某个key-value





取某个key-value





因此关键在于算法的选择，最基本的要求就是能让数据平均到所有服务器上。这自然而然让我想到了hash算法，spymemcached是一个用得比较广的java客户端，它就提供了一种简单的hash算法，实现类为ArrayModNodeLocator，从key映射到node的源码如下：

public MemcachedNode getPrimary(String k) {

return nodes[getServerForKey(k)];

}

private int getServerForKey(String key) {

int rv=(int)(hashAlg.hash(key) % nodes.length);

assert rv >= 0 : "Returned negative key for key " + key;

assert rv < nodes.length

: "Invalid server number " + rv + " for key " + key;

return rv;

}

从上面可知它是把所有node放在数组里，通过hash算法把key映射到某index，然后通过这个index在数组里取node

再则需要考虑如何容错，比如当某个node当掉了，如何自动地转到其他node上，上面的简单hash路由策略采用的方法是在数据组里顺序向下轮询node，找第一个工作正常的node即可。

最后要考虑当需要移除node或添加node的时候，如何有效地调整映射关系，这自然又让我们想到一致性hash算法，关于一致性hash算法就不多说，博文分布式设计与开发（二）------几种必须了解的分布式算法 有所涉及，这里可以看看spymemcached是如何利用这个算法来做路由的，实现类为KetamaNodeLocator，从key映射到node的源码如下：

public MemcachedNode getPrimary(final String k) {

MemcachedNode rv=getNodeForKey(hashAlg.hash(k));

assert rv != null : "Found no node for key " + k;

return rv;

}

MemcachedNode getNodeForKey(long hash) {

final MemcachedNode rv;

if(!ketamaNodes.containsKey(hash)) {

// Java 1.6 adds a ceilingKey method, but I'm still stuck in 1.5

// in a lot of places, so I'm doing this myself.

SortedMap tailMap=ketamaNodes.tailMap(hash);

if(tailMap.isEmpty()) {

hash=ketamaNodes.firstKey();

} else {

hash=tailMap.firstKey();

}

}

rv=ketamaNodes.get(hash);

return rv;

}

这段代码非常清晰，就是通过ketamaNodes这个数据结构按照一致性hash算法把node分区，每次都把映射到一个分区的key对于到负责这个分区的node上。

从上面几段代码和图示，我们大致能弄明白在客户端如何做路由来让memcached分布式，其实在大多数的项目中，以上这些简单的处理办法就足够了

memcached服务端集群

由上面可知一般的应用中memcached服务端集群不用做太多工作，部署一堆memcached服务器就可以了，大不了就是要做好监控的工作，但像facebook这样的大型互联网应用，并且又是那么依赖memcached，集群的工作就很有学问了。今年Qcom的会议上facebook就介绍了是如何通过扩展memcached来应付这么多数据量的，ppt可见Facebook的扩展Memcached实战。这个PPT比较抽象，我没看得太懂，并且facebook也只是蜻蜓点水，没透露太多的细节，但公司的资深架构师陈大峰同学做了些解析，才多多少少有点眉目。facebook所有数据的存取都基本上是在memcached上完成，后端的数据库mysql仅仅只是做持久化的作用，由于数据量巨大，做了类似与mysql的读写分离的结构，结构图如下所示：





其中非常重要的一点，当West的memcached要向East同步数据的时候，它没有采取memcached之间的同步，而是走MySQL replication，如下图所示：





这么做的原因我没法搞得太清楚，大概是比较信赖MySQL replication的简单稳定吧，并且像sns这种应用本身就不需要即时一致性，只要最终一致就行了。

另外在数据分布上是很有讲究的，facebook上面有很多很热的数据，比如LadyGaGa发布一条消息，将会有千万的人收到这个消息，如何把LadyGaGa和普通的用户同等对待就很可能会把这个memcached节点搞垮，甚至访问冲向后面的数据库后会把数据搞垮，如下图所示：





因此就需要一些策略来控制这些热点数据和热点访问，这些策略细节是什么facebook没说太清楚，一般说来可以把热点数据分布到其他节点，另外对于数据库可以加锁控制流量，只有拿到锁的访问才能直接访问数据库，没拿到的需要等候和竞争。

另外一个数据分布的难题是每个用户可能会有成百上千的好友，而这些好友的数据分布在成百上千台的memcached的节点，这样一个客户端就需要连接成千上万的memcached的节点，如下图所示：





这种问题一般说来可以采取数据重组，把有关联的数据重组在一起，而不是分布在n台机器上。

以上的这些facebook的实践只能说是走马观花地看看了，从我们可以看到一个简简单单memcached也能完成这么多玩样来，可以猜想到facebook的那些天才工程师们在亿万数据压力下被逼出了多少创新的设计，这些设计不一定适用于我们，不了解情景也没办法深究里面的细节，我们要做的是围绕我们自己的应用，让memcached玩出点味道来。

分布式设计与开发（二）------几种必须了解的分布式算法
/article/1684711.html 其他分布式链接

分布式设计与开发中有些疑难问题必须借助一些算法才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）：

Paxos算法
一致性Hash算法

Paxos算法

1）问题描述

分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图：



当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。

2）算法本身

算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的Paxos Made Simple 是学习paxos最好的文档，它并没有像大多数算法文档那样搞一堆公式和数学符号在那里吓唬人，而是用人类语言让你搞清楚Paxos要解决什么问题，是如何解决的。这里也借机抨击一下那些学院派的研究者，要想让别人认可你的成果，首先要学会怎样让大多数人乐于阅读你的成果，而这个描述Paxos算法的文档就是我们学习的榜样。

言归正传，透过Paxos算法的各个步骤和约束，其实它就是一个分布式的选举算法，其目的就是要在一堆消息中通过选举，使得消息的接收者或者执行者能达成一致，按照一致的消息顺序来执行。其实，以最简单的想法来看，为了达到大伙执行相同序列的指令，完全可以通过串行来做，比如在分布式环境前加上一个FIFO队列来接收所有指令，然后所有服务节点按照队列里的顺序来执行。这个方法当然可以解决一致性问题，但它不符合分布式特性，如果这个队列down掉或是不堪重负这么办？而Paxos的高明之处就在于允许各个client互不影响地向服务端发指令，大伙按照选举的方式达成一致，这种方式具有分布式特性，容错性更好。

说到这个选举算法本身，可以联想一下现实社会中的选举，一般说来都是得票者最多者获胜，而Paxos算法是序列号更高者获胜，并且当尝试提交指令者被拒绝时（说明它的指令所占有的序列号不是最高），它会重新以一个更好的序列参与再次选举，通过各个提交者不断参与选举的方式，达到选出大伙公认的一个序列的目的。也正是因为有这个不断参与选举的过程，所以Paxos规定了三种角色（proposer，acceptor，和 learner）和两个阶段（accept和learn），三种角色的具体职责和两个阶段的具体过程就见Paxos
Made Simple ，另外一个国内的哥们写了个不错的PPT ，还通过动画描述了paxos运行的过程。不过还是那句话不要一开始就陷入算法的细节中，一定要多想想设计这些游戏规则的初衷是什么。

Paxos算法的最大优点在于它的限制比较少，它允许各个角色在各个阶段的失败和重复执行，这也是分布式环境下常有的事情，只要大伙按照规矩办事即可，算法的本身保障了在错误发生时仍然得到一致的结果。

3）算法的实现

Paxos的实现有很多版本，最有名的就是google chubby ，不过看不了源码。开源的实现可见libpaxos 。另外，ZooKeeper 也基于paxos解决数据一致性问题，也可以看看它是如果实现paxos的。

4）适用场景

弄清楚paxos的来龙去脉后，会发现它的适用场景非常多，Tim有篇blog《Paxos在大型系统中常见的应用场景》专门谈这个问题。我所见到的项目里，naming service是运用Paxos最广的领域，具体应用可参考ZooKeeper

一致性Hash算法

1）问题描述

分布式常常用Hash算法来分布数据，当数据节点不变化时是非常好的，但当数据节点有增加或减少时，由于需要调整Hash算法里的模，导致所有数据得重新按照新的模分布到各个节点中去。如果数据量庞大，这样的工作常常是很难完成的。一致性Hash算法是基于Hash算法的优化，通过一些映射规则解决以上问题

2）算法本身

对于一致性Hash算法本身我也不做完整的阐述，有篇blog《一致性hash算法 - consistent hashing》 描述这个算法非常到位，我就不重复造轮子了。

实际上，在其他设计和开发领域我们也可以借鉴一致性Hash的思路，当一个映射或规则导致有难以维护的问题时，可以考虑更一步抽象这些映射或规则，通过规则的变化使得最终数据的不变。一致性hash实际就是把以前点映射改为区段映射，使得数据节点变更后其他数据节点变动尽可能小。这个思路在操作系统对于存储问题上体现很多，比如操作系统为了更优化地利用存储空间，区分了段、页等不同纬度，加了很多映射规则，目的就是要通过灵活的规则避免物理变动的代价

3）算法实现

一致性Hash算法本身比较简单，不过可以根据实际情况有很多改进的版本，其目的无非是两点：

节点变动后其他节点受影响尽可能小
节点变动后数据重新分配尽可能均衡

实现这个算法就技术本身来说没多少难度和工作量，需要做的是建立起你所设计的映射关系，无需借助什么框架或工具，sourceforge上倒是有个项目libconhash ，可以参考一下

以上两个算法在我看来就算从不涉及算法的开发人员也需要了解的，算法其实就是一个策略，而在分布式环境常常需要我们设计一个策略来解决很多无法通过单纯的技术搞定的难题，学习这些算法可以提供我们一些思路。