SOFA-源码分析-—-负载均衡和一致性-Hash

## 前言

SOFA 内置负载均衡，支持 5 种负载均衡算法，随机（默认算法），本地优先，轮询算法，一致性 hash，按权重负载轮询（不推荐，已被标注废弃）。

一起看看他们的实现（重点还是一致性 hash）。

源码分析

具体源码在 AbstractLoadBalancer 类中，子类需要实现 doSelect 方法：

public abstract ProviderInfo doSelect(SofaRequest invocation, List<ProviderInfo> providerInfos);

随机是默认算法，RandomLoadBalancer 类是具体实现，基本是就是 providerInfos.get(random.nextInt(size)) 的逻辑，但考虑到权重，会按总权重数随机找个数字，然后这个数字会递减直到小于 0 的时候，确定那个节点。好像看起来和权重没什么关系？ 有大佬懂的可以指导一下。

本地优先算法，则是找本机的 localhost 进行匹配，优先选择和本机地址相同的服务，然后在这些服务列表进行随机选一个。

轮询就是一个个来。使用取于算法。

然后就是一致性 Hash 了，重点讲讲。 有必要复习一下我们之前写过的一致性 hash 算法 demo： 自己实现一个一致性 Hash 算法。

SOFA 具体实现是 ConsistentHashLoadBalancer 类。内部维护一个 Map，每个服务对应一个选择器，这个选择器内部维护着一个 TreeMap，SOFA 会将所有节点均匀的散列在 Map 中，也就是 hash 环上，使用了虚拟节点。当根据服务的 key 获取节点的时候(如果服务列表没变)，会通过 hash 值找到比他大的那个节点，相同的请求每次找到的都是同一个节点（根据第一个参数 hash）。

来看看具体实现。

先看看 doSelect 方法：

@Override
public ProviderInfo doSelect(SofaRequest request, List<ProviderInfo> providerInfos) {
    String interfaceId = request.getInterfaceName();
    String method = request.getMethodName();
    String key = interfaceId + "#" + method;
    int hashcode = providerInfos.hashCode(); // 判断是否同样的服务列表
    Selector selector = selectorCache.get(key);
    if (selector == null // 原来没有
        ||
        selector.getHashCode() != hashcode) { // 或者服务列表已经变化
        selector = new Selector(interfaceId, method, providerInfos, hashcode);
        selectorCache.put(key, selector);
    }
    return selector.select(request);
}

根据接口名和方法名从 map 中找到对应的服务选择器，如果没有，或者服务列表变了，则重新创建一个，这点和缓存的一致性 Hash 设计还是有点不一样。

缓存的一致性 Hash 的目的是：如果服务列表变了，比如节点的增减，那么，缓存的 key 通过相同的 hash 算法依然能够找到对应的缓存节点（最多失效一个节点的数据——如果增减一个节点）。

但 RPC 服务的一致性 hash 的目的是：希望相同的请求总是落在同一个节点上。

而这里无法确定增加的是哪一个节点，索性直接创建一个新的。

然后，调用选择的 select 方法返回一个服务节点。

先看看选择器的构造方法：

public Selector(String interfaceId, String method, List<ProviderInfo> actualNodes, int hashcode) {
    this.interfaceId = interfaceId;
    this.method = method;
    this.hashcode = hashcode;
    // 创建虚拟节点环 （默认一个provider共创建128个虚拟节点，较多比较均匀）
    this.virtualNodes = new TreeMap<Long, ProviderInfo>();
    int num = 128;
    for (ProviderInfo providerInfo : actualNodes) {
        for (int i = 0; i < num / 4; i++) {
            byte[] digest = messageDigest(providerInfo.getHost() + providerInfo.getPort() + i);
            for (int h = 0; h < 4; h++) {
                long m = hash(digest, h);
                virtualNodes.put(m, providerInfo);
            }
        }
    }
}

主要逻辑就是构造虚拟节点，使用 TreeMap，和我们之前实现的一样。那么虚拟节点是如何设计的呢？

SOFA 为每个节点分配了 128 个虚拟节点，保存在 Map 中，也就是 128 个引用指向同一个对象。这里的 hash 算法用来 md5 然后再复杂的 hash 一波，为了更加的均衡吧。

当使用 select 方法的时候，怎么找到相同的节点呢？

代码：

private ProviderInfo sekectForKey(long hash) {
    ProviderInfo providerInfo = virtualNodes.get(hash);
    if (providerInfo == null) {
        SortedMap<Long, ProviderInfo> tailMap = virtualNodes.tailMap(hash);
        if (tailMap.isEmpty()) {
            hash = virtualNodes.firstKey();
        } else {
            hash = tailMap.firstKey();
        }
        providerInfo = virtualNodes.get(hash);
    }
    return providerInfo;
}

hash 该方法第一个参数，找到比他的 hash 值大节点集合中的第一个节点，如果没有比他大的，则最小的那个节点（回到原点）。

标准的一致性 hash 算法。保证了每次相同的请求都会落在同一个节点上。

总结

RPC 的一致性 hash 和缓存的一致性 hash 的目的是不同的。
缓存的目的是：当集群中缓存节点增减的时候，服务访问相同 key 依然能够访问到相同的节点（增减造成的失效节点很少）。不会像普通的取于算法那样造成无法访问，进而引起缓存雪崩，甚至 DB 宕机。

而 RPC 的目的是：希望相同的请求（第一个参数相同），每次都会打在相同的节点上。

换个角度想想，其实都是一样的，目的都是为了相同的请求每次都访问到相同的节点。

好啦，关于 SOFA 的负载均衡就到这里啦。

bye！！！