竹子爱熊猫
竹子爱熊猫

(四)网络编程之请求分发篇：负载均衡静态调度算法、平滑轮询加权、一致性哈希、最小活跃数算法实践！

引言

   先如今所有的技术栈中，只要一谈关于高可用、高并发处理相关的实现，必然会牵扯到集群这个话题，也就是部署多台服务器共同对外提供服务，从而做到提升系统吞吐量，优化系统的整体性能以及稳定性等目的。

当多台机器上部署相同服务节点时，客户端的发送请求访问就会出现一个必须要解决的问题：客户端的请求到底该交由哪台服务器处理？这点则由负载均衡策略来决定，也就是说：请求具体会被分发到哪台服务器，是调度算法来决定的。

   在上篇《Nginx》的文章中，我们首次引出了负载均衡的概念，在通过Nginx对后端做集群时，里面可以配置负载均衡策略，从而能够做到让访问系统的大规模流量均匀分散到集群中的每台服务器上，但在上篇Nginx的文章中并未对此展开叙述，但负载相关的内容对于后续的分布式、中间件专题尤为重要，因此也来详细剖析一下。

负载均衡这个概念，几乎在所有支持高可用的技术栈中都存在，例如微服务、分库分表、各大中间件（MQ、Redis、MyCat、Nginx、ES）等，也包括云计算、云调度、大数据中也是炙手可热的词汇。

负载均衡策略主要分为静态与动态两大类：

  • 静态调度算法：指配置后只会依据配置好的策略进行请求分发的算法。
  • 动态调度算法：指配置后会根据线上情况（网络/CPU负载/磁盘IO等）来分发请求。

但负载均衡算法数量并不少，本篇主要对于一些常用且高效的负载策略进行剖析。

一、基本的负载算法

   如果聊到最基本的负载均衡算法，那么相信大家多少都有了解，例如：轮询、随机、权重等这类算法。特点就在于实现简单，先来快速过一遍基本的算法实现。

1.1、轮询算法

   轮询算法是最为简单、也最为常见的算法，也是大多数集群情况下的默认调度算法，这种算法会按照配置的服务器列表，按照顺序依次分发请求，所有服务器都分发一遍后，又会回到第一台服务器循环该步骤，Java代码实现如下：

// 服务类：主要用于保存配置的所有节点
public class Servers {
    
    // 模拟配置的集群节点
    public static List SERVERS = Arrays.asList(
            "44.120.110.001:8080",
            "44.120.110.002:8081",
            "44.120.110.003:8082",
            "44.120.110.004:8083",
            "44.120.110.005:8084"
    );
}

// 轮询策略类：实现基本的轮询算法
public class RoundRobin{
    // 用于记录当前请求的序列号
    private static AtomicInteger requestIndex = new AtomicInteger(0);

    // 从集群节点中选取一个节点处理请求
    public static String getServer(){
        // 用请求序列号取余集群节点数量，求得本次处理请求的节点下标
        int index = requestIndex.get() % Servers.SERVERS.size();
        // 从服务器列表中获取具体的节点IP地址信息
        String server = Servers.SERVERS.get(index);
        // 自增一次请求序列号，方便下个请求计算
        requestIndex.incrementAndGet();
        // 返回获取到的服务器IP地址
        return server;
    }
}

// 测试类：测试轮询算法
public class Test{
    public static void main(String[] args){
        // 使用for循环简单模拟10个客户端请求
        for (int i = 1; i <= 10; i++){
            System.out.println("第"+ i + "个请求：" + RoundRobin.getServer());
        }
    }
}

/******输出结果*******/
第1个请求：44.120.110.001:8080
第2个请求：44.120.110.002:8081
第3个请求：44.120.110.003:8082
第4个请求：44.120.110.004:8083
第5个请求：44.120.110.005:8084
第6个请求：44.120.110.001:8080
第7个请求：44.120.110.002:8081
第8个请求：44.120.110.003:8082
第9个请求：44.120.110.004:8083
第10个请求：44.120.110.005:8084

上述案例中，整个算法的实现尤为简单，就是通过一个原子计数器记录当前请求的序列号，然后直接通过%集群中的服务器节点总数，最终得到一个具体的下标值，再通过这个下标值，从服务器IP列表中获取一个具体的IP地址。

轮询算法的优势：

  • ①算法实现简单，请求分发效率够高。
  • ②能够将所有请求均摊到集群中的每个节点上。
  • ③易于后期弹性伸缩，业务增长时可以拓展节点，业务萎靡时可以缩减节点。

轮询算法的劣势：

  • ①对于不同配置的服务器无法合理照顾，无法将高配置的服务器性能发挥出来。
  • ②由于请求分发时，是基于请求序列号来实现的，所以无法保证同一客户端的请求都是由同一节点处理的，因此需要通过session记录状态时，无法确保其一致性。

轮询算法的应用场景：

  • ①集群中所有节点硬件配置都相同的情况。
  • ②只读不写，无需保持状态的情景。

1.2、随机算法

   随机算法的实现也非常简单，也就是当客户端请求到来时，每次都会从已配置的服务器列表中随机抽取一个节点处理，实现如下：

// 随机策略类：随机抽取集群中的一个节点处理请求
public class Random {
    // 随机数产生器，用于产生随机因子
    static java.util.Random random = new java.util.Random();

    public static String getServer(){
        // 从已配置的服务器列表中，随机抽取一个节点处理请求
        return Servers.SERVERS.get(random.nextInt(Servers.SERVERS.size()));
    }
}

上述该算法的实现，非常明了，通过java.util包中自带的Random随机数产生器，从服务器列表中随机抽取一个节点处理请求，该算法的结果也不测试了，大家估计一眼就能看明白。

随机算法的优势：个人看来该算法单独使用的意义并不大，一般会配合下面要讲的权重策略协同使用。

随机算法的劣势：

  • ①无法合理的将请求均摊到每台服务器节点。
  • ②由于处理请求的目标服务器不明确，因此也无法满足需要记录状态的请求。
  • ③能够在一定程度上发挥出高配置的机器性能，但充满不确定因素。

1.3、权重算法

   权重算法是建立在其他基础算法之上推出的一种概念，权重算法并不能单独配置，因为权重算法无法做到请求分发的调度，所以一般权重会配合其他基础算法结合使用，如：轮询权重算法、随机权重算法等，这样可以让之前的两种基础调度算法更为“人性化”一些。
   权重算法是指对于集群中的每个节点分配一个权重值，权重值越高，该节点被分发的请求数也会越多，反之同理。这样做的好处十分明显，也就是能够充分考虑机器的硬件配置，从而分配不同权重值，做到“能者多劳”。那如何实现呢，先来看看随机权重的实现：

public class Servers{
    // 在之前是Servers类中再加入一个权重服务列表
    public static Map WEIGHT_SERVERS = new LinkedHashMap<>();
    static {
        // 配置集群的所有节点信息及权重值
        WEIGHT_SERVERS.put("44.120.110.001:8080",17);
        WEIGHT_SERVERS.put("44.120.110.002:8081",11);
        WEIGHT_SERVERS.put("44.120.110.003:8082",30);
    }
}

// 随机权重算法
public class Randomweight {
    // 初始化随机数生产器
    static java.util.Random random = new java.util.Random();

    public static String getServer(){
        // 计算总权重值
        int weightTotal = 0;
        for (Integer weight : Servers.WEIGHT_SERVERS.values()) {
            weightTotal += weight;
        }

        // 从总权重的范围内随机生成一个索引
        int index = random.nextInt(weightTotal);
        System.out.println(index);

        // 遍历整个权重集群的节点列表，选择节点处理请求
        String targetServer = "";
        for (String server : Servers.WEIGHT_SERVERS.keySet()) {
            // 获取每个节点的权重值
            Integer weight = Servers.WEIGHT_SERVERS.get(server);
            // 如果权重值大于产生的随机数，则代表此次随机分配应该落入该节点
            if (weight > index){
                // 直接返回对应的节点去处理本次请求并终止循环
                targetServer = server;
                break;
            }
            // 如果当前节点的权重值小于随机索引，则用随机索引减去当前节点的权重值，
            // 继续循环权重列表，与其他的权重值进行对比，
            // 最终该请求总会落入到某个IP的权重值范围内
            index = index - weight;
        }
        // 返回选中的目标节点
        return targetServer;
    }

    public static void main(String[] args){
        // 利用for循环模拟10个客户端请求测试
        for (int i = 1; i <= 10; i++){
            System.out.println("第"+ i + "个请求：" + getServer());
        }
    }
}

/********运行结果********/
第1个请求：44.120.110.003:8082
第2个请求：44.120.110.001:8080
第3个请求：44.120.110.003:8082
第4个请求：44.120.110.003:8082
第5个请求：44.120.110.003:8082
第6个请求：44.120.110.003:8082
第7个请求：44.120.110.003:8082
第8个请求：44.120.110.001:8080
第9个请求：44.120.110.001:8080
第10个请求：44.120.110.002:8081

上面这个算法对比之前的基本实现，可能略微有些复杂难懂，我们先上个图：

随机权重算法

仔细观看上图后，逻辑应该会清晰很多，大体捋一下思路：

  • 先求和所有的权重值，再随机生成一个总权重之内的索引。
  • 遍历之前配置的服务器列表，用随机索引与每个节点的权重值进行判断。
    • 如果小于，则代表当前请求应该落入目前这个节点。
    • 如果大于，则代表随机索引超出了目前节点的权重范围，则减去当前权重，继续与其他节点判断。
  • 最终随机出的索引总会落入到一个节点的权重范围内，最后返回对应的节点IP。

这样一分析下来，估摸着各位小伙伴应该都理解了，接着再来看看轮询权重算法的实现：

// 轮询权重算法
public class RoundRobinweight {
    private static AtomicInteger requestCount = new AtomicInteger(0);

    public static String getServer(){
        int weightTotal = 0;
        for (Integer weight : Servers.WEIGHT_SERVERS.values()) {
            weightTotal += weight;
        }
        
        String targetServer = "";
        int index = requestCount.get() % weightTotal;
        requestCount.incrementAndGet();

        for (String server : Servers.WEIGHT_SERVERS.keySet()) {
            Integer weight = Servers.WEIGHT_SERVERS.get(server);
            if (weight > index){
                targetServer = server;
                break;
            }
            index = index - weight;
        }
        return targetServer;
    }

    public static void main(String[] args){
        for (int i = 1; i <= 10; i++){
            System.out.println("第"+ i + "个请求：" + getServer());
        }
    }
}

/********运行结果*********/
第1个请求：44.120.110.001:8080
第2个请求：44.120.110.001:8080
第3个请求：44.120.110.001:8080
第4个请求：44.120.110.001:8080
第5个请求：44.120.110.001:8080
第6个请求：44.120.110.001:8080
第7个请求：44.120.110.001:8080
第8个请求：44.120.110.001:8080
第9个请求：44.120.110.001:8080
第10个请求：44.120.110.001:8080

观察上述中的案例，此刻会发现出端倪，代码实现过程相同，但此刻的输出结果，竟然全部请求都被分发到了44.120.110.001:8080这个节点，这是为什么呢？因为此时是通过请求序列号去进行判断的，所以最终效果会成为：

  • 前17个请求会交给44.120.110.001:8080节点。
  • 后续11个请求会交给44.120.110.002:8081节点。
  • 最后30个请求会交给44.120.110.003:8082节点。
  • 然后持续重复该过程.....

此时似乎离我们预期的负载效果发生了偏离，如果采用这种方案去实现轮询权重算法，最终会将一个集群变为单点服务，这显然并不是期待中的效果，因此需要一种新的方式去实现，那么又该如何去做呢？此时需要牵扯到一种请求调度的高级算法：平滑加权轮询算法。

二、平滑加权轮询算法

   平滑轮询加权算法的本质就是为了解决之前实现方式中所存在的问题，能够将请求均匀的按照权重值分发到每台机器。这种算法设计的非常巧妙，实现过程也尤为有趣，我们一起来看看：

// 权重服务器的配置类
public class Servers {
    public static Map WEIGHT_SERVERS = new LinkedHashMap<>();
    static {
        // 权重值设置的略微小一点，方便后续理解算法
        WEIGHT_SERVERS.put("44.120.110.001:8080",3);
        WEIGHT_SERVERS.put("44.120.110.002:8081",2);
        WEIGHT_SERVERS.put("44.120.110.003:8082",1);
    }
}

// 权重类
public class Weight {
    // 节点信息
    private String server;
    // 节点权重值
    private Integer weight;
    // 动态权重值
    private Integer currentWeight;

    // 构造方法
    public Weight() {}
    public Weight(String server, Integer weight, Integer currentWeight) {
        this.server = server;
        this.weight = weight;
        this.currentWeight = currentWeight;
    }

    // 封装方法
    public String getServer() {
        return server;
    }
    public void setServer(String server) {
        this.server = server;
    }
    public Integer getWeight() {
        return weight;
    }
    public void setWeight(Integer weight) {
        this.weight = weight;
    }
    public Integer getCurrentWeight() {
        return this.currentWeight;
    }
    public void setCurrentWeight(Integer currentWeight) {
        this.currentWeight = currentWeight;
    }
}

public class RoundRobinWeight {
    // 初始化存储每个节点的权重容器
    private static Map weightMap = new HashMap<>();

    // 计算总权重值，只需要计算一次，因此放在静态代码块中执行
    private static int weightTotal = 0;
    static {
        sumWeightTotal();
    }

    // 求和总权重值，后续动态伸缩节点时，再次调用该方法即可。
    public static void sumWeightTotal(){
        for (Integer weight : Servers.WEIGHT_SERVERS.values()) {
            weightTotal += weight;
        }
    }

    // 获取处理本次请求的具体服务器IP
    public static String getServer(){
        // 判断权重容器中是否有节点信息
        if (weightMap.isEmpty()){
            // 如果没有则将配置的权重服务器列表挨个载入容器
            Servers.WEIGHT_SERVERS.forEach((servers, weight) -> {
                // 初始化时，每个节点的动态权重值都为0
                weightMap.put(servers, new Weight(servers, weight, 0));
            });
        }

        // 每次请求时，更改动态权重值
        for (Weight weight : weightMap.values()) {
            weight.setCurrentWeight(weight.getCurrentWeight()
                    + weight.getWeight());
        }

        // 判断权重容器中最大的动态权重值
        Weight maxCurrentWeight = null;
        for (Weight weight : weightMap.values()) {
            if (maxCurrentWeight == null || weight.getCurrentWeight()
                    > maxCurrentWeight.getCurrentWeight()){
                maxCurrentWeight = weight;
            }
        }

        // 最后用最大的动态权重值减去所有节点的总权重值
        maxCurrentWeight.setCurrentWeight(maxCurrentWeight.getCurrentWeight()
                - weightTotal);

        // 返回最大的动态权重值对应的节点IP
        return maxCurrentWeight.getServer();
    }

    public static void main(String[] args){
        // 使用for循环模拟6次请求
        for (int i = 1; i <= 6; i++){
            System.out.println("第"+ i + "个请求：" + getServer());
        }
    }
}

/********输出结果********/
第1个请求：44.120.110.001:8080
第2个请求：44.120.110.002:8081
第3个请求：44.120.110.001:8080
第4个请求：44.120.110.003:8082
第5个请求：44.120.110.002:8081
第6个请求：44.120.110.001:8080

先看结果，对比之前的实现方式而言，该算法在分发请求时，确实均匀了很多很多，而且请求分发的数量与我们配置的权重值也恰巧相符合：

  • 44.120.110.001:8080：3次
  • 44.120.110.002:8081：2次
  • 44.120.110.003:8082：1次

这是不是很神奇？如何做到的呢，接下来简单聊一下该算法的核心思想。

在之前的权重算法中，服务器列表中只有两个值：服务器IP、对应的权重值，而在当前这种算法中，需要再引入一个动态权重值的概念，所以我们再上述案例中，将服务器的列表抽象成了一个Weight类，在该类中除开原本的servers、weight之外，多添加了一个字段currentWeight，用于记录每个节点的动态权重（该值是变化的）。

在该算法中，会先计算已配置的权重值总和，然后第一次请求，会初始化权重容器weightMap，将每个配置的节点都封装成一个Weight对象，并将其动态权重值初始化为0，如下：

  • Weight("server":"44.120.110.001:8080","weight":3,"currentWeight":0)
  • Weight("server":"44.120.110.002:8081","weight":2,"currentWeight":0)
  • Weight("server":"44.120.110.003:8082","weight":1,"currentWeight":0)

OK，至此准备工作就绪，接下来是算法的核心过程，主要分为三步：

  • ①用原本的动态权重值加一次每个节点的静态权重值，计算出新的动态权重值。
  • ②遍历权重容器，找出动态权重值最大的节点，将其作为处理本次请求的节点。
  • ③用最大的动态权重值减去已配置的静态权重值总和，为一下轮分发做准备。

结合上述的算法过程和前面给出的案例，把整个过程摊开剖析一次：

序列号 计算动态权重 寻找最大权重 最大权重减总权重 本次目标IP
① 3,2,1 3 -3,2,1 44.120.110.001:8080
② 0,4,2 4 0,-2,2 44.120.110.002:8081
③ 3,0,3 3 -3,0,3 44.120.110.001:8080
④ 0,2,4 4 0,0,-2 44.120.110.003:8082
⑤ 3,4,-1 4 3,-2,-1 44.120.110.002:8081
⑥ 6,0,0 6 0,0,0 44.120.110.001:8080

上表中列出了六次请求的处理过程，整个过程到最后，动态权重值又会回归初始值：0,0,0，然后开启新的一轮计算，周而复始之，格外的神奇^_^。

平滑加权轮询算法也是应用最为广泛的轮询算法，在Dubbo、Robbin、Nginx、Zookeeper等一些集群环境中，当你配置了权重时，默认采用的就是该算法作为请求分发的策略。

三、一致性哈希算法

   其实平滑加权轮询算法对于请求分发而言，是一种比较优秀的策略了，不过前面分析的所有策略，都存在一个致命问题：不能确保同一客户端的所有请求都分发在同一台服务器处理，因此无法实现有状态的请求，好比最简单的登录功能，客户端发送请求登录成功，然后将其登录的状态保存在session中，结果客户端的第二次请求被分发到了另外一台机器，由于第二台服务器session中没有相关的登录信息，因此会要求客户端重新登录，这显然造成的用户体验感是极差的，那么对于这种问题又该如何解决呢？主要有两种方案：

  • ①采用外部中间件存储session，例如Redis，然后从Redis中获取登录状态。
  • ②采用特殊的请求分发策略，确保同一客户端的所有请求都会去到同一台机器上处理。

一致性哈希算法 就是一种能够能够确保同一客户端的所有请求都会被分发到同一台机器的策略，不过一致性哈希算法依旧会存在问题，就是当集群中某个节点下线，或者集群出现拓展时，那么也会影响最终分发的目标机器，所以一般一致性哈希算法并不能100%解决session一致性的问题，因此该算法一般很少用于网关层的请求分发，更多的场景是应用在分布式缓存等情况，接下来一起来看看。

3.1、通过其他分发算法实现缓存

   在讲解一致性哈希算法之前，大家先来简单理解一下一致性哈希算法的产生背景。

先思考一个问题：假设目前单台缓存服务器无法承担外部的访问压力，此刻会如何去做呢？

答案是增加新的缓存服务器节点，拓展出一个集群对外提供服务。

好的，那问题又来了，现在缓存服务器是一个集群环境，此刻来了一个请求后该落入哪个节点呢？

   假设采用轮询策略，那么写入xxx缓存信息的请求被分发到了第一个节点，客户端读取xxx时，请求又被分发到了第三个节点上，那么显然是读不到之前的缓存。而且最关键的是，一般的轮询策略都是需要基于集群的节点数量进行请求分发的，因此集群中的节点一旦出现伸缩，最终会导致所有缓存内容全部失效。
   就拿最基本的取模轮询来说，原本集群是3个节点，所以是基于取模3去分发请求，结果有台节点宕机了，成为了取模2，那最后整个缓存系统分发请求完全乱套.....

如果采用随机策略.....，更不靠谱.....

因此在这种需求背景下，大名鼎鼎的一致性哈希算法问世了，一致性哈希算法其实也使用的取模方式，只是，刚才描述的取模轮询法是对服务器的数量进行取模，而一致性哈希算法是对2^32取模，什么意思呢？我们一点点来讲。

3.2、一致性哈希核心-哈希环

   实现一致性哈希算法的核心结构在于哈希环，前面讲到过一致性哈希是基于2^32做取模，那么首先可以将二的三十二次方想象成一个圆，这个圆总共由2^32个点组成，如下：

哈希环-V1

圆环的正上方第一个点代表0，0右侧的点按照1、2、3、4....的顺序依此类推，直到2^32-1，也就是说0左侧的第一个点代表着2^32-1。

最终这个在逻辑上由2^32个点组成的圆，被称为哈希环。

结合之前的缓存案例，假设有四台缓存服务器A、B、C、D，然后再通过每台服务器的IP哈希值取模2^32，最终必然会得到一个2^32范围之内的整数，这个数在哈希环上定然也对应着一个点，那么每台服务器的IP就可以映射到哈希环上，如下：

哈希环-V2

到此时，服务器已经和哈希环建立起了联系，那么此时当客户端发送请求时，又可以通过相同的计算方式，将客户端需要操作的缓存Key进行相同的哈希取模，然后同样将其映射到哈希环上，例如写入一条缓存name=竹子，如下：
哈希环-V3

那么此时该缓存纠结要落入到哪台服务器呢？答案是B，为什么？因为在哈希环结构中，沿着顺时针方向走，遇到的第一台服务器是B，所以最终会落到B服务器上。

当然，如果一致性哈希算法被用于请求分发，那么就以用户的IP作为哈希取模的条件，这样就能确保同一个客户端的所有请求都会被分发到同一台服务器。

一致性哈希算法中，就利用哈希环结构+哈希取模判断每个请求该落入的服务器，由于服务器IP、客户端IP或缓存的Key都是相同的，所以在服务器数量不变的情况，相同的哈希条件进行哈希取模，最终计算出来的值永远都是相同的，然后再通过计算出的值，在哈希环结构上进行顺时针查找，能够定位到的服务器也是相同的，所以相同属性的请求永远会落入到同一服务器。

3.3、哈希环的映射偏移问题

   经过上述分析后，好像发现一致性哈希算法没啥大毛病，但上述中属于“理想状态”：

理想vs现实

可偏偏理想很丰满，现实却很骨感，实际映射服务器IP的过程中，可能会出现如下情况：
映射偏移

   由于服务器IP哈希取模后，无法确保哈希得到的数字能够均匀分布，因此就有可能造成如上情况，所有的服务器IP都被映射在“一块儿”，最终导致A服务器承载了90%以上的访问压力。

3.4、映射偏移造成的宕机连锁反应

   接上述，如果服务器IP映射在哈希环上出现偏移，在大流量的冲击下，这种情况很容易导致整个集群崩塌，首先是A扛不住并发冲击，宕机下线，紧接着流量交给B，B也扛不住，接着宕机，然后C.....，因此哈希环映射偏移问题可能会造成的一系列连锁反应，所以在一致性哈希算法中，为了确保整个集群的健壮性，提出了一种虚拟节点的概念来解决此问题。

虚拟节点其实本质上就是真实服务器节点的复制品，虚拟节点映射的IP都是指向于真实服务器的，就类似平时.EXE软件的快捷方式，现在为QQ创建了一个快捷方式，然后拷贝到了十个不同的目录下，但本质上这十个快捷方式指向的启动文件都是相同exe程序，哈希环中的虚拟节点也同理，如下：

虚拟节点

从上图中可以看出，A、B、C、D四台服务器分别都映射出了一个虚拟节点，引入虚拟节点后会明显感觉出来，原本A服务器需要承载90%以上的流量，但此刻映射出的虚拟节点大大减轻了A的压力，将流量均摊到了集群中的每个节点。

在一致性哈希算法的实际应用场景中，绝非只映射一个虚拟节点，往往会为一个真实节点映射数十个虚拟节点，以便于减小哈希环偏移所带来的影响。同时，虚拟节点的数量越多，请求在分发时也能更均匀的分布，哈希环最终结构如下：

哈希环最终态

3.5、Java实现一致性哈希算法

   讲了这么多，那么一致性哈希算法究竟如何实现呢？接下来一起看看：

public class Servers {
    public static List SERVERS = Arrays.asList(
            "44.120.110.001:8080",
            "44.120.110.002:8081",
            "44.120.110.003:8082",
            "44.120.110.004:8083",
            "44.120.110.005:8084"
    );
}

public class ConsistentHash {
    // 使用有序的红黑树结构，用于实现哈希环结构
    private static TreeMap virtualNodes = new TreeMap<>();
    // 每个真实节点的虚拟节点数量
    private static final int VIRTUAL_NODES = 160;

    static {
        // 对每个真实节点添加虚拟节点，虚拟节点会根据哈希算法进行散列
        for (String serverIP : Servers.SERVERS) {
            // 将真实节点的IP映射到哈希环上
            virtualNodes.put(getHashCode(serverIP), serverIP);
            // 根据设定的虚拟节点数量进行虚拟节点映射
            for (int i = 0; i < VIRTUAL_NODES; i++){
                // 计算出一个虚拟节点的哈希值（只要不同即可）
                int hash = getHashCode(serverIP + i);
                // 将虚拟节点添加到哈希环结构上
                virtualNodes.put(hash, serverIP);
            }
        }
    }

    public static String getServer(String IP){
        int hashCode = getHashCode(IP);
        // 得到大于该Hash值的子红黑树
        SortedMap sortedMap = virtualNodes.tailMap(hashCode);
        // 得到该树的第一个元素，也就是最小的元素
        Integer treeNodeKey = sortedMap.firstKey();
        // 如果没有大于该元素的子树了，则取整棵树的第一个元素，相当于取哈希环中的最小元素
        if (sortedMap == null)
            treeNodeKey = virtualNodes.firstKey();
        // 返回对应的虚拟节点名称
        return virtualNodes.get(treeNodeKey);
    }

    // 哈希方法：用于计算一个IP的哈希值
    public static int getHashCode(String IP){
        final int p = 1904390101;
        int hash = (int)1901102097L;
        for (int i = 0; i < IP.length(); i++)
            hash = (hash ^ IP.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;
    }

    public static void main(String[] args){
        // 用for循环模拟五个不同的IP访问
        for (int i = 1; i <= 5; i++){
            System.out.println("第"+ i + "个请求：" + getServer("192.168.12.13"+i));
        }
        System.out.println("-----------------------------");
        // 用for循环模拟三个相同的IP访问
        for (int i = 1; i <= 3; i++){
            System.out.println("第"+ i + "个请求：" + getServer("192.168.12.131"));
        }
    }
}

/********输出结果*******/
第1个请求：44.120.110.002:8081
第2个请求：44.120.110.003:8082
第3个请求：44.120.110.004:8083
第4个请求：44.120.110.003:8082
第5个请求：44.120.110.004:8083
-----------------------------
第1个请求：44.120.110.002:8081
第2个请求：44.120.110.002:8081
第3个请求：44.120.110.002:8081

上述便是Java实现一致性哈希算法的全过程，其实并不难理解，里面用到了TreeMap实现了哈希环结构，并且指定了每个服务器节点的虚拟节点数量，同时实现了一个简单的哈希方法，用于计算入参的哈希值，算法过程如下：

  • ①启动时先根据指定的数量，映射对应的虚拟节点数量在哈希环上。
  • ②通过计算客户端哈希值，然后在哈希环上取得大于该值的节点，然后返回对应的IP。
    • 由于哈希环是取顺时针方向的第一个节点作为处理请求的目标服务器，所以获取大于该哈希值的节点中的第一个节点即可。
  • ③如果哈希环中没有大于客户端哈希值的节点，那么则将这些客户端的请求分发到整个Map上的第一台服务器，从此实现哈希闭环。

一致性哈希算法由于其特性，因此一般多被用于分布式缓存中的集群分片，尤其是MemCache的缓存分片，就是采用一致性哈希算法实现的，而Redis自身推出的RedisCluster分片集群中，也借用了一致性哈希算法的思想，不过进行了改版实现，内部采用CRC16+HashSolt实现了缓存分片，但核心思想也是相同的。

当然，文中给出的算法过程都是较为简单的实现，如若想要参考完整的实现，可以参考Dubbo的com.alibaba.dubbo.rpc.cluster.loadbalance包，或参考SpringCloudRibbon的com.netflix.loadbalancer包下的实现。

四、最小活跃数算法

   上述分析的基本算法、平滑轮询加权、一致性哈希等算法都属于静态算法，也就是说这些算法配置后，并不会根据线上的实际运行情况进行调整，只会根据已配置的规则进行请求分发。
   最小活跃数算法则会根据线上的实际情况进行分发，能够灵活的检测出集群中各个节点的状态，能够自动寻找并调用活跃度最低的节点处理请求，Java实现如下：

// 节点类：用于封装集群中的每个节点
public class Server {
    private String IP;
    private AtomicInteger active;
//    private Integer weight;

    public Server(){}
    public Server(String IP,int active) {
        this.IP = IP;
        // 将外部传递的活跃数作为默认活跃数
        this.active = new AtomicInteger(active);
    }

    public String getIP() {
        // 每分发一个请求时自增一次活跃数
        active.incrementAndGet();
        return IP;
    }

    public AtomicInteger getActive() {
        return active;
    }
}

// 集群类：用于模拟集群节点列表
public class Servers {
    // 活跃度衰减器
    public static void attenuator(){
        new Thread(()->{
            // 遍历集群中的所有节点
            for (Server server : Servers.SERVERS) {
                // 如果活跃度不为0
                if (server.getActive().get() != 0){
                    // 则自减一个活跃度
                    server.getActive().getAndDecrement();
                }
            }
            try {
                // 每隔 2 秒中衰减一次活跃度
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }).start();
    }

    // 模拟的集群节点信息，活跃数最开始默认为0
    public static List SERVERS = Arrays.asList(
            new Server("44.120.110.001:8080",0),
            new Server("44.120.110.002:8081",0),
            new Server("44.120.110.003:8082",0)
    );
}

// 最小活跃数算法实现类
public class LeastActive {

    public static String getServer(){
        // 初始化最小活跃数和最小活跃数的节点
        int leastActive = Integer.MAX_VALUE;
        Server leastServer = new Server();
        // 遍历集群中的所有节点
        for (Server server : Servers.SERVERS) {
            // 找出活跃数最小的节点
            if (leastActive > server.getActive().get()){
                leastActive = server.getActive().get();
                leastServer = server;
            }
        }

        // 返回活跃数最小的节点IP
        return leastServer.getIP();
    }

    public static void main(String[] args){
        Servers.attenuator();
        for (int i = 1; i <= 10; i++){
            System.out.println("第"+ i + "个请求：" + getServer());
        }
    }
}

/********运行结果*********/
第1个请求：44.120.110.001:8080
第2个请求：44.120.110.002:8081
第3个请求：44.120.110.003:8082
第4个请求：44.120.110.001:8080
第5个请求：44.120.110.002:8081
第6个请求：44.120.110.003:8082
第7个请求：44.120.110.001:8080
第8个请求：44.120.110.002:8081
第9个请求：44.120.110.003:8082
第10个请求：44.120.110.001:8080

观察如上案例的运行结果，似乎结果好像是轮询的效果呀？确实是的，这是因为在最开始，所有节点的活跃数都为0，三个节点的活跃数都相同，所以默认会先取集群中的第一个活跃数为0的节点处理请求，第一个节点的活跃数会变成1，第二次请求时最小活跃数也为0，然后取第二个节点处理请求，依此类推......

在线上环境下，不会出现轮询的效果，因为每台服务器随着运行时间的增长，活跃数必然会不同，因此该算法总会取活跃数最小的节点提供服务。

当然，上述案例中实现的最小活跃数，是比较简易的版本，对于完善的实现可以参考Dubbo框架中的com.alibaba.dubbo.rpc.cluster.loadbalance.LeastActiveLoadBalance类，其中也实现了权重机制，简单阐述一下其中的原理实现：

  • ①先从注册中心中拉取所有的服务实例，然后找出活跃数最小的节点。
  • ②如果只有一个，那么则直接返回对应的实例节点处理本次请求。
  • ③如果存在多个，则根据每个节点配置的权重值来决定本次处理请求的具体节点。
  • ④如果权重值不同，优先选取权重值最大的实例，作为处理本次请求的节点。
  • ⑤如果存在相同的最大权重值，那么则通过随机的方式选择一个节点提供服务。

当然，由于需要对每个节点去实现活跃数监听，所以在Dubbo框架中，想要配置最小活跃数策略，那么需要首先启用ActiveLimitFilter记录每个节点的活跃数。

或者也可以参考Ribbon框架com.netflix.loadbalancer包下面的BestAvailableRule最小活跃数算法实现类。

从最小活跃数算法特性不难得知，该算法带来的优势极为明显，永远都能选取节点列表中最空闲的那台服务器处理请求，从而避免某些负载过高的节点，还依旧承担需要承担新的流量访问，造成更大的压力。

五、最优响应算法

   与前面分析的最小活跃数算法一样，最优响应算法也是一种动态算法，但它比最小活跃数算法更加智能，因为最小活跃数算法中，如果一台节点存在故障，导致它自身处理的请求数比较少，那么它会遭受最大的访问压力，这显然是并不合理的。

最小活跃数算法就类似于平时的搬砖工作，谁事情做的最少谁留下来加班，在正常情况下，这种算法都能够找到“摸鱼”最厉害的员工留下来加班，但如果有一天，某个员工由于身体出问题了，导致自己做的工作量比较少，但按照这种算法的逻辑，依旧会判定为该员工今天最闲，所以留下来加班。

从上述这个案例中，大家略微能够感受出来最小活跃数算法的不合理性。

而最优响应算法则更加智能，该算法在开始前，会对服务列表中的各节点发出一个探测请求(例如Ping或心跳包检测)，然后根据各节点的响应时间来决定由哪台服务器处理客户端请求，该算法能较好根据节点列表中每台机器的当前运行状态分发请求，Java实现如下：

public class Servers {
    // 模拟的集群节点信息，活跃数最开始默认为0
    public static List SERVERS = Arrays.asList(
            new Server("44.120.110.001:8080"),
            new Server("44.120.110.002:8081"),
            new Server("44.120.110.003:8082")
    );
}

public class Server {
    private String IP;

    public Server(){}
    public Server(String IP) {
        this.IP = IP;
    }
    public String getIP() {
        return IP;
    }
    public void setIP(String IP){
        this.IP = IP;
    }

    public String ping(){
        // 生成一个1000~3000之间的随机数
        int random = ThreadLocalRandom.current().nextInt(1000, 2000);
        try {
            // 随机休眠一段时间，模拟不同的响应速度
            Thread.sleep(random);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 最后返回自身的IP
        return this.IP;
    }
}

public class ResponseTime {
    // 创建一个定长的线程池，用于去执行ping任务
    static ExecutorService pingServerPool = 
        Executors.newFixedThreadPool(Servers.SERVERS.size());

    public static String getServer() throws InterruptedException {
        // 创建一个CompletableFuture用于拼接任务
        CompletableFuture cfAnyOf;
        // 创建一个接收结果返回的server节点对象
        final Server resultServer = new Server();
        // 根据集群节点数量初始化一个异步任务数组
        CompletableFuture[] cfs = new CompletableFuture[Servers.SERVERS.size()];

        // 遍历整个服务器列表，为每个节点创建一个ping任务
        for (Server server : Servers.SERVERS) {
            // 获取当前节点在集群列表中的下标
            int index = Servers.SERVERS.indexOf(server);
            // 为每个节点创建一个ping任务，并交给pingServerPool线程池执行
            CompletableFuture cf =
                    CompletableFuture.supplyAsync(server::ping,pingServerPool);
            // 将创建好的异步任务加入数组中
            cfs[index] = cf;
        }

        // 将创建好的多个Ping任务组合成一个聚合任务并执行
        cfAnyOf = CompletableFuture.anyOf(cfs);

        // 监听执行完成后的回调，谁先执行完成则返回谁
        cfAnyOf.thenAccept(resultIP -> {
             System.out.println("最先响应检测请求的节点为：" + resultIP);
            resultServer.setIP((String) resultIP);
        });
        //  阻塞主线程一段时间，防止CompletableFuture退出
        Thread.sleep(3000);

        // 返回最先响应检测请求（ping）的节点作为本次处理客户端请求的节点
        return resultServer.getIP();
    }

    public static void main(String[] args) throws InterruptedException {
        for (int i = 1; i <= 5; i++){
            System.out.println("第"+ i + "个请求：" + getServer());
        }
    }
}

/******运行结果：******/
最先响应检测请求的节点为：44.120.110.002:8081
第1个请求：44.120.110.002:8081
最先响应检测请求的节点为：44.120.110.002:8081
第2个请求：44.120.110.002:8081
最先响应检测请求的节点为：44.120.110.003:8082
第3个请求：44.120.110.003:8082
最先响应检测请求的节点为：44.120.110.003:8080
第4个请求：44.120.110.001:8080
最先响应检测请求的节点为：44.120.110.002:8081
第5个请求：44.120.110.002:8081

在该案例中，其实现过程对比之前的算法略微复杂一些，首先在Server实例类中定义了一个Ping()方法，该方法中使用随机数+线程休眠的方式简单模拟了一下节点的不同的响应速度，然后在算法实现类中，利用CompletableFuture分别对每一个节点都创建了对应的Ping任务，然后同时执行，又通过thenAccept()回调方法监听了执行结果，谁最先响应，则取其作为处理本次请求的节点。

这个算法的实现过程中，唯一难理解的就是CompletableFuture，它是JDK8中推出的一种异步任务，具体的可参考之前的并发文章：《CompletableFuture详解》。

这里只是举例实现，所以通过CompletableFuture实现了检测请求，但实际过程中如果要选择这种算法，那么基于Netty会更为合适。

从上述案例的运行结果中也可以得知：最优响应算法无论在何种情况下，都能从集群中选取性能最好的节点对外服务，Nginx中也支持配置这种算法，但需要先安装对应的nginx-upstream-fair模块。

六、请求分发篇总结

   在本文中，对于比较常用的请求分发算法进行了剖析及手写实践，其中提到了较为传统的静态调度算法：轮询、随机、加权、一致性哈希等，也谈到了一些较为智能的动态算法：最小活跃数、最优响应等，但需要牢记的一点是：

并非越智能的算法越好，越是并发高、流量大的场景下，反而选用最基本的算法更合适，例如微信的红包业务，就是采用最基本的轮询算法进行集群调度。

那这又是为何呢？因为越智能的调度算法，进行节点选择时的开销会更大，如果你对于文中给出的调度算法实现都一一运行过，那么大家会明显感知出：越到后面的算法，分发请求的速度越慢。

因此在面临巨大访问压力的情景中，选择最简单的算法反而带来的收益更高，但前提是需要集群中所有的节点硬件配置都一致，所有节点分配的资源都相同，轮询算法则是最佳的调度算法。

你可能感兴趣的:((四)网络编程之请求分发篇：负载均衡静态调度算法、平滑轮询加权、一致性哈希、最小活跃数算法实践！)

  • 铭刻于星（四十二） 随风至
    69夜晚，绍敏同学做完功课后，看了眼房外，没听到动静才敢从书包的夹层里拿出那个心形纸团。折痕压得很深，都有些旧了，想来是已经写好很久了。绍敏同学慢慢地、轻轻地捏开折叠处，待到全部拆开后，又反复抚平纸张，然后仔细地一字字默看。只是开头的三个字是第一次看到，让她心漏跳了几拍。“亲爱的绍敏：从四年级的时候，我就喜欢你了，但是我一直不敢说，怕影响你学习。六年级的时候听说有人跟你表白，你接受了，我很难过，但
  • 2021年12月19日，春蕾教育集团团建活动感受——黄晓丹 黄错错加油
    感受:1.从陌生到熟悉的过程。游戏环节让我们在轻松的氛围中得到了锻炼，也增长了不少知识。2.游戏过程中，我们贡献的是个人力量，展现的是团队的力量。它磨合的往往不止是工作的熟悉，更是观念上契合度的贴近。3.这和工作是一样的道理。在各自的岗位上，每个人摆正自己的位置、各司其职充分发挥才能，并团结一致劲往一处使，才能实现最大的成功。新知:1.团队精神需要不断地创新。过去，人们把创新看作是冒风险，现在人们
  • 扫地机类清洁产品之直流无刷电机控制 悟空胆好小 清洁服务机器人单片机人工智能
    扫地机类清洁产品之直流无刷电机控制1.1前言扫地机产品有很多的电机控制，滚刷电机1个，边刷电机1-2个，清水泵电机，风机一个，部分中高端产品支持抹布功能，也就是存在抹布盘电机，还有追觅科沃斯石头等边刷抬升电机，滚刷抬升电机等的，这些电机有直流有刷电机，直接无刷电机，步进电机，电磁阀，挪动泵等不同类型。电机的原理，驱动控制方式也不行。接下来一段时间的几个文章会作个专题分析分享。直流有刷电机会自动持续
  • 消息中间件有哪些常见类型 xmh-sxh-1314 java
    消息中间件根据其设计理念和用途，可以大致分为以下几种常见类型：点对点消息队列（Point-to-PointMessagingQueues）：在这种模型中，消息被发送到特定的队列中，消费者从队列中取出并处理消息。队列中的消息只能被一个消费者消费，消费后即被删除。常见的实现包括IBM的MQSeries、RabbitMQ的部分使用场景等。适用于任务分发、负载均衡等场景。发布/订阅消息模型（Pub/Sub
  • 那个抄袭的大张伟 猫小努
    最近一直在追《即刻电音》这个综艺，除了觉得出场节目的音乐制作人有意思之外，也觉得有两个导师挺有趣的（另外一个就忽略了吧）。孙艺兴在上一篇文章里面已经说过了，那么这篇就说说我们的大老师，大张伟吧。其实在节目刚开始大张伟出来的时候，我以为他是属于导师里面来活跃气氛负责搞笑的，毕竟孙艺兴属于卖萌卖傻卖老实的，尚雯婕一般负责装逼耍狠的，而大张伟一贯以来上综艺的形象基本上都是蹦蹦跳跳带动气氛的。谁知道，两期
  • 2018-07-23-催眠日作业-#不一样的31天#-66小鹿 小鹿_33
    预言日：人总是在逃避命运的路上，与之不期而遇。心理学上有个著名的名词，叫做自证预言；经济学上也有一个很著名的定律叫做，墨菲定律；在灵修派上，还有一个很著名的法则，叫做吸引力法则。这3个领域的词，虽然看起来不太一样，但是他们都在告诉人们一个现象：你越担心什么，就越有可能会发生什么。同样的道理，你越想得到什么，就应该要积极地去创造什么。无论是自证预言，墨菲定律还是吸引力法则，对人都有正反2个维度的影响
  • 我的烦恼 余建梅
    我的烦恼。女儿问我：“你给学生布置什么作文题目？”“《我的烦恼》。”“他们都这么大了，你觉得他们还有烦恼吗？”“有啊！每个人都会有自己烦恼。”“我不相信，大人是没有烦恼的，如果说一定有的话，你的烦恼和我写作业有关，而且是小烦恼。不像我，天天被你说，有这样的妈妈，烦恼是没完没了。”女儿愤愤不平。每个人都会有自己的烦恼，处在上有老下有小的年纪，烦恼多的数不完。想干好工作带好孩子，想孝顺父母又想经营好自
  • 《大清方方案》| 第二话 谁佐清欢
    和珅究竟说了些什么？竟能令堂堂九五之尊龙颜失色！此处暂且按下不表；单说这位乾隆皇帝，果真不愧是康熙从小带过的，一旦决定了要做的事，便杀伐决断毫不含糊。他当即亲自拟旨，着令和珅为钦差大臣，全权负责处理方方事件，并钦赐尚方宝剑，遇急则三品以下官员可先斩后奏。和珅身负皇上重托，岂敢有半点怠慢，当夜即率领相关人等，马不停蹄杀奔江汉。这一路上，和珅的几位幕僚一直在商讨方方事件的处置方案。有位年轻幕僚建议快刀
  • 回溯 Leetcode 332 重新安排行程 mmaerd Leetcode刷题学习记录leetcode算法职场和发展
    重新安排行程Leetcode332学习记录自代码随想录给你一份航线列表tickets，其中tickets[i]=[fromi,toi]表示飞机出发和降落的机场地点。请你对该行程进行重新规划排序。所有这些机票都属于一个从JFK（肯尼迪国际机场）出发的先生，所以该行程必须从JFK开始。如果存在多种有效的行程，请你按字典排序返回最小的行程组合。例如，行程[“JFK”,“LGA”]与[“JFK”,“LGB
  • Python数据分析与可视化实战指南 William数据分析 pythonpython数据
    在数据驱动的时代，Python因其简洁的语法、强大的库生态系统以及活跃的社区，成为了数据分析与可视化的首选语言。本文将通过一个详细的案例，带领大家学习如何使用Python进行数据分析，并通过可视化来直观呈现分析结果。一、环境准备1.1安装必要库在开始数据分析和可视化之前，我们需要安装一些常用的库。主要包括pandas、numpy、matplotlib和seaborn等。这些库分别用于数据处理、数学
  • 2022-04-18 Apbenz
    语重心长的和我说，不要老是说不行，人至而立之年危机四伏，内在的，外在的，感觉就是心力憔悴，让人无所适从。面对职场的无情，突然好羡慕干体力劳动的外卖小哥。难道命运是想让我去送外卖了吗？干体力活才能让我活下去？fastadmin打卡成功,淘宝金币任务完成。ㅏㅓㅗㅜㅡㅣㅐㅔㅑㅕㅛㅠㅢㅒㅖY行。야자여자요리우유의사얘기예
  • 《庄子.达生9》 钱江潮369
    【原文】孔子观于吕梁，县水三十仞，流沫四十里，鼋鼍鱼鳖之所不能游也。见一丈夫游之，以为有苦而欲死也，使弟子并流而拯之。数百步而出，被发行歌而游于塘下。孔子从而问焉，曰：“吾以子为鬼，察子则人也。请问，‘蹈水有道乎’”曰：“亡，吾无道。吾始乎故，长乎性，成乎命。与齐俱入，与汩偕出，从水之道而不为私焉。此吾所以蹈之也。”孔子曰：“何谓始乎故，长乎性，成乎命？”曰：“吾生于陵而安于陵，故也；长于水而安于
  • 第四天旅游线路预览——从换乘中心到喀纳斯湖 陟彼高冈yu 基于Googleearthstudio的旅游规划和预览旅游
    第四天：从贾登峪到喀纳斯风景区入口，晚上住宿贾登峪；换乘中心有4路车，喀纳斯①号车，去喀纳斯湖，路程时长约5分钟；将上面的的行程安排进行动态展示，具体步骤见”Googleearthstudio进行动态轨迹显示制作过程“、“Googleearthstudio入门教程”和“Googleearthstudio进阶教程“相关内容，得到行程如下所示：Day4-2-480p
  • Goolge earth studio 进阶4——路径修改与平滑 陟彼高冈yu Googleearthstudio进阶教程旅游
    如果我们希望在大约中途时获得更多的城市鸟瞰视角。可以将相机拖动到这里并创建一个新的关键帧。camera_target_clip_7EarthStudio会自动平滑我们的路径，所以当我们通过这个关键帧时，不是一个生硬的角度，而是一个平滑的曲线。camera_target_clip_8路径上有贝塞尔控制手柄，允许我们调整路径的形状。右键单击，我们可以选择“平滑路径”，这是默认的自动平滑算法，或者我们可
  • LLM 词汇表 落难Coder LLMsNLP大语言模型大模型llama人工智能
    Contextwindow“上下文窗口”是指语言模型在生成新文本时能够回溯和参考的文本量。这不同于语言模型训练时所使用的大量数据集，而是代表了模型的“工作记忆”。较大的上下文窗口可以让模型理解和响应更复杂和更长的提示，而较小的上下文窗口可能会限制模型处理较长提示或在长时间对话中保持连贯性的能力。Fine-tuning微调是使用额外的数据进一步训练预训练语言模型的过程。这使得模型开始表示和模仿微调数
  • 我的黑历史 袖手围观有来有去
    孩子同学与我们一起共进晚餐，俩孩子加我三个人。小同学是一个大方率性礼貌的小孩，我们也都非常喜欢。好了，回到正题上来让我把这个故事讲完。俩孩子都喜欢吃鱼，所以就发生了小孩子之间常会发生的事。我狠狠的盯了我家孩子，孩子表情有些狼狈。和孩子单独一起的时候，见她尚未释怀，并谴责我不该狠盯她，让她没面子。也许是她触动了我的童年往事吧。由此，一狠心，给她讲了一段埋藏心里极深的黑历史：我奶奶有四个儿子，四个儿子
  • 509. 斐波那契数(每日一题) lzyprime
    lzyprime博客(github)创建时间：2021.01.04qq及邮箱：2383518170leetcode笔记题目描述斐波那契数，通常用F(n)表示，形成的序列称为斐波那契数列。该数列由0和1开始，后面的每一项数字都是前面两项数字的和。也就是：F(0)=0，F(1)=1F(n)=F(n-1)+F(n-2)，其中n>1给你n，请计算F(n)。示例1：输入：2输出：1解释：F(2)=F(1)+
  • 关于提高复杂业务逻辑代码可读性的思考 编程经验分享 开发经验java数据库开发语言
    目录前言需求场景常规写法拆分方法领域对象总结前言实际工作中大部分时间都是在写业务逻辑，一般都是三层架构，表示层（Controller）接收客户端请求，并对入参做检验，业务逻辑层（Service）负责处理业务逻辑，一般开发都是在这一层中写具体的业务逻辑。数据访问层（Dao）是直接和数据库交互的，用于查数据给业务逻辑层，或者是将业务逻辑层处理后的数据写入数据库。简单的增删改查接口不用多说，基本上写好一
  • 18-115 一切思考不能有效转化为行动，都TM是扯淡！ 成长时间线
    7月25号写了一篇关于为什么会断更如此严重的反思，然而，之后日更仅仅维持了一周，又出现了这次更严重的现象。从8月2号到昨天8月6号，5天！又是5天没有更文！虽然这次断更时间和上次一样，那为什么说这次更严重？因为上次之后就分析了问题的原因，以及应该如何解决，按理说应该会好转，然而，没过几天严重断更的现象再次出现，想想，经过反思，问题依然没有解决与改变，这让我有些担忧。到底是哪里出了问题，难道我就真的
  • 直返最高等级与直返APP：无需邀请码的返利新体验 古楼
    随着互联网的普及和电商的兴起，直返模式逐渐成为一种流行的商业模式。在这种模式下，消费者通过购买产品或服务，获得一定的返利，并可以分享给更多的人。其中，直返最高等级和直返APP是直返模式中的重要概念和工具。本文将详细介绍直返最高等级的概念、直返APP的使用以及与邀请码的关系。【高省】APP（高佣金领导者）是一个自用省钱佣金高，分享推广赚钱多的平台，百度有几百万篇报道，运行三年，稳定可靠。高省APP，
  • 四章-32-点要素的聚合 彩云飘过
    本文基于腾讯课堂老胡的课《跟我学Openlayers--基础实例详解》做的学习笔记，使用的openlayers5.3.xapi。源码见1032.html，对应的官网示例https://openlayers.org/en/latest/examples/cluster.htmlhttps://openlayers.org/en/latest/examples/earthquake-clusters.
  • DIV+CSS+JavaScript技术制作网页（旅游主题网页设计与制作）云南大理 STU学生网页设计 网页设计期末网页作业html静态网页html5期末大作业网页设计web大作业
    ️精彩专栏推荐作者主页:【进入主页—获取更多源码】web前端期末大作业：【HTML5网页期末作业(1000套)】程序员有趣的告白方式：【HTML七夕情人节表白网页制作(110套)】文章目录二、网站介绍三、网站效果▶️1.视频演示2.图片演示四、网站代码HTML结构代码CSS样式代码五、更多源码二、网站介绍网站布局方面：计划采用目前主流的、能兼容各大主流浏览器、显示效果稳定的浮动网页布局结构。网站程
  • 高端密码学院笔记285 柚子_b4b4
    高端幸福密码学院（高级班）幸福使者：李华第（598）期《幸福》之回归内在深层生命原动力基础篇——揭秘“激励”成长的喜悦心理案例分析主讲：刘莉一，知识扩充:成功=艰苦劳动+正确方法+少说空话。贪图省力的船夫，目标永远下游。智者的梦再美，也不如愚人实干的脚印。幸福早课堂2020.10.16星期五一笔记:1，重视和珍惜的前提是知道它的价值非常重要，当你珍惜了，你就真正定下来，真正的学到身上。2，大家需要
  • 2020-04-12每天三百字之连接与替代 冷眼看潮
    不知道是不是好为人师，有时候还真想和别人分享一下我对某些现象的看法或者解释。人类社会不断发展进步的过程，就是不断连接与替代的过程。人类发现了火并应用火以后，告别了茹毛饮血的野兽般的原始生活（火烧、烹饪替代了生食）人类用石器代替了完全手工，工具的使用使人类进步一大步。类似这样的替代还有很多，随着科技的发展，有更多的原始的事物被替代，代之以更高效、更先进的技术。在近现代，汽车替代了马车，高速公路和铁路
  • 利用Requests Toolkit轻松完成HTTP请求 nseejrukjhad http网络协议网络python
    RequestsToolkit的力量：轻松构建HTTP请求Agent在现代软件开发中，API请求是与外部服务交互的核心。RequestsToolkit提供了一种便捷的方式，帮助开发者构建自动化的HTTP请求Agent。本文旨在详细介绍RequestsToolkit的设置、使用和潜在挑战。引言RequestsToolkit是一个强大的工具包，可用于构建执行HTTP请求的智能代理。这对于想要自动化与外
  • 想明白这个问题，你才能写下去 文自拾
    春节放假的时候，又有一天梦见她，第二天她冒着漫天大雪，傻傻地跑来见我。她说，见见傻傻的我，天很冷，心很暖。她回去后，我写了一篇文章，题目叫——从此梦中只有你。我们没在一起的很长一段时间里，她都在我的心底，一次次出现在我的梦里。我对她说，在一起之前，是胆小且闷骚，在一起之后，我变得不要脸了。不要脸的——去爱你。那文章没写完，火车上，给她看了。我有点小失望，花了好几个小时写，她分分钟就看完，很希望她逐
  • 东南林氏之九牧林候选父系 祖缘树TheYtree
    渊源介绍东晋初年晋安林始祖林禄公入闽，传十世隋右丞林茂，由晋安迁居莆田北螺村。又五世而至林万宠，唐开元间任高平太守，生三子：韬、披、昌。韬公之孙攒，唐德宗立双阙以旌表其孝，时号"阙下林家"。昌公字茂吉，乃万宠公第三子，官兵部司马，配宋氏，生一子名萍。萍于唐贞元间明经及第，官沣洲司马(后追赠中宪大夫)。唐太和年间归隐后，迁居仙游游洋，世称“游洋林”；其后裔居游洋后迁移漳州漳浦路下，由路下林第四房平和
  • git - Webhook让部署自动化 大猪大猪
    我们现在有一个需求，将项目打包上传到gitlab或者github后，程序能自动部署，不用手动地去服务器中进行项目更新并运行，如何做到？这里我们可以使用gitlab与github的挂钩，挂钩的原理就是，每当我们有请求到gitlab与github服务器时，这时他俩会根据我们配置的挂钩地扯进行访问，webhook挂钩程序会一直监听着某个端口请求，一但收到他们发过来的请求，这时就知道用户有请求提交了，这时
  • 【目标检测数据集】卡车数据集1073张VOC+YOLO格式 熬夜写代码的平头哥∰ 目标检测YOLO人工智能
    数据集格式：PascalVOC格式+YOLO格式(不包含分割路径的txt文件，仅仅包含jpg图片以及对应的VOC格式xml文件和yolo格式txt文件)图片数量(jpg文件个数)：1073标注数量(xml文件个数)：1073标注数量(txt文件个数)：1073标注类别数：1标注类别名称:["truck"]每个类别标注的框数：truck框数=1120总框数：1120使用标注工具：labelImg标注
  • 【JS】执行时长(100分) |思路参考+代码解析（C++） l939035548 JS算法数据结构c++
    题目为了充分发挥GPU算力，需要尽可能多的将任务交给GPU执行，现在有一个任务数组，数组元素表示在这1秒内新增的任务个数且每秒都有新增任务。假设GPU最多一次执行n个任务，一次执行耗时1秒，在保证GPU不空闲情况下，最少需要多长时间执行完成。题目输入第一个参数为GPU一次最多执行的任务个数，取值范围[1,10000]第二个参数为任务数组长度，取值范围[1,10000]第三个参数为任务数组，数字范围
  • Nginx负载均衡 510888780 nginx应用服务器
    Nginx负载均衡一些基础知识: nginx 的 upstream目前支持 4 种方式的分配 1)、轮询（默认）       每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 2)、weight       指定轮询几率，weight和访问比率成正比
  • RedHat 6.4 安装 rabbitmq bylijinnan erlangrabbitmqredhat
    在 linux 下安装软件就是折腾，首先是测试机不能上外网要找运维开通，开通后发现测试机的 yum 不能使用于是又要配置 yum 源，最后安装 rabbitmq 时也尝试了两种方法最后才安装成功 机器版本： [root@redhat1 rabbitmq]# lsb_release LSB Version: :base-4.0-amd64:base-4.0-noarch:core
  • FilenameUtils工具类 eksliang FilenameUtilscommon-io
    转载请出自出处：http://eksliang.iteye.com/blog/2217081 一、概述 这是一个Java操作文件的常用库，是Apache对java的IO包的封装，这里面有两个非常核心的类FilenameUtils跟FileUtils，其中FilenameUtils是对文件名操作的封装;FileUtils是文件封装，开发中对文件的操作，几乎都可以在这个框架里面找到。 非常的好用。
  • xml文件解析SAX 不懂事的小屁孩 xml
    xml文件解析:xml文件解析有四种方式， 1.DOM生成和解析XML文档(SAX是基于事件流的解析) 2.SAX生成和解析XML文档(基于XML文档树结构的解析) 3.DOM4J生成和解析XML文档 4.JDOM生成和解析XML 本文章用第一种方法进行解析，使用android常用的DefaultHandler import org.xml.sax.Attributes;
  • 通过定时任务执行mysql的定期删除和新建分区，此处是按日分区 酷的飞上天空 mysql
    使用python脚本作为命令脚本，linux的定时任务来每天定时执行 #!/usr/bin/python # -*- coding: utf8 -*- import pymysql import datetime import calendar #要分区的表 table_name = 'my_table' #连接数据库的信息 host,user,passwd,db =
  • 如何搭建数据湖架构？听听专家的意见 蓝儿唯美 架构
    Edo Interactive在几年前遇到一个大问题：公司使用交易数据来帮助零售商和餐馆进行个性化促销，但其数据仓库没有足够时间去处理所有的信用卡和借记卡交易数据  “我们要花费27小时来处理每日的数据量，”Edo主管基础设施和信息系统的高级副总裁Tim Garnto说道：“所以在2013年，我们放弃了现有的基于PostgreSQL的关系型数据库系统，使用了Hadoop集群作为公司的数
  • spring学习——控制反转与依赖注入 a-john spring
           控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是轻量级的Spring框架的核心。 控制反转一般分为两种类型，依赖注入（Dependency Injection，简称DI）和依赖查找（Dependency Lookup）。依赖注入应用比较广泛。  
  • 用spool+unixshell生成文本文件的方法 aijuans xshell
    例如我们把scott.dept表生成文本文件的语句写成dept.sql,内容如下: 　　set pages 50000; 　　set lines 200; 　　set trims on; 　　set heading off; 　　spool /oracle_backup/log/test/dept.lst; 　　select deptno||','||dname||','||loc
  • 1、基础--名词解析(OOA/OOD/OOP) asia007 学习基础知识
    OOA:Object-Oriented Analysis（面向对象分析方法） 是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。 　　OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）
  • 浅谈java转成json编码格式技术 百合不是茶 json编码java转成json编码
    json编码;是一个轻量级的数据存储和传输的语言       在java中需要引入json相关的包,引包方式在工程的lib下就可以了   JSON与JAVA数据的转换（JSON 即 JavaScript Object Natation，它是一种轻量级的数据交换格式，非   常适合于服务器与 JavaScript 之间的数据的交
  • web.xml之Spring配置(基于Spring+Struts+Ibatis) bijian1013 javaweb.xmlSSIspring配置
    指定Spring配置文件位置 <context-param> <param-name>contextConfigLocation</param-name> <param-value> /WEB-INF/spring-dao-bean.xml,/WEB-INF/spring-resources.xml, /WEB-INF/
  • Installing SonarQube（Fail to download libraries from server） sunjing InstallSonar
    1.  Download and unzip the SonarQube distribution 2.  Starting the Web Server The default port is "9000" and the context path is "/". These values can be changed in &l
  • 【MongoDB学习笔记十一】Mongo副本集基本的增删查 bit1129 mongodb
    一、创建复本集   假设mongod,mongo已经配置在系统路径变量上，启动三个命令行窗口，分别执行如下命令：   mongod --port 27017 --dbpath data1 --replSet rs0 mongod --port 27018 --dbpath data2 --replSet rs0 mongod --port 27019 -
  • Anychart图表系列二之执行Flash和HTML5渲染 白糖_ Flash
    今天介绍Anychart的Flash和HTML5渲染功能   HTML5 Anychart从6.0第一个版本起，已经逐渐开始支持各种图的HTML5渲染效果了，也就是说即使你没有安装Flash插件，只要浏览器支持HTML5，也能看到Anychart的图形（不过这些是需要做一些配置的）。 这里要提醒下大家，Anychart6.0版本对HTML5的支持还不算很成熟，目前还处于
  • Laravel版本更新异常4.2.8-> 4.2.9 Declaration of ... CompilerEngine ... should be compa bozch laravel
    昨天在为了把laravel升级到最新的版本，突然之间就出现了如下错误： ErrorException thrown with message "Declaration of Illuminate\View\Engines\CompilerEngine::handleViewException() should be compatible with Illuminate\View\Eng
  • 编程之美-NIM游戏分析-石头总数为奇数时如何保证先动手者必胜 bylijinnan 编程之美
    import java.util.Arrays; import java.util.Random; public class Nim { /**编程之美 NIM游戏分析 问题： 有N块石头和两个玩家A和B，玩家A先将石头随机分成若干堆，然后按照BABA...的顺序不断轮流取石头， 能将剩下的石头一次取光的玩家获胜，每次取石头时，每个玩家只能从若干堆石头中任选一堆，
  • lunce创建索引及简单查询 chengxuyuancsdn 查询创建索引lunce
    import java.io.File; import java.io.IOException; import org.apache.lucene.analysis.Analyzer; import org.apache.lucene.analysis.standard.StandardAnalyzer; import org.apache.lucene.document.Docume
  • [IT与投资]坚持独立自主的研究核心技术 comsci it
           和别人合作开发某项产品....如果互相之间的技术水平不同,那么这种合作很难进行,一般都会成为强者控制弱者的方法和手段.....        所以弱者,在遇到技术难题的时候,最好不要一开始就去寻求强者的帮助,因为在我们这颗星球上,生物都有一种控制其
  • flashback transaction闪回事务查询 daizj oraclesql闪回事务
       闪回事务查询有别于闪回查询的特点有以下3个： （1）其正常工作不但需要利用撤销数据，还需要事先启用最小补充日志。 （2）返回的结果不是以前的“旧”数据，而是能够将当前数据修改为以前的样子的撤销SQL（Undo SQL）语句。 （3）集中地在名为flashback_transaction_query表上查询，而不是在各个表上通过“as of”或“vers
  • Java I/O之FilenameFilter类列举出指定路径下某个扩展名的文件 游其是你 FilenameFilter
    这是一个FilenameFilter类用法的例子，实现的列举出“c:\\folder“路径下所有以“.jpg”扩展名的文件。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
  • C语言学习五函数，函数的前置声明以及如何在软件开发中合理的设计函数来解决实际问题 dcj3sjt126com c
    # include <stdio.h> int f(void) //括号中的void表示该函数不能接受数据，int表示返回的类型为int类型 { return 10; //向主调函数返回10 } void g(void) //函数名前面的void表示该函数没有返回值 { //return 10; //error 与第8行行首的void相矛盾 } in
  • 今天在测试环境使用yum安装，遇到一个问题： Error: Cannot retrieve metalink for repository: epel. Pl dcj3sjt126com centos
    今天在测试环境使用yum安装，遇到一个问题： Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again   处理很简单，修改文件“/etc/yum.repos.d/epel.repo”， 将baseurl的注释取消， mirrorlist注释掉。即可。 &n
  • 单例模式 shuizhaosi888 单例模式
    单例模式      懒汉式 public class RunMain { /** * 私有构造 */ private RunMain() { } /** * 内部类，用于占位，只有 */ private static class SingletonRunMain { priv
  • Spring Security（09）——Filter 234390216 Spring Security
    Filter 目录 1.1     Filter顺序 1.2     添加Filter到FilterChain 1.3     DelegatingFilterProxy 1.4     FilterChainProxy 1.5
  • 公司项目NODEJS实践0.1 逐行分析JS源代码 mongodbnginxubuntunodejs
      一、前言         前端如何独立用nodeJs实现一个简单的注册、登录功能，是不是只用nodejs+sql就可以了？其实是可以实现，但离实际应用还有距离，那要怎么做才是实际可用的。         网上有很多nod
  • java.lang.Math liuhaibo_ljf javaMathlang
    System.out.println(Math.PI); System.out.println(Math.abs(1.2)); System.out.println(Math.abs(1.2)); System.out.println(Math.abs(1)); System.out.println(Math.abs(111111111)); System.out.println(Mat
  • linux下时间同步 nonobaba ntp
    今天在linux下做hbase集群的时候，发现hmaster启动成功了，但是用hbase命令进入shell的时候报了一个错误  PleaseHoldException: Master is initializing，查看了日志，大致意思是说master和slave时间不同步，没办法，只好找一种手动同步一下，后来发现一共部署了10来台机器，手动同步偏差又比较大，所以还是从网上找现成的解决方
  • ZooKeeper3.4.6的集群部署 roadrunners zookeeper集群部署
    ZooKeeper是Apache的一个开源项目，在分布式服务中应用比较广泛。它主要用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步、集群管理、配置文件管理、同步锁、队列等。这里主要讲集群中ZooKeeper的部署。   1、准备工作 我们准备3台机器做ZooKeeper集群，分别在3台机器上创建ZooKeeper需要的目录。   数据存储目录
  • Java高效读取大文件 tomcat_oracle java
    　　读取文件行的标准方式是在内存中读取，Guava 和Apache Commons IO都提供了如下所示快速读取文件行的方法： 　　Files.readLines(new File(path), Charsets.UTF_8); 　　FileUtils.readLines(new File(path)); 　　这种方法带来的问题是文件的所有行都被存放在内存中，当文件足够大时很快就会导致
  • 微信支付api返回的xml转换为Map的方法 xu3508620 xmlmap微信api
    举例如下： <xml>    <return_code><![CDATA[SUCCESS]]></return_code>    <return_msg><![CDATA[OK]]></return_msg>    <appid><
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他