自古帝王多短命,假如皇帝也懂负载均衡算法...
苏静   51CTO艺术栈   2020-01-16

【51CTO.com原创稿件】大家都晓得古代皇帝各个都是后宫佳丽三千,而皇帝身上都天然之带着雨露均沾的旺盛,不想单独的宠爱一人口!

 

图表来自 Pexels

弱水三千,又怎舍得只取一瓢饮?据传皇帝们晚上睡觉个个都怕冷,故此每晚都要求有人侍寝,这就是说这么多后宫,该翻谁牌子、怎么分配侍寝名额呢?

还别说,当今行房事竟还挺讲究的!早在《寒暑》就有记载“晦阴惑疾,明谣心疾,以辟六气”。

九嫔以下,每九人口中进御一人口,八十一女御占九个晚上,世妇二十七人口占三个晚上,九嫔占一个晚上,三夫人占一个晚上,上述共十四夜,皇后独占一个晚上,共十五夜。上半个月按上述安排进御,从半个月从十六日开始,由皇后起,再御九嫔、世妇、女御,与月亮由盛而衰相对应......

不同朝代的王者也有不同宠幸妃子的主意,享誉的有羊车望幸、掷筛侍寝、蝶幸、翻牌悬灯等等。

不过在我瞅来,如果皇帝懂负载均衡算法的话,大可不要这么折腾,一套作法便可搞定终身侍寝大事!故此我们今天来介绍几种备用的载荷均衡算法及代码实现!

先看下文章的纲领:

  • 轮询书法
  • 加权轮询书法
  • 随机算法
  • 加权随机算法
  • 源地址 hash 书法
  • 竞争性 hash 书法
  • 轮询书法

    据资料记载,乾隆一生妃嫔就有 42 人口,还不算大明湖畔的夏雨荷等在从江南时候留下的情。

     

    假设在某个时期内,皇阿玛最宠幸的有令妃、娴妃、高贵妃、纯妃四位。那普通的轮询书法怎么去选择呢?

    咱们先定义一个妃子集合如下:

         
    1. /** 
    2.  * *整整妃子集合 
    3.  */ 
    4. public static final List<String> PRINCESS_LIST = Arrays.asList("令妃""娴妃""高贵妃""纯妃"); 

    下一场从列表中轮询侍寝的妃子,用一个变量 index 扮演记录轮询之岗位。

         
    1. // 记录循环的岗位 
    2. private static Integer index = 0; 
    3. public static void main(String[] args) { 
    4.     for (int i = 0; i < 10; i++) { 
    5.         System.out.println(getPrincess()); 
    6.     } 
    7. private static String getPrincess() { 
    8.     // 超过数组大小需要归零(每次获取前判断,防止配置变化导致索引越界) 
    9.     if (index >= PrincessConfig.PRINCESS_LIST.size()) { 
    10.         index = 0; 
    11.     } 
    12.     String princess = PrincessConfig.PRINCESS_LIST.get(index); 
    13.     index++; 
    14.     return princess; 

    进出口结果就不贴出来了。该疗法的性状就是简单、大概、大概!但是也存在很大缺点!

    如果皇帝更宠爱令妃,想让他侍寝的概率更高呢?那就要求用到下的加权轮询书法!

    加权轮询书法

    加权轮询就是可以主观的送每个妃子设置一个喜好值(权重值),以控制被选中的概率,故此我们需要定义如下的安排:

         
    1. /** 
    2.  * *整整妃子集合 
    3.  */ 
    4. public static final Map<String, Integer> PRINCESS_MAP = new LinkedHashMap<String, Integer>() { 
    5.     { 
    6.         put("令妃", 5); 
    7.         put("娴妃", 1); 
    8.         put("高贵妃", 3); 
    9.         put("纯妃", 2); 
    10.     } 
    11. }; 

    此地的安排就不再是简单的一个集合,每个妃子都对应了一番权重值,那轮询之时节怎么根据这个值去提高被选中的概率呢?

    下我们来讲三种比较广泛的贯彻。

    加权轮询实现一

    咱们的笔触是把这个 map 的 key(妃子)根据权重值转存到一个 list 官方,下一场再扮轮询这个 list,如果权重值为 5,那就在 list 官方添加 5 条相同的记录!

    下一场我们去遍历这个 list,这样权重值越高,在 list 官方出现的概率就越高,把轮询中的概率也就越高!

         
    1. // 记录循环的岗位 
    2. private static Integer index = 0; 
    3.  
    4. public static void main(String[] args) { 
    5.    for (int i = 0; i < 11; i++) { 
    6.        System.out.println(getPrincess1()); 
    7.   } 
    8.  
    9. private static String getPrincess1() { 
    10.  
    11.    // 遍历map放入到list官方 
    12.    List<String> princessList = new ArrayList<String>(); 
    13.    for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    14.        int weight = PrincessConfig.PRINCESS_MAP.get(princess); 
    15.        // 根据权重值重复放入到一个list官方 
    16.        for (int i = 0; i < weight; i++) { 
    17.            princessList.add(princess); 
    18.       } 
    19.   } 
    20.  
    21.    if (index >= princessList.size()) { 
    22.        index = 0; 
    23.   } 
    24.    String princess = princessList.get(index); 
    25.  
    26.    index++; 
    27.  
    28.    return princess; 

    进出口结果如下:

     

    该加权轮询书法比较简便,比起容易实现。但是也有个问题,咱们配备的权重值是 5、1、3、2,那我们是不是也得以配置成 50、10、30、20 呢?

    那按照地方的措施,咱们是不是就要求把同样的要素往 list 其中放几百个呢?这显然是比较不合理且耗内存的!

    加权轮询实现二

    基于上面的作法存在的题材,咱们考虑用类似占比之措施来处理。

    比如我们配备的权重值为 50、10、30、20,那在横坐标上表示就是 0_____50_60__80__110。

    咱们还是用一个 index 扮演记录轮询之岗位,如果 index 在 0~50 之间就代替第一个妃子被选中,如果在 50~60 之间就代替第二个妃子被选中......

    咱们看具体代码实现:

         
    1. // 记录循环的岗位 
    2. private static Integer indexInteger = 0; 
    3.  
    4. public static void main(String[] args) { 
    5.    for (int i = 0; i < 11; i++) { 
    6.        System.out.println(getPrincess2()); 
    7.   } 
    8.  
    9. private static String getPrincess2() { 
    10.    //记录总权重值 
    11.    int totalWeight = 0; 
    12.    for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    13.        int weight = PrincessConfig.PRINCESS_MAP.get(princess); 
    14.        totalWeight += weight; 
    15.   } 
    16.  
    17.    // 归零 
    18.    if (indexInteger >= totalWeight) { 
    19.        indexInteger = 0; 
    20.   } 
    21.  
    22.    int index = indexInteger; 
    23.    String result = null
    24.    for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    25.        int weight = PrincessConfig.PRINCESS_MAP.get(princess); 
    26.  
    27.        // 落在当前区间 直接返回 
    28.        if (index < weight) { 
    29.  
    30.            result = princess; 
    31.            break; 
    32.       } 
    33.  
    34.        // 没有落在当前区间 继承循环 
    35.        index = index - weight; 
    36.  
    37.   } 
    38.  
    39.    indexInteger++; 
    40.    return result; 

    进出口结果与地方的主意一毛一样:

     

    该加权轮询书法略复杂于重点种,但是这两种实现都存在的共同问题是,按照我们当前的安排去轮询会继续 5 先后令妃、再 1 先后娴妃、再 3 先后高贵妃......

    继续 5 先后!就算皇阿玛再喜欢令妃,怕是令妃也有点吃不消!用电脑术语说也就是负载不是很均衡!

    加权轮询实现三(平滑加权轮询)

    平滑加权轮询书法就是为了消灭上面负载不均的状况之,该疗法实现起来相对比较复杂!

    每个妃子不仅有一度权重值(weight),还有一个会转变的常态权重值(dynamicWeight)来帮助计算。

    动态权重值计算逻辑如下:

  • 动态权重值 dynamicWeight 初步为 0。
  • 每次获取轮询获取目标妃子时先设置 dynamicWeight=dynamicWeight+weight。
  • 下一场找到所有妃子中动态权重值 dynamicWeight 最大的一个,则为此次轮询到的对象。
  • 名将本次轮询到的对象的 dynamicWeight 安装为 dynamicWeight-totalWeight(总权重值)。
  • 这样看可能会有点不是很清楚,咱们来做个推算,假设我们还是有如下配置(安排中只有妃子名称及对应的权重值):

         
    1. /** 
    2.  * *整整妃子集合 
    3.  */ 
    4. public static final Map<String, Integer> PRINCESS_MAP = new LinkedHashMap<String, Integer>() { 
    5.     { 
    6.         put("令妃", 5); 
    7.         put("娴妃", 1); 
    8.         put("高贵妃", 3); 
    9.         put("纯妃", 2); 
    10.     } 
    11. }; 

    在地方的安排中总权重值 totalWeight=5+1+3+2 等于 11。

    ①按照地方算法的首要线,在重要次轮询目标之前她们的 dynamicWeight 都是0。

    因此四位妃子的 weight 和 dynamicWeight 值如下:

     

    ②按照地方算法的第二线,在重要次轮询选中目标的时节 dynamicWeight=dynamicWeight+weight。

    扭转后四位妃子的 weight 和 dynamicWeight 值如下:

     

    ③按照地方算法的程序三线,下一场找最大的 dynamicWeight,也就是 5,因此第一次轮询选中的就是令妃。

    ④按照地方算法的程序四线,令妃之 dynamicWeight 要求减去 totalWeight。

    扭转后四位妃子的 weight 和 dynamicWeight 值如下:

     

    下一场第二次轮询的时节又要求按照算法的首要线设置 dynamicWeight。

    安装后四位妃子的 weight 和 dynamicWeight 值如下:

     

    就这样一直按照算法处理下去,轮询完 11 先后之后,整整妃子的 dynamicWeight 又会全部变为 0......

    如果大家依然还是有点模糊,咱们只能上代码为敬了!咱们需要先定义一个实体,来存放每个妃子及对应的 weight 及 dynamicWeight 属性:

         
    1. /** 
    2.  * *权重实体 
    3.  *  
    4.  * @author sullivan 
    5.  * 
    6.  */ 
    7. public class PrincessWeight { 
    8.     private String princess; 
    9.     private Integer weight; 
    10.     private Integer dynamicWeight; 
    11.     public PrincessWeight(String princess, Integer weight, Integer dynamicWeight) { 
    12.         super(); 
    13.         this.princess = princess; 
    14.         this.weight = weight; 
    15.         this.dynamicWeight = dynamicWeight; 
    16.     } 

    下一场定义两个全局的目标存放对象:

         
    1. // 每个妃子及对应的权重实体 
    2. private static Map<String, PrincessWeight> weightMap = new HashMap<String, PrincessWeight>(); 
    3. // 总权重值 
    4. private static int totalWeight = 0; 

    再进行书法的贯彻:

         
    1. private static String getPrincess() {     
    2.     // 初始化妃子及对应的权重实体 
    3.     if (weightMap.isEmpty()) { 
    4.         //名将安排初始化到map官方扮 
    5.         for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    6.             // 书法的首要线:初步dynamicWeight为0 
    7.             weightMap.put(princess, new PrincessWeight(princess, PrincessConfig.PRINCESS_MAP.get(princess), 0)); 
    8.             totalWeight += PrincessConfig.PRINCESS_MAP.get(princess); 
    9.         } 
    10.     } 
    11.  
    12.     // 书法的第二线:安装currentWeight=安装weight+currentWeight 
    13.     for (PrincessWeight weight : weightMap.values()) { 
    14.         weight.setDynamicWeight(weight.getWeight() + weight.getDynamicWeight()); 
    15.     } 
    16.  
    17.     // 书法的程序三线:追寻最大的currentWeight 
    18.     PrincessWeight maxPrincessWeight = null
    19.     for (PrincessWeight weight : weightMap.values()) { 
    20.         if (maxPrincessWeight == null || weight.getDynamicWeight() > maxPrincessWeight.getDynamicWeight()) { 
    21.             maxPrincessWeight = weight; 
    22.         } 
    23.     } 
    24.  
    25.     // 书法的程序四线:最大的dynamicWeight = dynamicWeight-totalWeight 
    26.     maxPrincessWeight.setDynamicWeight(maxPrincessWeight.getDynamicWeight() - totalWeight); 
    27.  
    28.     return maxPrincessWeight.getPrincess(); 

    末了输出如下:

     

    这样经过 11 先后轮询,令妃同样出现了 5 先后,但是明显不会再像之前算法那样连续出现了,会均衡得多!!!如果还有不知晓的,可以去文末之 Github 地点上下载代码自己调试及理解!

    随机算法

    平滑加权轮询书法能很好的开展负载了!但是皇阿玛又说了,按照轮询书法,我自己都能够生产来每晚侍寝的妃子,不刺激不刺激。

    当今嘛,总喜欢来些新鲜的刺激的我们也得以了解!还好我们有随机算法可以解决,夜间都是随机选一个,让皇帝无法提前推测,送皇帝足够的刺激感!

    咱们依然先定义一个妃子集合如下:

         
    1. /** 
    2.  * *整整妃子集合 
    3.  */ 
    4. public static final List<String> PRINCESS_LIST = Arrays.asList("令妃""娴妃""高贵妃""纯妃"); 

    下一场利用随机函数去选择一个目标:

         
    1. public static void main(String[] args) { 
    2.     for (int i = 0; i < 10; i++) { 
    3.         System.out.println(getPrincess()); 
    4.     } 
    5. /** 
    6.  * *随机获取侍寝妃子 
    7.  * @return 
    8.  */ 
    9. private static String getPrincess() { 
    10.     SecureRandom rd = new SecureRandom(); 
    11.     int index = rd.nextInt(PrincessConfig.PRINCESS_LIST.size()); 
    12.     return PrincessConfig.PRINCESS_LIST.get(index); 

    因为输出是随机的,故此这里就不贴出来了。如果明白了轮询书法,随机算法理解起来也就简单了,是不是在轮询中用一个全局的 index 扮演保存每次循环的岗位,而在随机中是每次去随机出来一下值。

    加权随机算法

    加权随机实现一

    加权随机实现一与地方的加权轮询实现一之笔触几乎一毛一样,此地就直接上代码了:

         
    1. public static void main(String[] args) { 
    2.         for (int i = 0; i < 10; i++) { 
    3.             System.out.println(getPrincess()); 
    4.         } 
    5.     } 
    6. private static String getPrincess() { 
    7.     List<String> princessList = new ArrayList<String>(); 
    8.     for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    9.         int weight = PrincessConfig.PRINCESS_MAP.get(princess); 
    10.         for (int i = 0; i < weight; i++) { 
    11.             princessList.add(princess); 
    12.         } 
    13.     } 
    14.     Random rd = new Random(); 
    15.     int index = rd.nextInt(princessList.size()); 
    16.     return princessList.get(index); 

    加权随机实现二

    加权随机实现二与地方的加权轮询实现二之笔触几乎一模一样,此地也就直接上代码了:

         
    1. public static void main(String[] args) { 
    2.     for (int i = 0; i < 10; i++) { 
    3.         System.out.println(getPrincess2()); 
    4.     } 
    5.  
    6. private static String getPrincess2() { 
    7.  
    8.     List<String> princessList = new ArrayList<String>(); 
    9.     int totalWeight = 0; 
    10.     for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    11.         int weight = PrincessConfig.PRINCESS_MAP.get(princess); 
    12.         totalWeight += weight; 
    13.         for (int i = 0; i < weight; i++) { 
    14.             princessList.add(princess); 
    15.         } 
    16.     } 
    17.  
    18.     Random rd = new Random(); 
    19.     int index = rd.nextInt(totalWeight); 
    20.  
    21.     String result = null
    22.     for (String princess : PrincessConfig.PRINCESS_MAP.keySet()) { 
    23.         int weight = PrincessConfig.PRINCESS_MAP.get(princess); 
    24.  
    25.         // 落在当前区间 直接返回 
    26.         if (index < weight) { 
    27.  
    28.             result = princess; 
    29.             break; 
    30.         } 
    31.  
    32.         // 没有落在当前区间 继承循环 
    33.         index = index - weight; 
    34.  
    35.     } 
    36.     return result; 

    源地址 hash 书法

    咱们的上班中开发体系很常见的一个需要就是要求登录后才能走访,这就会涉及到 session!

    如果我们没有做 session 共享,那登录后的 session 消息只会存在我们调用登录接口的那台服务器上!

    按照前面的轮询书法或者随机算法,咱们同一客户端的多次请求就会落在不同之蒸发器上,这样就会导致部分接口没权限访问!

    故此我们需要同一个客户端多次之呼吁落在同一台服务器上,此地常见的一种书法是对源地址进行 hash!

    到此处我们也得让咱的皇阿玛歇会儿了,返回我们正常的工作场景中。假如我们有服务器配置如下:

         
    1. /** 
    2.      * *整整服务器集合 
    3.      */ 
    4.     public static final List<String> SERVER_IP_LIST = Arrays.asList( 
    5.         "192.168.1.10",  
    6.         "192.168.2.20",  
    7.         "192.168.3.30",  
    8.         "192.168.4.40"); 

    客户端访问的 ip 我也模拟了一番集合:

         
    1. /** 
    2.      * *客户端ip 
    3.      */ 
    4.     public static final List<String> CLIENT_IP_LIST = Arrays.asList( 
    5.         "113.88.97.173",  
    6.         "106.11.154.33",  
    7.         "207.46.13.149"
    8.         "42.156.137.120",  
    9.         "203.208.60.0",  
    10.         "119.39.47.182",  
    11.         "171.34.179.4",  
    12.         "111.175.58.52",  
    13.         "124.235.138.199"
    14.         "175.184.166.184"); 

    源地址 hash 书法的笔触就是对客户端的 ip 拓展 hash,下一场用 hash 值与服务器的多寡进行取模,得到需要访问的蒸发器的 ip。只要客户端 ip 有序,那 hash 此后的值就是固定的!

    贯彻如下:

         
    1. public static void main(String[] args) { 
    2.         for (String clientIp : CLIENT_IP_LIST) { 
    3.             int index = Math.abs(getHash(clientIp)) % PrincessConfig.SERVER_IP_LIST.size(); 
    4.             String serverIp = PrincessConfig.SERVER_IP_LIST.get(index); 
    5.             System.out.println(clientIp + "呼吁的蒸发器ip为" + serverIp); 
    6.         } 
    7.     } 

    末了输出如下:

     

    这样不管执行多少次,相同的客户端 ip 呼吁得到的蒸发器地址都是一样的!

    这种实现很简单,但也很薄弱!因为我们服务器的多寡是可能转变的,当日下线一台机械明天增长一台机械是很常见的!

    传感器数量一旦变化,那源地址 hash 后取模的值可能就变化了,获取到的蒸发器的 ip 潇洒就也会发生变化!

    比如我们服务器去掉一台 192.168.4.10 的机械再瞅下输出结果:

     

    相比之下输出结果我们就能收看,影响几乎是全局的!那我们能不能有一种方案就算是服务器数量变化,也能减少受影响之客户端呢?这就要求用到下的边缘 hash 书法!

    竞争性 hash 书法

    加权轮询书法实现二中我们讲到过把权重值转化为横坐标展示,咱们这里是不是也得以用同样的笔触呢?

    客户端 ip 拓展 hash 此后不就是一番 int32 的数字嘛,那我们就足以把一个 int32 的数字分为几个段,让每个服务器负责一个段的呼吁!

     

    下为了直观我们把服务器 192.168.2.10、192.168.2.20、192.168.2.30、192.168.2.40 离别用 IP1、IP2、IP3、IP4 表示,如上图:

  • 如果客户端 ip 拓展 hash 此后的值在 0~536870911 之间,那就付给 IP2 传感器处理。
  • 如果客户端 ip 拓展 hash 此后的值在 536870911~1073741822 之间,那就付给 IP3 传感器处理。
  • 如果客户端 ip 拓展 hash 此后的值在 1073741822~1610612733 之间,那就付给 IP4 传感器处理。
  • 如果客户端 ip 拓展 hash 此后的值大于 1610612733 之间,那就付给 IP1 传感器处理。
  • 但是专业一点之表示都会把这个横坐标掰弯,形成一个环,就叫所谓的 hash 环,如下图:

     

    这样看就更直观了!如果有远方 IP4 这台服务器宕机,那原来需要到 IP4 的呼吁就会全部转移到 IP1 传感器进行拍卖。

    这样对一部分客户端的呼吁依然会有影响,但至少影响也只是部分的,如下图:

     

    这样就足以了吗?咱们思考两个问题:

  • 每个服务器在 hash 环上的岗位是咱们人为的人均的分配的,这样经常需要扩容缩容的时节会不会比较难以保护呢?
  • IP4 宕机,原来会到 IP4 的呼吁全部转移到 IP1,那会不会导致 IP1 的话务量不均衡?能不能有一度更均衡一点之提案让原本到 IP4 的话务量均衡的更换到 IP1、IP2、IP3 呢?
  • 解决问题 1 的提案就是不再人为分配结点所在的岗位,而是根据服务器的 ip 计算出 hash 值,再瞅 hash 值落在环上的哪个岗位!

    这样存在的一个问题是每个集群的蒸发器 ip 都市不同,因此计算后落在环上的岗位可能就是不足控的。

    如上面四台服务器计算后所在的岗位可能会如下图所示:

     

    很显然,这种情景是极为不平衡的,会造成数据的右倾!地方问题 2 的题材其实也是宕机导致的多寡倾斜!

    环的左上部分那么空,咱们是不是可以把今天的 4 台服务器再论证其他的平整在左上方生成一些结点呢?这样是不是请求就会稍微均匀一点呢?

    这就是所谓的虚拟结点!编造结点就是同一个服务器 ip 会根据某个规则生成多个 hashcode,这样在环上就存在多个结点了。

    如下图所示:

     

    此地只是人云亦云了每台服务器有两个虚拟结点,现实在开发中会更多!这样就算 IP4 机械挂掉,呼吁也不会全部压到某一台服务器上去!

    讲了这么多,但实现起来也不困难,下就该上代码了(传感器配置及请求的客户端 ip 与源地址 hash 书法部分的一致,此地就不贴对应的编码了,直接上书法逻辑):

         
    1. //编造结点数量100 
    2. private static final Integer VIRTUAL_NODES = 100; 
    3.  
    4. public static void main(String[] args) { 
    5.  
    6.     // 遍历服务器ip,浮动对应的虚拟结点 
    7.     TreeMap<Integer, String> nodeMap = new TreeMap<Integer, String>(); 
    8.     for (String serverIp : PrincessConfig.SERVER_IP_LIST) { 
    9.         for (int i = 0; i < VIRTUAL_NODES; i++) { 
    10.             nodeMap.put(getHash(serverIp + "VN" + i), serverIp); 
    11.         } 
    12.     } 
    13.  
    14.     for (String clientIp : CLIENT_IP_LIST) { 
    15.         //此地利用的TreeMap的性状,不知晓的可以去自己去了解一下tailMap办法的企图 
    16.         SortedMap<Integer, String> subMap = nodeMap.tailMap(getHash(clientIp)); 
    17.         Integer firstKey = null
    18.         try { 
    19.             firstKey = subMap.firstKey(); 
    20.         } catch (Exception e) { 
    21.         } 
    22.  
    23.         if (firstKey == null) { 
    24.             firstKey = nodeMap.firstKey(); 
    25.         } 
    26.         System.out.println("呼吁的蒸发器ip为" + nodeMap.get(firstKey)); 
    27.     } 

    到此,几种备用的载荷均衡算法及代码实现都已介绍完毕!还有不知晓可以去同性交友网下载示例代码自己调试:

         
    1. https://github.com/sujing910206/load-balance 

    笔者:苏静

    介绍:有过多年巨型互联网项目的支出经历,对高并发、分布式、以及微服务技能有深刻的研讨及相关实践经验。经验过自学,热衷于技术研究与分享!格言:始终保持虚心学习之态势!

    【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

    【编纂推荐】

    1. 借Redis Cluster集群,聊一聊集群中数据分布算法
    2. 面试官:负载均衡的作法你了解不?
    3. 负载均衡的5种书法,你了解几种?
    4. 负载均衡的作法你了解不?
    5. 深入了解Nginx及利用Nginx贯彻负载均衡
    【义务编辑: 武晓燕 TEL:(010)68476606】
    分享到朋友圈 分享到微博
  • 负载均衡
  • 书法
  • 加权轮询
  • 相关推荐

    用多少告诉你,最新冠状病毒传染性有多强?

    2020-01-30 14:55:15

    对外部Eureka的AP竞争性,Nacos如何实现Raft书法

    2020-01-30 11:13:23

    百度:免费开放LinearFold书法,可将RNA剖析从55分钟缩短至27秒

    2020-01-30 11:00:45

    Copyright © 2005-2020 51CTO.COM 必发娱乐登入
    情节话题
    必发娱乐登入 移步 传感器 系统 安全 网络 必发娱乐登录 虚拟化 付出
    热门产品
    51CTO必发娱乐登录 51CTO高招 移步开发者服务联盟网+ 51CTO博客 WOT碰头会


  • 
       
       
       
       
       
  •