memcache分布式部署的原理分析
今天在封装memcache操作类库过程中，意识到一直以来对memcache的使用都是局限在单台服务器的情况下，还没有使用到memcache的分布式部署。虽然知道memcache的分布式是怎么回事，但是为了更加深入的理解，还是通过谷歌搜索了这方面的相关资料。
下面是精摘于网络的一些关于 memcache分布式部署 的资料。
memcache分布式部署是什么呢？下面通过一个例子来认识一下：
假设memcached服务器有node1～node3三台， 应用程序要保存键名为“tokyo”“kanagawa”“chiba”“saitama”“gunma” 的数据。
首先向memcached中添加“tokyo”。将“tokyo”传给客户端程序库后， 客户端实现的算法就会根据“键”来决定保存数据的memcached服务器。 服务器选定后，即命令它保存“tokyo”及其值。
同样，“kanagawa”“chiba”“saitama”“gunma”都是先选择服务器再保存。
接下来获取保存的数据。获取时也要将要获取的键“tokyo”传递给函数库。 函数库通过与数据保存时相同的算法，根据“键”选择服务器。 使用的算法相同，就能选中与保存时相同的服务器，然后发送get命令。 只要数据没有因为某些原因被删除，就能获得保存的值。
这样，将不同的键保存到不同的服务器上，就实现了memcached的分布式。 memcached服务器增多后，键就会分散，即使一台memcached服务器发生故障无法连接，也不会影响其他的缓存，系统依然能继续运行。
下面我们具体介绍一下 Consistent hashing算法：
Consistent Hashing的简单说明
首先求出memcached服务器（节点）的哈希值， 并将其配置到0～2SUP(32)的圆（continuum）上。 然后用同样的方法求出存储数据的键的哈希值，并映射到圆上。 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。 如果超过2SUP(32)仍然找不到服务器，就会保存到第一台memcached服务器上。
从上图的状态中添加一台memcached服务器。余数分布式算法由于保存键的服务器会发生巨大变化 而影响缓存的命中率，但Consistent Hashing中，只有在continuum上增加服务器的地点逆时针方向的 第一台服务器上的键会受到影响。
因此，Consistent Hashing最大限度地抑制了键的重新分布。 而且，有的Consistent Hashing的实现方法还采用了虚拟节点的思想。 使用一般的hash函数的话，服务器的映射地点的分布非常不均匀。 因此，使用虚拟节点的思想，为每个物理节点（服务器） 在continuum上分配100～200个点。这样就能抑制分布不均匀， 最大限度地减小服务器增减时的缓存重新分布。
下面再介绍一下虚拟节点
Consistent hashing算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题。例如我们的系统中有两台 server，其环分布如下：
此时必然造成大量数据集中到Server 1上，而只有极少量会定位到Server 2上。为了解决这种数据倾斜问题，一致性哈希算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。
具体做法可以在服务器ip或主机名的后面增加编号来实现。例如上面的情况，我们决定为每台服务器计算三个虚拟节点，于是可以分别计算“Memcached Server 1#1”、“Memcached Server 1#2”、“Memcached Server 1#3”、“Memcached Server 2#1”、“Memcached Server 2#2”、“Memcached Server 2#3”的哈希值，于是形成六个虚拟节点：
同时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射，例如定位到“Memcached Server 1#1”、“Memcached Server 1#2”、“Memcached Server 1#3”三个虚拟节点的数据均定位到Server 1上。这样就解决了服务节点少时数据倾斜的问题。在实际应用中，通常将虚拟节点数设置为32甚至更大，因此即使很少的服务节点也能做到相对均匀的数据分布，避免出现雪崩的情况。
例子
启动Memcache服务，比如这样
| 代码如下 | 复制代码 |
/usr/local/bin/memcached -d -p 11213 -u root -m 10 -c 1024 -t 8 -P /tmp/memcached.pid /usr/local/bin/memcached -d -p 11214 -u root -m 10 -c 1024 -t 8 -P /tmp/memcached.pid /usr/local/bin/memcached -d -p 11215 -u root -m 10 -c 1024 -t 8 -P /tmp/memcached.pid |
|
启动三个只使用10M内存以方便测试。
分布式部署
PHP的PECL扩展中的memcache实际上在2.0.0的版本中就已经实现多服务器支持，现在都已经2.2.5了。请看如下代码
| 代码如下 | 复制代码 |
$memcache = new Memcache; $memcache->addServer('localhost', 11213); $memcache->addServer('localhost', 11214); $memcache->addServer('localhost', 11215); $memStats = $memcache->getExtendedStats(); print_r($memStats); |
|
通过上例就已经实现Memcache的分布式部署，是不是非常简单。
分布式系统的良性运行
在Memcache的实际使用中，遇到的最严重的问题，就是在增减服务器的时候，会导致大范围的缓存丢失，从而可能会引导数据库的性能瓶颈，为了避免出现这种情况，请先看Consistent hashing算法，中文的介绍可以参考这里，通过存取时选定服务器算法的改变，来实现。
修改PHP的Memcache扩展memcache.c的源代码中的
| 代码如下 | 复制代码 |
"memcache.hash_strategy" = standard |
|
为
| 代码如下 | 复制代码 |
| "memcache.hash_strategy" = consistent | |
重新编译，这时候就是使用Consistent hashing算法来寻找服务器存取数据了。
有效测试数据表明，使用Consistent hashing可以极大的改善增删Memcache时缓存大范围丢失的情况。
| 代码如下 | 复制代码 |
| NonConsistentHash: 92% of lookups changed after adding a target to the existing 10 NonConsistentHash: 90% of lookups changed after removing 1 of 10 targets ConsistentHash: 6% of lookups changed after adding a target to the existing 10 ConsistentHash: 9% of lookups changed after removing 1 of 10 targets |
|
总结：
在动态分布式缓存系统里哈希算法承担着系统架构上的关键点。 使用分布更合理的算法可以使得多个服务节点间的负载相对均衡，可以最大程度的避免资源的浪费以及服务器过载。 使用一致性哈希算法，可以最大程度的降低服务硬件环境变化带来的数据迁移代价和风险。 使用更合理的配置策略和算法可以使分布式缓存系统更加高效稳定。
