分布式设计与开发（六）------让memcached分布式
转载自：http://blog.csdn.net/cutesource/article/details/5848253
?
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的源码如下：
?
其中非常重要的一点，当West的memcached要向East同步数据的时候，它没有采取memcached之间的同步，而是走MySQL replication，如下图所示：
这么做的原因我没法搞得太清楚，大概是比较信赖MySQL replication的简单稳定吧，并且像sns这种应用本身就不需要即时一致性，只要最终一致就行了。
另外在数据分布上是很有讲究的，facebook上面有很多很热的数据，比如LadyGaGa发布一条消息，将会有千万的人收到这个消息，如何把LadyGaGa和普通的用户同等对待就很可能会把这个memcached节点搞垮，甚至访问冲向后面的数据库后会把数据搞垮，如下图所示：
因此就需要一些策略来控制这些热点数据和热点访问，这些策略细节是什么facebook没说太清楚，一般说来可以把热点数据分布到其他节点，另外对于数据库可以加锁控制流量，只有拿到锁的访问才能直接访问数据库，没拿到的需要等候和竞争。
另外一个数据分布的难题是每个用户可能会有成百上千的好友，而这些好友的数据分布在成百上千台的memcached的节点，这样一个客户端就需要连接成千上万的memcached的节点，如下图所示：
这种问题一般说来可以采取数据重组，把有关联的数据重组在一起，而不是分布在n台机器上。
以上的这些facebook的实践只能说是走马观花地看看了，从我们可以看到一个简简单单memcached也能完成这么多玩样来，可以猜想到facebook的那些天才工程师们在亿万数据压力下被逼出了多少创新的设计，这些设计不一定适用于我们，不了解情景也没办法深究里面的细节，我们要做的是围绕我们自己的应用，让memcached玩出点味道来。
