Memcached分布式缓存问题

最新推荐文章于 2023-05-13 16:16:33 发布

置顶敲代码的黑米粥

最新推荐文章于 2023-05-13 16:16:33 发布

阅读量299

点赞数

文章标签：一致性哈希分布式缓存 Memcached

本文链接：https://blog.csdn.net/qq_38122278/article/details/91362809

版权

在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了Consistent Hashing 算法
Consistent Hashing 算法是分布式系统负载均衡的首选算法。
比如CRC32_HASH、FNV1_32_HASH、KETAMA_HASH等，其中KETAMA_HASH是默认的MemCache推荐的一致性Hash算法，
用别的Hash算法也可以，比如FNV1_32_HASH算法的计算效率就会高一些。
应用场景：
假设我们有一个网站，最近发现随着流量增加，服务器的压力越来越大，之前直接读写数据库的方式不太给力了，于是我们想
引入Memcached作为缓存机制。现在我们一共有三台机器可以作为Memcached服务器，如下图所示：
在这里插入图片描述
很显然，最简单的策略是将每一次Memcached请求随机发送到一台Memcached服务器，但是这种策略可能会带来两个问题：
1.同一份数据可能被存在不同的机器上而造成数据冗余；
2.有可能某数据已经被缓存但是访问却没有命中，因为无法保证对相同key的所有访问都被发送到相同的服务器。
要解决上述问题需要做到如下一点：
保证对相同key的访问会被发送到相同的服务器。
最常用的方法是计算哈希。例如对于每次访问，可以按照如下算法计算其哈希值：
h = Hash(key) % N
其中Hash是一个从字符串到正整数的哈希映射函数。这样如果我们将Memcached Server分别编号为0、1、2，那么就可以根据上式和key计算出服务器编号h。
这个算式虽然解决了上面提到的两个问题，但是还存在一些其他的问题，就是容错性和扩展性不好。
容错性是指系统中某一个或者几个服务器变得不可用时，整个系统是否可以正确高效的运行。
扩展性是指当加入新的服务器后，整个系统是否可以正确高效的运行。
现假设有一台服务器宕机了，那么为了填补空缺，要将服务器从编号列表中移除，后面的服务器按顺序前移一位并将其编号值减一，
此时每个key就要按照 h=Hash(key)%(N-1)重新计算；
同样，如果新增了一台服务器，虽然原有服务器编号不用改变，但是要按照h=Hash(key)%(N+1)重新计算哈希值。
因此系统中一旦有服务器变更，大量的key会被重定位到不同的服务器而造成大量的缓存不命中。
一致性哈希就是一种服务器节点的增减不会造成大量哈希重定位的解决方案。
一致性哈希算法（Consistent Hashing）
算法简述：
一致性哈希算法(Consistent Hashing Algorithm)是一种分布式算法，常用于负载均衡。Memcached client也选择这种算法，
解决将key-value均匀分配到众多Memcached server上的问题。它可以取代传统的取模操作，解决了取模操作无法应对增删Memcached Server的问题
(增删server会导致同一个key,在get操作时分配不到数据真正存储的server，命中率会急剧下降)。
简单来说，一致性哈希将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0 - (2^32)-1（即哈希值是一个32位无符号整形），整个哈希空间环如下：
在这里插入图片描述
下一步将各个服务器使用H进行一个哈希，具体可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，
这里假设将上文中三台服务器使用ip地址哈希后在环空间的位置如下：
在这里插入图片描述
接下来使用如下算法定位数据访问到相应服务器：将数据key使用相同的函数H计算出哈希值h，通根据h确定此数据在环上的位置，从此位置沿环顺时针“行走”，
第一台遇到的服务器就是其应该定位到的服务器。
例如我们有A、B、C、D四个数据对象，经过哈希计算后，在环空间上的位置如下：

在这里插入图片描述
根据一致性哈希算法，数据A会被定为到Server 1上，D被定为到Server 3上，而B、C分别被定为到Server 2上。
容错性与扩展性分析：
下面分析一致性哈希算法的容错性和可扩展性。现假设Server 3宕机了：

可以看到此时A、C、B不会受到影响，只有D节点被重定位到Server 2。一般的，在一致性哈希算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器
（即顺着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。
下面考虑另外一种情况，如果我们在系统中增加一台服务器Memcached Server 4：
在这里插入图片描述
此时A、D、C不受影响，只有B需要重定位到新的Server 4。一般的，在一致性哈希算法中，如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器
（即顺着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。
综上所述，一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。
虚拟节点：
一致性哈希算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题。例如我们的系统中有两台服务器，其环分布如下：
在这里插入图片描述
此时必然造成大量数据集中到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”的哈希值，于是形成六个虚拟节点：
在这里插入图片描述
下面附上两个版本的一致性哈希实现代码

一致性Hash算法实现版本1：不带虚拟节点

/**
*不带虚拟节点的Hash算法
*/
package com.zx.demo;
import java.util.Arrays;
import java.util.Set;
import java.util.SortedMap;
import java.util.TreeMap;
public class ConsistentHashing {
        /**
     * 待添加入Hash环的服务器列表
     */
        private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111",  "192.168.0.2:111",
         "192.168.0.3:111", "192.168.0.4:111"};
    
    /**
     * key表示服务器的hash值，value表示服务器的名称
     * SortedMap的主要特征是，它按照自然顺序或指定的比较器对键进行排序。
     */
    private static SortedMap<Integer, String> sortedMap =new TreeMap<Integer,  String>();
    
    /**
     * 程序初始化，将所有的服务器放入sortedMap中
     */
    static
    {
        for (int i = 0; i < servers.length; i++)
        {
            int hash = getHash(servers[i]);
            System.out.println("[" + servers[i] + "]加入集合中, 其Hash值为" + hash);
            sortedMap.put(hash, servers[i]);
        }
        System.out.println();
    }
    
    /**
     * 使用FNV1_32_HASH算法计算服务器的Hash值
     */
    private static int getHash(String str)
    {
        final int p = 16777619;
        int hash = (int)2166136261L;
        for (int i = 0; i < str.length(); i++)
            hash = (hash ^ str.charAt(i)) * p;
        hash += hash << 13;
        hash ^= hash >> 7;
        hash += hash << 3;
        hash ^= hash >> 17;
        hash += hash << 5;        
        // 如果算出来的值为负数则取其绝对值
        if (hash < 0)
            hash = Math.abs(hash);
        return hash;
    }
    
    /**
     * 得到应当路由到的结点
     */
    private static String getServer(String node)
    {
        // 得到带路由的结点的Hash值
        int hash = getHash(node);
        // 得到大于该Hash值的所有Map
        SortedMap<Integer, String> subMap =sortedMap.tailMap(hash);
        Integer i ;
        if(subMap.isEmpty()){
                //当node的Hash值比Map中最大的key还要大的时候，分配给最小的那台服务器
                Set<Integer> set = sortedMap.keySet();
                Object[] obj =set.toArray();
                Arrays.sort(obj);
                i=(Integer) obj[0];
                return sortedMap.get(i);
        }else{
                // 第一个Key就是顺时针过去离node最近的那个结点
             i = subMap.firstKey();
        }
       
        // 返回对应的服务器名称
        return subMap.get(i);
    }
    
    public static void main(String[] args)
    {
        String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"};
        for (int i = 0; i < nodes.length; i++)
            System.out.println("[" + nodes[i] + "]的hash值为" +
                    getHash(nodes[i]) + ", 被路由到结点[" + getServer(nodes[i]) +  "]");
    }
}

可以运行一下看一下结果：

[192.168.0.0:111]加入集合中, 其Hash值为575774686
[192.168.0.1:111]加入集合中, 其Hash值为8518713
[192.168.0.2:111]加入集合中, 其Hash值为1361847097
[192.168.0.3:111]加入集合中, 其Hash值为1171828661
[192.168.0.4:111]加入集合中, 其Hash值为1764547046

[127.0.0.1:1111]的hash值为380278925, 被路由到结点[192.168.0.0:111]
[221.226.0.1:2222]的hash值为1493545632, 被路由到结点[192.168.0.4:111]
[10.211.0.1:3333]的hash值为1393836017, 被路由到结点[192.168.0.4:111]

看到经过FNV1_32_HASH算法重新计算过后的Hash值，就比原来String的hashCode()方法好多了。从运行结果来看，也没有问题，三个点路由到的都是顺时针离他们Hash值最近的那台服务器上。
一致性Hash算法实现版本2：带虚拟节点
使用虚拟节点来改善一致性Hash算法
上面的一致性Hash算法实现，可以在很大程度上解决很多分布式环境下不好的路由算法导致系统伸缩性差的问题，但是会带来另外一个问题：负载不均。
比如说有Hash环上有A、B、C三个服务器节点，分别有100个请求会被路由到相应服务器上。现在在A与B之间增加了一个节点D，这导致了原来会路由到B上的部分节点被路由到了D上，这样A、C上被路由到的请求明显多于B、D上的，原来三个服务器节点上均衡的负载被打破了。某种程度上来说，这失去了负载均衡的意义，因为负载均衡的目的本身就是为了使得目标服务器均分所有的请求。
解决这个问题的办法是引入虚拟节点，其工作原理是：将一个物理节点拆分为多个虚拟节点，并且同一个物理节点的虚拟节点尽量均匀分布在Hash环上。采取这样的方式，就可以有效地解决增加或减少节点时候的负载不均衡的问题。
至于一个物理节点应该拆分为多少虚拟节点，下面可以先看一张图：
在这里插入图片描述
横轴表示需要为每台福利服务器扩展的虚拟节点倍数，纵轴表示的是实际物理服务器数。可以看出，物理服务器很少，需要更大的虚拟节点；反之物理服务器比较多，虚拟节点就可以少一些。比如有10台物理服务器，那么差不多需要为每台服务器增加100~200个虚拟节点才可以达到真正的负载均衡。
在理解了使用虚拟节点来改善一致性Hash算法的理论基础之后，就可以尝试开发代码了。编程方面需要考虑的问题是：
1、一个真实结点如何对应成为多个虚拟节点？
2、虚拟节点找到后如何还原为真实结点？
这两个问题其实有很多解决办法，我这里使用了一种简单的办法，给每个真实结点后面根据虚拟节点加上后缀再取Hash值，比如"192.168.0.0:111"就把它变成"192.168.0.0:111&&VN0"到"192.168.0.0:111&&VN4"，VN就是Virtual Node的缩写，还原的时候只需要从头截取字符串到"&&"的位置就可以了。
下面来看一下带虚拟节点的一致性Hash算法的Java代码实现：

/**
* 带虚拟节点的一致性Hash算法
* 
*/
package com.zx.demo;
import java.util.Arrays;
import java.util.LinkedList;
import java.util.List;
import java.util.Set;
import java.util.SortedMap;
import java.util.TreeMap;
public class ConsistentHashingWithVirtualNode {
        /**
     * 待添加入Hash环的服务器列表
     */
    private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111",  "192.168.0.2:111",
            "192.168.0.3:111", "192.168.0.4:111"};
    
    /**
     * 真实结点列表,考虑到服务器上线、下线的场景，即添加、删除的场景会比较频繁，这里使用LinkedList会更好
     */
    private static List<String> realNodes = new LinkedList<String>();
    
    /**
     * 虚拟节点，key表示虚拟节点的hash值，value表示虚拟节点的名称
     */
    private static SortedMap<Integer, String> virtualNodes =new TreeMap<Integer,  String>();
    
    /**
     * 虚拟节点的数目，这里写死，为了演示需要，一个真实结点对应5个虚拟节点
     */
    private static final int VIRTUAL_NODES = 5;
    
    static
    {
        // 先把原始的服务器添加到真实结点列表中
        for (int i = 0; i < servers.length; i++)
            realNodes.add(servers[i]);
        
        // 再添加虚拟节点，遍历LinkedList使用foreach循环效率会比较高
        for (String str : realNodes)
        {
            for (int i = 0; i < VIRTUAL_NODES; i++)
            {
                String virtualNodeName = str + "&&VN" + String.valueOf(i);
                int hash = getHash(virtualNodeName);
                System.out.println("虚拟节点[" + virtualNodeName + "]被添加, hash值为" + hash);
                virtualNodes.put(hash, virtualNodeName);
            }
        }
        System.out.println();
    }
    
    /**
     * 使用FNV1_32_HASH算法计算服务器的Hash值,这里不使用重写hashCode的方法，最终效果没区别
     */
    private static int getHash(String str)
    {
        final int p = 16777619;
        int hash = (int)2166136261L;
        for (int i = 0; i < str.length(); i++)
            hash = (hash ^ str.charAt(i)) * p;
        hash += hash << 13;
        hash ^= hash >> 7;
        hash += hash << 3;
        hash ^= hash >> 17;
        hash += hash << 5;
        
        // 如果算出来的值为负数则取其绝对值
        if (hash < 0)
            hash = Math.abs(hash);
        return hash;
    }
    
    /**
     * 得到应当路由到的结点
     */
    private static String getServer(String node)
    {
        // 得到带路由的结点的Hash值
        int hash = getHash(node);
        Integer i ;
        // 得到大于该Hash值的所有Map
        SortedMap<Integer, String> subMap = virtualNodes.tailMap(hash);
        if(subMap.isEmpty()){
         //当node的Hash值比Map中最大的key还要大的时候，分配给最小的那台服务器
         Set<Integer> set = virtualNodes.keySet();
         Object[] obj =set.toArray();
         Arrays.sort(obj);
         i=(Integer) obj[0];
         String virtualNode = virtualNodes.get(i);
         return virtualNode.substring(0, virtualNode.indexOf("&&"));
       }else{
          // 第一个Key就是顺时针过去离node最近的那个结点
            i = subMap.firstKey();
           // 返回对应的虚拟节点名称，这里字符串稍微截取一下
           String virtualNode = subMap.get(i);
           return virtualNode.substring(0, virtualNode.indexOf("&&"));
       }
       
       
    }
    
    public static void main(String[] args)
    {
        String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"};
        for (int i = 0; i < nodes.length; i++)
            System.out.println("[" + nodes[i] + "]的hash值为" +
                    getHash(nodes[i]) + ", 被路由到结点[" + getServer(nodes[i]) +  "]");
    }
}

看一下运行结果：

虚拟节点[192.168.0.0:111&&VN0]被添加, hash值为1686427075
虚拟节点[192.168.0.0:111&&VN1]被添加, hash值为354859081
虚拟节点[192.168.0.0:111&&VN2]被添加, hash值为1306497370
虚拟节点[192.168.0.0:111&&VN3]被添加, hash值为817889914
虚拟节点[192.168.0.0:111&&VN4]被添加, hash值为396663629
虚拟节点[192.168.0.1:111&&VN0]被添加, hash值为1032739288
虚拟节点[192.168.0.1:111&&VN1]被添加, hash值为707592309
虚拟节点[192.168.0.1:111&&VN2]被添加, hash值为302114528
虚拟节点[192.168.0.1:111&&VN3]被添加, hash值为36526861
虚拟节点[192.168.0.1:111&&VN4]被添加, hash值为848442551
虚拟节点[192.168.0.2:111&&VN0]被添加, hash值为1452694222
虚拟节点[192.168.0.2:111&&VN1]被添加, hash值为2023612840
虚拟节点[192.168.0.2:111&&VN2]被添加, hash值为697907480
虚拟节点[192.168.0.2:111&&VN3]被添加, hash值为790847074
虚拟节点[192.168.0.2:111&&VN4]被添加, hash值为2010506136
虚拟节点[192.168.0.3:111&&VN0]被添加, hash值为891084251
虚拟节点[192.168.0.3:111&&VN1]被添加, hash值为1725031739
虚拟节点[192.168.0.3:111&&VN2]被添加, hash值为1127720370
虚拟节点[192.168.0.3:111&&VN3]被添加, hash值为676720500
虚拟节点[192.168.0.3:111&&VN4]被添加, hash值为2050578780
虚拟节点[192.168.0.4:111&&VN0]被添加, hash值为586921010
虚拟节点[192.168.0.4:111&&VN1]被添加, hash值为184078390
虚拟节点[192.168.0.4:111&&VN2]被添加, hash值为1331645117
虚拟节点[192.168.0.4:111&&VN3]被添加, hash值为918790803
虚拟节点[192.168.0.4:111&&VN4]被添加, hash值为1232193678

[127.0.0.1:1111]的hash值为380278925, 被路由到结点[192.168.0.0:111]
[221.226.0.1:2222]的hash值为1493545632, 被路由到结点[192.168.0.0:111]
[10.211.0.1:3333]的hash值为1393836017, 被路由到结点[192.168.0.2:111]

从代码运行结果看，每个点路由到的服务器都是Hash值顺时针离它最近的那个服务器节点，没有任何问题。
通过采取虚拟节点的方法，一个真实结点不再固定在Hash换上的某个点，而是大量地分布在整个Hash环上，这样即使上线、下线服务器，也不会造成整体的负载不均衡。
Consistent Hashing最大限度地抑制了hash键的重新分布。另外要取得比较好的负载均衡的效果，往往在服务器数量比较少的时候需要增加虚拟节点来保证服务器能均匀的分布在圆环上。因为使用一般的hash方法，服务器的映射地点的分布非常不均匀。使用虚拟节点的思想，为每个物理节点（服务器）在圆上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小服务器增减时的缓存重新分布。用户数据映射在虚拟节点上，就表示用户数据真正存储位置是在该虚拟节点代表的实际物理服务器上。

敲代码的黑米粥

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Memcached分布式缓存问题

在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了Consistent Hashing 算法Consistent Hashing 算法是分布式系统负载均衡的首选算法。比如CRC32_HASH、FNV1_32_HASH、KETAMA_HASH等，其中KETAMA_HASH是默认的MemCache推荐的一致性Hash算法，用别的Hash算法也可以...
复制链接

扫一扫