面试必问的一致性Hash在负载均衡中的应用

绝地灬酷狼 2022-12-10 14:51 85阅读 0赞

点击上方“java大数据修炼之道”，选择“设为星标”

# 优质文章和精品资源, 第一时间送达 #

###  ###

![format_png][]

![format_png 1][]

来源：http://marklux.cn/blog/90

**好文推荐：**[老板要求用java将word转为PDF，这么搞？][java_word_PDF]

**简介**

一致性Hash是一种特殊的Hash算法，由于其均衡性、持久性的映射特点，被广泛的应用于负载均衡领域，如nginx和memcached都采用了一致性Hash来作为集群负载均衡的方案。

本文将介绍一致性Hash的基本思路，并讨论其在分布式缓存集群负载均衡中的应用。同时也会进行相应的代码测试来验证其算法特性，并给出和其他负载均衡方案的一些对比。

## **一致性Hash算法简介** ##

在了解一致性Hash算法之前，先来讨论一下Hash本身的特点。普通的Hash函数最大的作用是散列，或者说是将一系列在形式上具有相似性质的数据，打散成随机的、均匀分布的数据。

比如，对字符串abc和abcd分别进行md5计算，得到的结果如下：

![format_png 2][]

可以看到，两个在形式上非常相近的数据经过md5散列后，变成了完全随机的字符串。负载均衡正是利用这一特性，对于大量随机的请求或调用，通过一定形式的Hash将他们均匀的散列，从而实现压力的平均化。（当然，并不是只要使用了Hash就一定能够获得均匀的散列，后面会分析这一点。）

举个例子，如果我们给每个请求生成一个Key，只要使用一个非常简单的Hash算法`Group = Key % N`来实现请求的负载均衡，如下：

![format_png 3][]

（如果将Key作为缓存的Key，对应的Group储存该Key的Value，就可以实现一个分布式的缓存系统，后文的具体例子都将基于这个场景）

不难发现，这样的Hash只要集群的数量N发生变化，之前的所有Hash映射就会全部失效。如果集群中的每个机器提供的服务没有差别，倒不会产生什么影响，但对于分布式缓存这样的系统而言，映射全部失效就意味着之前的缓存全部失效，后果将会是灾难性的。

一致性Hash通过构建环状的Hash空间代替线性Hash空间的方法解决了这个问题，如下图：

![format_png 4][]

整个Hash空间被构建成一个首尾相接的环，使用一致性Hash时需要进行两次映射。

第一次，给每个节点（集群）计算Hash，然后记录它们的Hash值，这就是它们在环上的位置。

第二次，给每个Key计算Hash，然后沿着顺时针的方向找到环上的第一个节点，就是该Key储存对应的集群。

分析一下节点增加和删除时对负载均衡的影响，如下图：

![format_png 5][]

可以看到，当节点被删除时，其余节点在环上的映射不会发生改变，只是原来打在对应节点上的Key现在会转移到顺时针方向的下一个节点上去。增加一个节点也是同样的，最终都只有少部分的Key发生了失效。不过发生节点变动后，整体系统的压力已经不是均衡的了，下文中提到的方法将会解决这个问题。

## **问题与优化** ##

最基本的一致性Hash算法直接应用于负载均衡系统，效果仍然是不理想的，存在诸多问题，下面就对这些问题进行逐个分析并寻求更好的解决方案。

### **数据倾斜** ###

如果节点的数量很少，而hash环空间很大（一般是 0 ~ 2^32），直接进行一致性hash上去，大部分情况下节点在环上的位置会很不均匀，挤在某个很小的区域。最终对分布式缓存造成的影响就是，集群的每个实例上储存的缓存数据量不一致，会发生严重的数据倾斜。

### **缓存雪崩** ###

如果每个节点在环上只有一个节点，那么可以想象，当某一集群从环中消失时，它原本所负责的任务将全部交由顺时针方向的下一个集群处理。例如，当group0退出时，它原本所负责的缓存将全部交给group1处理。这就意味着group1的访问压力会瞬间增大。设想一下，如果group1因为压力过大而崩溃，那么更大的压力又会向group2压过去，最终服务压力就像滚雪球一样越滚越大，最终导致雪崩。

### **引入虚拟节点** ###

解决上述两个问题最好的办法就是扩展整个环上的节点数量，因此我们引入了虚拟节点的概念。一个实际节点将会映射多个虚拟节点，这样Hash环上的空间分割就会变得均匀。

同时，引入虚拟节点还会使得节点在Hash环上的顺序随机化，这意味着当一个真实节点失效退出后，它原来所承载的压力将会均匀地分散到其他节点上去。

如下图：

![format_png 6][]

## **代码测试** ##

现在我们尝试编写一些测试代码，来看看一致性hash的实际效果是否符合我们预期。

首先我们需要一个能够对输入进行均匀散列的Hash算法，可供选择的有很多，memcached官方使用了基于md5的KETAMA算法，但这里处于计算效率的考虑，使用了FNV1\_32\_HASH算法，如下：

public class HashUtil {
        /**
         * 计算Hash值, 使用FNV1_32_HASH算法
         * @param str
         * @return
         */
        public 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;
        }
    }

实际使用时可以根据需求调整。

接着需要使用一种数据结构来保存hash环，可以采用的方案有很多种，最简单的是采用数组或链表。但这样查找的时候需要进行排序，如果节点数量多，速度就可能变得很慢。

针对集群负载均衡状态读多写少的状态，很容易联想到使用二叉平衡树的结构去储存，实际上可以使用TreeMap（内部实现是红黑树）来作为Hash环的储存结构。

先编写一个最简单的，无虚拟节点的Hash环测试：

public class ConsistentHashingWithoutVirtualNode {
    
        /**
         * 集群地址列表
         */
        private static String[] groups = {
            "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"
        };
    
        /**
         * 用于保存Hash环上的节点
         */
        private static SortedMap<Integer, String> sortedMap = new TreeMap<>();
    
        /**
         * 初始化，将所有的服务器加入Hash环中
         */
        static {
            // 使用红黑树实现，插入效率比较差，但是查找效率极高
            for (String group : groups) {
                int hash = HashUtil.getHash(group);
                System.out.println("[" + group + "] launched @ " + hash);
                sortedMap.put(hash, group);
            }
        }
    
        /**
         * 计算对应的widget加载在哪个group上
         *
         * @param widgetKey
         * @return
         */
        private static String getServer(String widgetKey) {
            int hash = HashUtil.getHash(widgetKey);
            // 只取出所有大于该hash值的部分而不必遍历整个Tree
            SortedMap<Integer, String> subMap = sortedMap.tailMap(hash);
            if (subMap == null || subMap.isEmpty()) {
                // hash值在最尾部，应该映射到第一个group上
                return sortedMap.get(sortedMap.firstKey());
            }
            return subMap.get(subMap.firstKey());
        }
    
        public static void main(String[] args) {
            // 生成随机数进行测试
            Map<String, Integer> resMap = new HashMap<>();
    
            for (int i = 0; i < 100000; i++) {
                Integer widgetId = (int)(Math.random() * 10000);
                String server = getServer(widgetId.toString());
                if (resMap.containsKey(server)) {
                    resMap.put(server, resMap.get(server) + 1);
                } else {
                    resMap.put(server, 1);
                }
            }
    
            resMap.forEach(
                (k, v) -> {
                    System.out.println("group " + k + ": " + v + "(" + v/1000.0D +"%)");
                }
            );
        }
    }

生成10000个随机数字进行测试，最终得到的压力分布情况如下：

[192.168.0.1:111] launched @ 8518713
    [192.168.0.2:111] launched @ 1361847097
    [192.168.0.3:111] launched @ 1171828661
    [192.168.0.4:111] launched @ 1764547046
    group 192.168.0.2:111: 8572(8.572%)
    group 192.168.0.1:111: 18693(18.693%)
    group 192.168.0.4:111: 17764(17.764%)
    group 192.168.0.3:111: 27870(27.87%)
    group 192.168.0.0:111: 27101(27.101%)

可以看到压力还是比较不平均的，所以我们继续，引入虚拟节点：

public class ConsistentHashingWithVirtualNode {
        /**
         * 集群地址列表
         */
        private static String[] groups = {
            "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"
        };
    
        /**
         * 真实集群列表
         */
        private static List<String> realGroups = new LinkedList<>();
    
        /**
         * 虚拟节点映射关系
         */
        private static SortedMap<Integer, String> virtualNodes = new TreeMap<>();
    
        private static final int VIRTUAL_NODE_NUM = 1000;
    
        static {
            // 先添加真实节点列表
            realGroups.addAll(Arrays.asList(groups));
    
            // 将虚拟节点映射到Hash环上
            for (String realGroup: realGroups) {
                for (int i = 0; i < VIRTUAL_NODE_NUM; i++) {
                    String virtualNodeName = getVirtualNodeName(realGroup, i);
                    int hash = HashUtil.getHash(virtualNodeName);
                    System.out.println("[" + virtualNodeName + "] launched @ " + hash);
                    virtualNodes.put(hash, virtualNodeName);
                }
            }
        }
    
        private static String getVirtualNodeName(String realName, int num) {
            return realName + "&&VN" + String.valueOf(num);
        }
    
        private static String getRealNodeName(String virtualName) {
            return virtualName.split("&&")[0];
        }
    
        private static String getServer(String widgetKey) {
            int hash = HashUtil.getHash(widgetKey);
            // 只取出所有大于该hash值的部分而不必遍历整个Tree
            SortedMap<Integer, String> subMap = virtualNodes.tailMap(hash);
            String virtualNodeName;
            if (subMap == null || subMap.isEmpty()) {
                // hash值在最尾部，应该映射到第一个group上
                virtualNodeName = virtualNodes.get(virtualNodes.firstKey());
            }else {
                virtualNodeName = subMap.get(subMap.firstKey());
            }
            return getRealNodeName(virtualNodeName);
        }
    
        public static void main(String[] args) {
            // 生成随机数进行测试
            Map<String, Integer> resMap = new HashMap<>();
    
            for (int i = 0; i < 100000; i++) {
                Integer widgetId = i;
                String group = getServer(widgetId.toString());
                if (resMap.containsKey(group)) {
                    resMap.put(group, resMap.get(group) + 1);
                } else {
                    resMap.put(group, 1);
                }
            }
    
            resMap.forEach(
                (k, v) -> {
                    System.out.println("group " + k + ": " + v + "(" + v/100000.0D +"%)");
                }
            );
        }
    }

这里真实节点和虚拟节点的映射采用了字符串拼接的方式，这种方式虽然简单但很有效，memcached官方也是这么实现的。将虚拟节点的数量设置为1000，重新测试压力分布情况，结果如下：

group 192.168.0.2:111: 18354(18.354%)
    group 192.168.0.1:111: 20062(20.062%)
    group 192.168.0.4:111: 20749(20.749%)
    group 192.168.0.3:111: 20116(20.116%)
    group 192.168.0.0:111: 20719(20.719%)

可以看到基本已经达到平均分布了，接着继续测试删除和增加节点给整个服务带来的影响，相关测试代码如下：

private static void refreshHashCircle() {
        // 当集群变动时，刷新hash环，其余的集群在hash环上的位置不会发生变动
        virtualNodes.clear();
        for (String realGroup: realGroups) {
            for (int i = 0; i < VIRTUAL_NODE_NUM; i++) {
                   String virtualNodeName = getVirtualNodeName(realGroup, i);
                int hash = HashUtil.getHash(virtualNodeName);
                System.out.println("[" + virtualNodeName + "] launched @ " + hash);
                virtualNodes.put(hash, virtualNodeName);
            }
        }
    }
    private static void addGroup(String identifier) {
        realGroups.add(identifier);
        refreshHashCircle();
    }
    
    private static void removeGroup(String identifier) {
        int i = 0;
        for (String group:realGroups) {
            if (group.equals(identifier)) {
                realGroups.remove(i);
            }
            i++;
        }
        refreshHashCircle();
    }

测试删除一个集群前后的压力分布如下：

running the normal test.
    group 192.168.0.2:111: 19144(19.144%)
    group 192.168.0.1:111: 20244(20.244%)
    group 192.168.0.4:111: 20923(20.923%)
    group 192.168.0.3:111: 19811(19.811%)
    group 192.168.0.0:111: 19878(19.878%)
    removed a group, run test again.
    group 192.168.0.2:111: 23409(23.409%)
    group 192.168.0.1:111: 25628(25.628%)
    group 192.168.0.4:111: 25583(25.583%)
    group 192.168.0.0:111: 25380(25.38%)

同时计算一下消失的集群上的Key最终如何转移到其他集群上：

[192.168.0.1:111-192.168.0.4:111] :5255
    [192.168.0.1:111-192.168.0.3:111] :5090
    [192.168.0.1:111-192.168.0.2:111] :5069
    [192.168.0.1:111-192.168.0.0:111] :4938

可见，删除集群后，该集群上的压力均匀地分散给了其他集群，最终整个集群仍处于负载均衡状态，符合我们的预期，最后看一下添加集群的情况。

压力分布：

running the normal test.
    group 192.168.0.2:111: 18890(18.89%)
    group 192.168.0.1:111: 20293(20.293%)
    group 192.168.0.4:111: 21000(21.0%)
    group 192.168.0.3:111: 19816(19.816%)
    group 192.168.0.0:111: 20001(20.001%)
    add a group, run test again.
    group 192.168.0.2:111: 15524(15.524%)
    group 192.168.0.7:111: 16928(16.928%)
    group 192.168.0.1:111: 16888(16.888%)
    group 192.168.0.4:111: 16965(16.965%)
    group 192.168.0.3:111: 16768(16.768%)
    group 192.168.0.0:111: 16927(16.927%)

压力转移：

[192.168.0.0:111-192.168.0.7:111] :3102
    [192.168.0.4:111-192.168.0.7:111] :4060
    [192.168.0.2:111-192.168.0.7:111] :3313
    [192.168.0.1:111-192.168.0.7:111] :3292
    [192.168.0.3:111-192.168.0.7:111] :3261

综上可以得出结论，在引入足够多的虚拟节点后，一致性hash还是能够比较完美地满足负载均衡需要的。

扩展一下：

[带你从头进行RabbitMQ安装、集群搭建、镜像队列配置和代码验证][RabbitMQ]

[分布式与集群的区别究竟是什么？][Link 1]

[这次一定要教会你搭建Redis集群和MySQL主从同步(非Docker)][Redis_MySQL_Docker]

## **优雅缩扩容** ##

缓存服务器对于性能有着较高的要求，因此我们希望在扩容时新的集群能够较快的填充好数据并工作。但是从一个集群启动，到真正加入并可以提供服务之间还存在着不小的时间延迟，要实现更优雅的扩容，我们可以从两个方面出发：

### **1.高频Key预热** ###

负载均衡器作为路由层，是可以收集并统计每个缓存Key的访问频率的，如果能够维护一份高频访问Key的列表，新的集群在启动时根据这个列表提前拉取对应Key的缓存值进行预热，便可以大大减少因为新增集群而导致的Key失效。

具体的设计可以通过缓存来实现，如下：

![format_png 7][]

不过这个方案在实际使用时有一个很大的限制，那就是高频Key本身的缓存失效时间可能很短，预热时储存的Value在实际被访问到时可能已经被更新或者失效，处理不当会导致出现脏数据，因此实现难度还是有一些大的。

### **2.历史Hash环保留** ###

回顾一致性Hash的扩容，不难发现新增节点后，它所对应的Key在原来的节点还会保留一段时间。因此在扩容的延迟时间段，如果对应的Key缓存在新节点上还没有被加载，可以去原有的节点上尝试读取。

举例，假设我们原有3个集群，现在要扩展到6个集群，这就意味着原有50%的Key都会失效（被转移到新节点上），如果我们维护扩容前和扩容后的两个Hash环，在扩容后的Hash环上找不到Key的储存时，先转向扩容前的Hash环寻找一波，如果能够找到就返回对应的值并将该缓存写入新的节点上，找不到时再透过缓存，如下图：

![format_png 8][]

这样做的缺点是增加了缓存读取的时间，但相比于直接击穿缓存而言还是要好很多的。优点则是可以随意扩容多台机器，而不会产生大面积的缓存失效。

谈完了扩容，再谈谈缩容。

### **1.熔断机制** ###

缩容后，剩余各个节点上的访问压力都会有所增加，此时如果某个节点因为压力过大而宕机，就可能会引发连锁反应。因此作为兜底方案，应当给每个集群设立对应熔断机制来保护服务的稳定性。

### **2.多集群LB的更新延迟** ###

这个问题在缩容时比较严重，如果你使用一个集群来作为负载均衡，并使用一个配置服务器比如ConfigServer来推送集群状态以构建Hash环，那么在某个集群退出时这个状态并不一定会被立刻同步到所有的LB上，这就可能会导致一个暂时的调度不一致，如下图：

![format_png 9][]

如果某台LB错误地将请求打到了已经退出的集群上，就会导致缓存击穿。解决这个问题主要有以下几种思路：

*  缓慢缩容，等到Hash环完全同步后再操作。可以通过监听退出集群的访问QPS来实现这一点，等到该集群几乎没有QPS时再将其撤下。
 *  手动删除，如果Hash环上对应的节点找不到了，就手动将其从Hash环上删除，然后重新进行调度，这个方式有一定的风险，对于网络抖动等异常情况兼容的不是很好。
 *  主动拉取和重试，当Hash环上节点失效时，主动从ZK上重新拉取集群状态来构建新Hash环，在一定次数内可以进行多次重试。

## **对比：HashSlot** ##

了解了一致性Hash算法的特点后，我们也不难发现一些不尽人意的地方：

*  整个分布式缓存需要一个路由服务来做负载均衡，存在单点问题（如果路由服务挂了，整个缓存也就凉了）
 *  Hash环上的节点非常多或者更新频繁时，查找性能会比较低下
 *  针对这些问题，Redis在实现自己的分布式集群方案时，设计了全新的思路：基于P2P结构的HashSlot算法，下面简单介绍一下：

### **1.使用HashSlot** ###

类似于Hash环，Redis Cluster采用HashSlot来实现Key值的均匀分布和实例的增删管理。

首先默认分配了16384个Slot（这个大小正好可以使用2kb的空间保存），每个Slot相当于一致性Hash环上的一个节点。接入集群的所有实例将均匀地占有这些Slot，而最终当我们Set一个Key时，使用`CRC16(Key) % 16384`来计算出这个Key属于哪个Slot，并最终映射到对应的实例上去。

那么当增删实例时，Slot和实例间的对应要如何进行对应的改动呢？

举个例子，原本有3个节点A,B,C，那么一开始创建集群时Slot的覆盖情况是：

节点A    0－5460
     节点B    5461－10922
     节点C    10923－16383

现在假设要增加一个节点D，RedisCluster的做法是将之前每台机器上的一部分Slot移动到D上（注意这个过程也意味着要对节点D写入的KV储存），成功接入后Slot的覆盖情况将变为如下情况：

节点A    1365-5460
     节点B    6827-10922
     节点C    12288-16383
     节点D    0-1364,5461-6826,10923-12287

同理删除一个节点，就是将其原来占有的Slot以及对应的KV储存均匀地归还给其他节点。

### **2.P2P节点寻找** ###

现在我们考虑如何实现去中心化的访问，也就是说无论访问集群中的哪个节点，你都能够拿到想要的数据。其实这有点类似于路由器的路由表，具体说来就是：

*  每个节点都保存有完整的HashSlot - 节点映射表，也就是说，每个节点都知道自己拥有哪些Slot，以及某个确定的Slot究竟对应着哪个节点。
 *  无论向哪个节点发出寻找Key的请求，该节点都会通过CRC(Key) % 16384计算该Key究竟存在于哪个Slot，并将请求转发至该Slot所在的节点。

总结一下就是两个要点：映射表和内部转发，这是通过著名的**Gossip协议**来实现的。

最后我们可以给出Redis Cluster的系统结构图，和一致性Hash环还是有着很明显的区别的：

![format_png 10][]

对比一下，HashSlot + P2P的方案解决了去中心化的问题，同时也提供了更好的动态扩展性。但相比于一致性Hash而言，其结构更加复杂，实现上也更加困难。

而在之前的分析中我们也能看出，一致性Hash方案整体上还是有着不错的表现的，因此在实际的系统应用中，可以根据开发成本和性能要求合理地选择最适合的方案。总之，两者都非常优秀，至于用哪个、怎么用，就是仁者见仁智者见智的问题了。

## **参考阅读** ##

> http://marklux.cn/blog/75  
> http://codelog.me/2015-10-12/consistent-hash-ketama/  
> https://github.com/ma6174/blog/issues/14  
> https://www.cnblogs.com/xrq730/p/5186728.html

*  ####  ####
    
    ![format_png 11][]
    
    \-- < End > --
 *  ####  ####
    
    **最近热文推荐：**
    
    1、[建议收藏 | Redis 使用 10 个小技巧][_ Redis _ 10]  
    
    
    2、[永远不要在代码中使用“User”这个单词][User]
    
    3、[项目中常用的19条MySQL优化][19_MySQL]
    
    4、[单怼多线程，60道面试题，你能答上几个？（附答案）][60]
    
    5、[这21 个刁钻的HashMap 面试题，我把阿里面试官吊打了！][21 _HashMap]
    
    6、[PanDownload复活了！60MB/s！附下载地址！][PanDownload_60MB_s]  
    
    
    7、[14 款牛逼的 IDEA 插件，让你开发速度飞起来！][14 _ IDEA]  
    
    
    8、[Redis分布式锁没用明白，搞出了大故障…][Redis]
    
    9、[程序员面试 10 大潜规则，千万不要踩坑！][10]  
    
    
    10、[*【收藏了】10分钟读懂进程线程、同步异步、阻塞非阻塞、并发并行*][10 1]
 *  #### **看完本文有收获？请转发分享给更多有需要的人** ####
 *  ####  ####
    
    关注 java大数据修炼之道
    
    **![format_png 12][]**每天学习java技术，你想学的Java知识这里都有！**![format_png 12][]**
    
    ![format_png 13][]
    
    微信扫描二维码，关注我的公众号
    
    写留言
 *  ####  ####
    
    如果对你有一点点帮助,请点个"在看",谢谢 ![format_png 14][]

[format_png]: /images/20221123/278f0d1a3e0048b3af53e25de5a4f2eb.png
[format_png 1]: /images/20221123/9fe8b935c6b6486fa3ecaf0e777cbc90.png
[java_word_PDF]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22dc7ccb5a4d1b94f2a9bbce26082c9f845fbbf7d588a5540d072bcef39b2281d0b705f91&idx=1&mid=2247492363&scene=21&sn=6975a1a5de92dc49d04654f21ffa7c21#wechat_redirect
[format_png 2]: /images/20221123/8d7dd9fcbcc943199aeb54adf5d0da00.png
[format_png 3]: /images/20221123/db2d40a0f5c149d2934b7ee410d47dca.png
[format_png 4]: /images/20221123/67f66d5dffb04743b83c3c5d8779ce3e.png
[format_png 5]: /images/20221123/eeea2094345e43a988dfad0b88a0e78c.png
[format_png 6]: /images/20221123/4a3a6407431141eeb0e6f3b7b686f734.png
[RabbitMQ]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd6212edca1a8389f770be2e54de16256dc7897f997bdf33710b1578508abc69beb879d9762&idx=1&mid=2247491074&scene=21&sn=e19ffe71fc871ec5e9ff96ed87eea5e8#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd62262dca1ab7482532648fd1582b82648acfe56305ee69bf0e4e019533799929d8cbf03e1&idx=1&mid=2247490894&scene=21&sn=88de5ece6b990d219a04e3f6917f3531#wechat_redirect
[Redis_MySQL_Docker]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd6240fdca1ad19a363b3c0a917352f78ca4cdb20c79f639298ef731295bde3753fd55cf539&idx=1&mid=2247490339&scene=21&sn=355246186ce9cad69a8a4fe578141ffb#wechat_redirect
[format_png 7]: /images/20221123/93712c10980b49958bd140532802b91f.png
[format_png 8]: /images/20221123/ed03f63359d74d818a64b7ea041ac23b.png
[format_png 9]: /images/20221123/7afcea7675df4d9b9a575be9f0c59511.png
[format_png 10]: /images/20221123/90358d1a9efa4d8da0d92ff371919c74.png
[format_png 11]: /images/20221123/cedcd55af90f4f5b924698540060d30d.png
[_ Redis _ 10]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22e05ccb5a713216d76a47efd7e4144ab9be9616235630f5f4edea4c8615182203fb8ef74&idx=1&mid=2247491785&scene=21&sn=a8cae67660d5733f1da6003c50d3529f#wechat_redirect
[User]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d142ccb65854ace9258a558f9fd0e17ad91a79020d569c567145f1dce2750f245a92a384&idx=1&mid=2247491470&scene=21&sn=b26fdeba68dab79e467857b93b2a547a#wechat_redirect
[19_MySQL]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22c17ccb5a501df41ddeaecf0f7e85e292b45d6c7522e4d6a4d9c4a93a389338ee175eae8&idx=1&mid=2247492315&scene=21&sn=37c6888e30892c7fae56d0769c35a571#wechat_redirect
[60]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d557ccb65c41ec5d3b7dedd6c7a22949ddcb5de1406de482c3b702a1a4768c66b730b219&idx=1&mid=2247490459&scene=21&sn=66bc23ae41a8abcb9a6f00be754b2e47#wechat_redirect
[21 _HashMap]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d429ccb65d3fc4be6ab008e4318d3beeccb1394801c72e33cbb9fd162868dce2b9b0c0f2&idx=1&mid=2247490277&scene=21&sn=63d44db7ae6930f25478119f423227d4#wechat_redirect
[PanDownload_60MB_s]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22c0eccb5a5182a51b78623168377d719bedbf820659acf2d1e71060c0046f6a18811be50&idx=1&mid=2247492290&scene=21&sn=fd4c3acf8e4589bc578b5425b1d7d8d1#wechat_redirect
[14 _ IDEA]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22c62ccb5a574a582677624bade6875be9a2ed64c74e970aa92378b3aada01448d43c818e&idx=1&mid=2247492270&scene=21&sn=faa5635ed83673df61747b147cab46e7#wechat_redirect
[Redis]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d038ccb6592e2d08ccd07a31a069ebbfc64d9abd2d1cfd88dba5efc1439f14cc78392bf3&idx=1&mid=2247491316&scene=21&sn=59fdccb5447abec7e33c881110c5be1f#wechat_redirect
[10]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc22cc6ccb5a5d09ec368b85dfe087d1b68f6ccbf67d7275356f64f203d353dcba684b4012e&idx=1&mid=2247492106&scene=21&sn=e25c3eea649006f34fd6f5cb62ea78be#wechat_redirect
[10 1]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d748ccb65e5e8bfe2334dac9c4a1678fa77a4b1c6bb230fb4442682c36120cfb8d8941ae&idx=1&mid=2247489924&scene=21&sn=40b4b841430ae75879b25545291dbf0a#wechat_redirect
[format_png 12]: /images/20221123/3edc52e65d8049a7bafe79286aeba2ad.png
[format_png 13]: /images/20221123/0d51bd73371b4478bafb6d313cb0e2a9.png
[format_png 14]: /images/20221123/79fb63306ec14920a0c05908773eefec.png