SpringCloud-负载均衡-ribbon

本篇是从基础方便讲解一些springcloud-负载均衡-ribbon中的一些理论性的内容；还会讲一些源码内容；后面的文章会将源码进行整理，并且将源码的github地址上传。

1.什么是负载均衡

核心概念：用户来访请求应该相对平均的分摊到每个节点；

不要将所有工作量都给一个节点。

LB策略的目的(负载均衡)：海量的用户请求均匀的分配到集群中的每一台机器上

设计系统时需要有一定的余量(应对系统不同情况)

2.客户端负载与服务端负载均衡

客户端的负载均衡：服务机器的列表(客户端保存copy，且动态变化)

+LB策略(负载均衡策略)

服务端的负载均衡：nignx/F5等

大型应用通常是客户端+服务端负载均衡搭配使用

客户端负载均衡(红色)与服务端负载均衡的比较：

客户端，对开发团队更加友好，代码中可以决定使用那种负载均衡策略(配置文件)。

运维成本低(不需要额外的组件，所有的负载均衡策略在服务端就制定好了)

强依赖于注册中心，从注册中心拉到可用服务的列表(可动态更新)

微服务框架搭配使用，gateway，zookeeper，ribbon偏多。

服务端，开发团队很难去主动的发起修改，负载均衡都在网关层，由专业的网络人员来

操作，修改。网关层语言跟日常的java有很大的区别。

运维成本高(需要额外的组件，使用F5还要搭配硬件设备)

通常不依赖(SpringCloud架构zookeeper，gateway时存在依赖)

Tomcat,JBoss部署传统应用：nginx，F5偏多

3.Ribbon体系架构解析

Ribbon体系架构：

丰富的组件库；适配性好；(牛的Ribbon可以脱离

SpringCloud可以应用在一般项目中)

组件图：

一个HttpRequest发过来，先被转发到Eureka上。此时Eureka仍然通过服务发现获取了所有服务节点的物理地址，但问题是他不知道该调用哪一个，只好把请求转到了Ribbon手里。

IPing IPing是Ribbon的一套healthcheck机制，故名思议，就是要Ping一下目标机器看是否还在线，一般情况下IPing并不会主动向服务节点发起healthcheck请求，Ribbon后台通过静默处理返回true默认表示所有服务节点都处于存活状态（和Eureka集成的时候会检查服节点UP状态）。
IRule 这就是Ribbon的组件库了，各种负载均衡策略都继承自IRule接口。所有经过Ribbon的请求都会先请示IRule一把，找到负载均衡策略选定的目标机器，然后再把请求转发过去。

实现的demo：

在eureka-consumer中，

@SpringBootApplication
@EnableDiscoveryClient
public class EurekaConsumerApplication {
    @Bean
    public RestTemplate register(){
        return new RestTemplate();
    }
    public static void main(String[] args) {
        new SpringApplicationBuilder(EurekaConsumerApplication.class)
                .web(WebApplicationType.SERVLET)
                .run(args);
    }
}

在eureka-consumer的controller中，实现的方式是

@RestController
public class Controller {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping
    public String sayHi() {
            return restTemplate.getForObject(
                    "http://eureka-client/sayHi",
                    String.class);
    }

}

在Ribbon-consumer的controller中如何实现(LB策略)下获取对应的节点：

这里直接将地址写上去(直接应用服务名)。返回值是String.class。

后台是如何找到对应的服务和对应的端口呢？

key就在@LoadBalanced

@Bean

@LoadBalanced

public RestTemplate template(){

return new RestTemplate();

}

4.懒加载与饥饿加载

INFO [main] com.netflix.loadbalancer.DynamicServerListLoadBalancer -
DynamicServerListLoadBalancer for client eureka-consumer initialized

这行log意思是，Ribbon客户端已经完成了LoadBalancer的初始化。初始化是没问题的，但问题是初始化发生的时间，为什么偏偏发生在首次超时之前呢？

这就要从Ribbon的懒加载说起了，原来Ribbon是在第一次方法调用的时候才去初始化LoadBalancer。这样看来，第一个方法请求不仅仅包含HTTP连接和方法的响应时间，还包括了LoadBalancer的创建耗时。假如你的方法本身就比较耗时的话，而且超时时间又设置的比较短，那么很大可能这第一次http调用就会失败。其实还有很多框架也实现了类似的懒加载功能，比如Hibernate的lazy-fetch，懒加载在大部分情况下可以节省系统资源开销，但某些情况下反而导致服务响应时间被延长。

之所以这类问题难以发现的原因，在于它无法稳定重现，比如只能通过重启来重现，对这种问题往往直接从生产环境的log入手去分析是比较有效的手段。

Ribbon--饥饿加载：

ribbon.eager-load.enabled=true

ribbon.eager-load.clients=ribbon-consumer

第一个参数开启了Ribbon的饥饿加载模式，第二个属性指定了需要应用饥饿加载的服务名称。完成上面配置并再次重启服务，就会发现LoadBalancer初始化日志在方法调用之前就打印出来了

5.负载均衡策略-七种策略
RandomRule ：随性而为：随机挑选访问节点
RoundRobinRule :按部就班从一个节点一步一步向后选取节点，

不会跳过一个，不会原地踏步，每次只会向后移动一步；

假如在多线程环境下，两个请求同时访问这个Rule是否会读取到相同节点呢？不会，这靠的是RandomRobinRule底层的自旋锁+CAS的同步操作。CAS的全称是compare and swap，是一种借助操作系统函数来实现的同步操作。类似Eureka为了防止服务下线被重复调用，就使用AtomicBoolean的CAS方法做同步控制，CAS+自旋锁这套组合技是高并发下最廉价的线程安全手段，因为这套操作不需要锁定系统资源。有优点也有缺点，自旋锁如果迟迟不能释放，将会带来CPU资源的浪费，因为自旋本身并不会执行任何业务逻辑，而是单纯的使CPU"空转"。所以通常情况下会对自旋锁的旋转次数做一个限制，比如JDK中synchronize底层的锁升级策略，就对自旋次数做了动态调整。

// CAS+自旋锁获取系统资源的打开方式，真实应用中还要注意防止无休止自旋：
// 或者for (;;) 做自旋
while (true) { 
	// cas操作
	if (cas(expected, update)) {
		// 业务逻辑代码
		// break或退出return
	}  }

Netflix是特别喜欢用自旋+CAS，作为中间件来说性能是非常重要的。
RetryRule:卷土重来

一个类似装饰器模式的Rule。装饰器相当于一层层的俄罗斯套娃，每一层都会加上一层独特的buff。

RetryRule也是同样的道理，他的BUFF就是给其他负载均衡策略加上"重试"功能。而在RetryRule里还藏着一个subRule，这才是隐藏在下面的真正被执行的负载均衡策略，RetryRule正是要为它添加重试功能（如果初始化时没指定subRule，将默认使用RoundRibinRule）。

WeightedResponseTimeRule :能者多劳

继承自RoundRibbonRule，他会根据服务节点的响应时间计算权重，

响应时间越长权重就越低，响应越快则权重越高。权重的高低决定了

机器被选中概览的高低。就是说，响应时间越小的机器，被选中的概览越大。

由于服务器刚启动的时候，对各个服务节点采样不足，因此采用轮询策略，当积累

到一定的样本时，会切换到WeightedResponseTimeRule模式。

BestAvailableRule :让最闲的人来

有点智能。过滤掉故障服务以后，它会基于30分钟的统计结果选取当前并发量最小的

服务结点，也就最"闲"的节点作为目标地址。

如果无统计结果，则采用轮询的方式选定节点。

关键字：过滤故障服务；选取并发量最小的节点。

AvailabilityFilteringRule :我是有底线的(AFR)

底层依赖RandomRobinRule来选取节点，满足它的最小要求的节点才会被选中。

如果节点满足要求，无论响应时间或当前并发量是什么。都会被选中。

每次AvailabilityFilteringRule（简称AFR）都会请求RobinRule挑选一个节点，然后对这个节点做以下两步检查：

是否处于熔断状态（熔断是Hystrix中的知识点，后面章节会讲到，这里大家可以把熔断当做服务不可用）

节点当前的active请求连接数超过阈值，超过了则表示节点目前太忙，不适合接客

如果被选中的server不幸挂掉了检查，那么AFR会自动重试（次数最多10次），让RobinRule重新选择一个服务节点。

ZoneAvoidanceRule:我的地盘我做主

ZoneFilter:在Eureka注册中一个服务结点有Zone,Region和URL三个身份信息

其中Zone可以理解为机房大区(未指定则由Eureka给定默认值)，

这里会对这个Zone的监控情况过滤器下面所有服务结点

可用性过滤：这里和AvailabilityFilteringRule的验证非常像，会过滤当前并发量

较大，或者处于熔断的服务节点。

5.配置负载均衡策略

Ribbon默认的策略是：RoundRobinRule。一个个轮询

配置负载均衡策略的方式：@Bean注入的方式。也可以放在启动类中

@Configuration
public class RibbonConfiguration {

    @Bean
    public IRule delaultLBStrategy() {
        return new RandomRule();
    }

}

针对特定的服务的id的负载均衡策略：

配置在application.yml

eureka-client:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

注解的方式：

(配置在public class RibbonConfiguration {)

//@RibbonClient(name = "eureka-client", configuration = MyRule.class)

6.部分源码品读：

概念：

**真假随机数：**真随机数是通过物理过程（如放射性衰变、大气噪声等）生成的，其每个数字都是完全随机的，无法预测。而假随机数则是通过算法生成的，其每个数字都是基于前一个数字计算得出的，存在一定的规律性，可以被预测。因此，在需要高度安全性的场景中，应该使用真随机数来保证随机性。

RandomRule核心：

@edu.umd.cs.findbugs.annotations.SuppressWarnings(value = "RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE")
public Server choose(ILoadBalancer lb, Object key) {
    if (lb == null) {
        return null;
    }
    Server server = null;
    while (server == null) {
        if (Thread.interrupted()) {
            return null;
        }
        List<Server> upList = lb.getReachableServers();
        List<Server> allList = lb.getAllServers();
        int serverCount = allList.size();
        if (serverCount == 0) {
            /*
             * No servers. End regardless of pass, because subsequent passes
             * only get more restrictive.
             */
            return null;
        }
        int index = chooseRandomInt(serverCount);
        server = upList.get(index);
        if (server == null) {
            /*
             * The only time this should happen is if the server list were
             * somehow trimmed. This is a transient condition. Retry after
             * yielding.
             */
            Thread.yield();
            continue;
        }
        if (server.isAlive()) {
            return (server);
        }
        // Shouldn't actually happen.. but must be transient or a bug.
        server = null;
        Thread.yield();
    }
    return server;
}

对于上面的分析：ILoadBalancer lb。

当server = = null. If(Thread.interrupted()),表示线程中断，则返回空。防御性编程

if (server == null) {

Thread.yield(); continue; }

Thread.yield()表示线程让渡，当前线程愿意让出CPU。

如果server.isAlive,则直接返回。

为空，则调用Thread.yield()，完成线程让步。

原因是没有其他退出线程的办法。

RoundRobinRule：在代码最后没有做线程让渡

因为有Count计数器，10次之后就自动退出了。

   // Next.
    server = null;
}

if (count >= 10) {
    log.warn("No available alive servers after 10 tries from load balancer: "
            + lb);
}

for(;😉:自旋锁的实现。

自旋锁+NSCC.CAS操作是一个非常高效的线程同步方式。

private int incrementAndGetModulo(int modulo) {
    for (;;) {
        int current = nextServerCyclicCounter.get();
        int next = (current + 1) % modulo;
        if (nextServerCyclicCounter.compareAndSet(current, next))
            return next;
    }
}

全部代码：RoundRobinRule核心部分

public Server choose(ILoadBalancer lb, Object key) {
    if (lb == null) {
        log.warn("no load balancer");
        return null;
    }

    Server server = null;
    int count = 0;
    while (server == null && count++ < 10) {
        List<Server> reachableServers = lb.getReachableServers();
        List<Server> allServers = lb.getAllServers();
        int upCount = reachableServers.size();
        int serverCount = allServers.size();

        if ((upCount == 0) || (serverCount == 0)) {
            log.warn("No up servers available from load balancer: " + lb);
            return null;
        }

        int nextServerIndex = incrementAndGetModulo(serverCount);
        server = allServers.get(nextServerIndex);

        if (server == null) {
            /* Transient. */
            Thread.yield();
            continue;
        }

        if (server.isAlive() && (server.isReadyToServe())) {
            return (server);
        }

        // Next.
        server = null;
    }

    if (count >= 10) {
        log.warn("No available alive servers after 10 tries from load balancer: "
                + lb);
    }
    return server;
}

BestAvailableRule：

分析先判断loadBalancerStats ==null为空时，

直接调用super.choose(key).

它调用的是上层(ClientConfigEnabledRoundRobinRule).

里面的代码是：

@Override
public Server choose(Object key) {
    if (roundRobinRule != null) {
        return roundRobinRule.choose(key);
    } else {
        throw new IllegalArgumentException(
                "This class has not been initialized with the RoundRobinRule class");
    }
}

继续分析：这里代码是直接调用上层的roundRobinRule的choose方法。具体

RoundRobinRule核心choose方法上面已经进行了分析

获取所有的getAllServers.以及当前时间

遍历serverList,首先获取serverStats.

isCircuitBreakerTripped ：一个布尔值，用于表示断路器是否触发。如果断路器已触发，则该值为 true；否则为 false。

对于isCircuitBreakerTripped

这段代码是一个名为 isCircuitBreakerTripped 的 Java 方法，它这段代码是一个名为 isCircuitBreakerTripped 的 Java 方法，它接受一个长整型参数 currentTime。该方法的作用是判断断路器是否触发。

首先，通过调用 getCircuitBreakerTimeout() 方法获取断路器超时时间，并将其赋值给变量 circuitBreakerTimeout。如果 circuitBreakerTimeout 小于等于 0，则表示断路器未设置超时时间，因此返回 false。

如果 circuitBreakerTimeout 大于 0，则比较当前时间 currentTime 和断路器超时时间 circuitBreakerTimeout。如果当前时间小于等于断路器超时时间，说明断路器还未触发，返回 false；否则，说明断路器已触发，返回 true。

BestAvailableRule的核心代码：

@Override
public Server choose(Object key) {
    if (loadBalancerStats == null) {
        return super.choose(key);
    }
    List<Server> serverList = getLoadBalancer().getAllServers();
    int minimalConcurrentConnections = Integer.MAX_VALUE;
    long currentTime = System.currentTimeMillis();
    Server chosen = null;
    for (Server server: serverList) {
        ServerStats serverStats = loadBalancerStats.getSingleServerStat(server);
        if (!serverStats.isCircuitBreakerTripped(currentTime)) {
            int concurrentConnections = serverStats.getActiveRequestsCount(currentTime);
            if (concurrentConnections < minimalConcurrentConnections) {
                minimalConcurrentConnections = concurrentConnections;
                chosen = server;
            }
        }
    }
    if (chosen == null) {
        return super.choose(key);
    } else {
        return chosen;
    }
}

RetryRule:给与其他Rule进行重试策略

public Server choose(ILoadBalancer lb, Object key) {
   long requestTime = System.currentTimeMillis();
   long deadline = requestTime + maxRetryMillis;

   Server answer = null;

   answer = subRule.choose(key);

   if (((answer == null) || (!answer.isAlive()))
         && (System.currentTimeMillis() < deadline)) {

      InterruptTask task = new InterruptTask(deadline
            - System.currentTimeMillis());

      while (!Thread.interrupted()) {
         answer = subRule.choose(key);

         if (((answer == null) || (!answer.isAlive()))
               && (System.currentTimeMillis() < deadline)) {
            /* pause and retry hoping it's transient */
            Thread.yield();
         } else {
            break;
         }
      }
      task.cancel();
   }
   if ((answer == null) || (!answer.isAlive())) {
      return null;
   } else {
      return answer;
   }
}

7.负载均衡器LoadBalancer原理解析

@LoadBalanced 这个注解一头挂在RestTemplate上，另一头挂在LoadBalancerAutoConfiguration这个类上。它就像连接两个世界的传送门，将所有顶着「LoadBalanced」注解的RestTemplate类，都传入到LoadBalancerAutoConfiguration中。如果要深挖底层的作用机制，大家可以发现这个注解的定义上还有一个@Qualifier注解，@Qualifier注解搭配@Autowired注解做自动装配，可以通过name属性，将指定的Bean装载到指定位置（即使有两个同样类型的Bean，也可以通过Qualifier定义时声明的name做区分）。这里「LoadBalanced」也是借助Qualifier实现了一个给RestTemplate打标签的功能，凡是被打标的RestTemplate都会被传送到AutoConfig中做进一步改造。

LBAutoConfig 从前一步中传送过来的RestTemplate，会经过LBAutoConfig的装配，将一系列的Interceptor（拦截器）添加到RestTemplate中。拦截器是类似职责链编程模型的结构，我们常见的ServletFilter，权限控制器等，都是类似的模式。Ribbon拦截器会拦截每个网络请求做一番处理，在这个过程中拦截器会找到对应的LoadBalancer对HTTP请求进行接管，接着LoadBalancer就会找到默认或指定的负载均衡策略来对HTTP请求进行转发。

总结Ribbon的作用机制就是，由LoadBalanced在RestTemplate上打标，Ribbon将带有负载均衡能力的拦截器注入标记好的RestTemplate中，以此实现了负载均衡。

IPing机制

DummyPing，默认返回true，即认为所有节点都可用，这也是单独使用Ribbon时的默认模式

NIWSDiscoveryPing，借助Eureka服务发现机制获取节点状态，假如节点状态是UP则认为是可用状态

PingUrl,它会主动向服务节点发起一次http调用，如果对方有响应则认为节点可用

大家可以看出第三种主动出击的模式比较生猛。大家可以想象，假如我们的服务节点搭载的是随便一个微服务都有大几千台服务器，在服务本身就被超高访问量调用的情况下，那这种主动出击的IPing策略必然会大大增加服务节点的访问压力。

既然Eureka已经有了服务发现机制，可以获取节点的当前状态，拿来就用岂不更好？因此，除非特殊指定，在和Eureka搭配使用的时候，采用的是第二种，也就是过滤非UP状态的节点（其实这个功能直接放Eureka里也能做）

8.IPing机制解析

public interface IPing接口只有一个方法public boolean isAlive(Server server);

5个实现类

对于DummyPing,isAlive方法，直接返回true

NoOpPing同上。

NIWSDiscoveryPing代码：

DiscoveryEnabledServer dServer = (DiscoveryEnabledServer)server;	            
InstanceInfo instanceInfo = dServer.getInstanceInfo();

发现Eureka的服务列表，然后通过是否是up状态来判断对应的

Server是否处于alive状态

public boolean isAlive(Server server) {
    boolean isAlive = true;
    if (server!=null && server instanceof DiscoveryEnabledServer){
           DiscoveryEnabledServer dServer = (DiscoveryEnabledServer)server;                
           InstanceInfo instanceInfo = dServer.getInstanceInfo();
           if (instanceInfo!=null){                    
               InstanceStatus status = instanceInfo.getStatus();
               if (status!=null){
                   isAlive = status.equals(InstanceStatus.UP);
               }
           }
       }
    return isAlive;
}

对于PingUrl类：拼接url，向服务节点发起调用

public boolean isAlive(Server server) {
    String urlStr = "";
    if (this.isSecure) {
        urlStr = "https://";
    } else {
        urlStr = "http://";
    }

    urlStr = urlStr + server.getId();
    urlStr = urlStr + this.getPingAppendString();
    boolean isAlive = false;
    HttpClient httpClient = new DefaultHttpClient();
    HttpUriRequest getRequest = new HttpGet(urlStr);
    String content = null;

    try {
        HttpResponse response = httpClient.execute(getRequest);
        content = EntityUtils.toString(response.getEntity());
        isAlive = response.getStatusLine().getStatusCode() == 200;
        if (this.getExpectedContent() != null) {
            LOGGER.debug("content:" + content);
            if (content == null) {
                isAlive = false;
            } else if (content.equals(this.getExpectedContent())) {
                isAlive = true;
            } else {
                isAlive = false;
            }
        }
    } catch (IOException var11) {
        var11.printStackTrace();
    } finally {
        getRequest.abort();
    }

    return isAlive;
}

9.IRule机制解析

Rule就是负载均衡策略

IRule的对象结构

IRule调用的方式和改造点：

IRule在执行一次代码时，无需重复执行。(因为测试时debug时，第二次

执行接口测试的时候没有进入)

多次测试发现没经过RibbonClientConfiguration中如下的方法：

这里主要是加载environment中的环境资源：

拿到配置后会在SpringClientFactory中调用instantiateWithConfig

(下面代码就是简单的反射机制)

try {
   Constructor<C> constructor = clazz.getConstructor(IClientConfig.class);
   result = constructor.newInstance(config);
}

ZoneAvoidanceRule 加载的config信息是：

@Bean
@ConditionalOnMissingBean
public IRule ribbonRule(IClientConfig config) {
   if (this.propertiesFactory.isSet(IRule.class, name)) {
      return this.propertiesFactory.get(IRule.class, config, name);
   }
   ZoneAvoidanceRule rule = new ZoneAvoidanceRule();
   rule.initWithNiwsConfig(config);
   return rule;
}

然后就到ribbonLoadBalancer来生成ILoadBalancer

(RibbonClientConfiguration类中的方法，同上类)

ZoneAwareLoadBalancer 来加载配置

@Bean
@ConditionalOnMissingBean
public ILoadBalancer ribbonLoadBalancer(IClientConfig config,
      ServerList<Server> serverList, ServerListFilter<Server> serverListFilter,
      IRule rule, IPing ping, ServerListUpdater serverListUpdater) {
   if (this.propertiesFactory.isSet(ILoadBalancer.class, name)) {
      return this.propertiesFactory.get(ILoadBalancer.class, config, name);
   }
   return new ZoneAwareLoadBalancer<>(config, rule, ping, serverList,
         serverListFilter, serverListUpdater);
}

10.自定义IRule

自定义基于一致性哈希负载均衡策略；

制定服务应用自定义策略：

来访的请求怎么找到对应的服务器呢？将来访的请求的某一个

特征量(可以是请求中的RequestParam也可以是你整个的URL)找出来，

通过一定的算法做成一个摘要。再通过HashCode算法过滤一遍摘要，

变成一个Int值，映射到环上。接下来就寻找离它最近的下一个节点的位置

(只能是顺时针或者是逆时针)

分析：同一个request的特征量每次都是相同的，摘要相同；只要服务器不宕机，

永远只能找到同一台机器。因为每次的位置都在环上同一个位置。服务器宕机后，

会继续往前寻找下一个节点。

//无构造器的构造方法

@NoArgsConstructor
public class MyRule extends AbstractLoadBalancerRule implements IRule {
    @Override
    public void initWithNiwsConfig(IClientConfig clientConfig) {

    }

    //key无法做摘要，就是default
    @Override
    public Server choose(Object key) {

        HttpServletRequest request = ((ServletRequestAttributes)
                RequestContextHolder.getRequestAttributes())
                .getRequest();
        // 特征量 uri 具体需要根据情况决定。
        // 比如当关联USERID时，需要从request将用户的id提取出来
        String uri = request.getServletPath() + "?" + request.getQueryString();
        //处理特征量 这里使用的是所有的服务列表，区别于getReachableServers
        return route(uri.hashCode(), getLoadBalancer().getAllServers());
    }

    /**
     * 主逻辑：用来寻找特定的Server，最终需要返回的对象
     * @param hashId
     * @param addressList
     * @return
     */
    public Server route(int hashId, List<Server> addressList){
        //防御性编程
        if (CollectionUtils.isEmpty(addressList)){
            return null;
        }

        // 排序相关
        TreeMap<Long, Server> address = new TreeMap<>();
        // 循环List stream方式
        addressList.stream().forEach(e ->{
            //假设圆环有几个节点，对应i值
            // 这里是每个server的hash值，然后将其放进来
            // 这8个hash值分布不够均匀
            // TODO 可以针对这个算法，修改成均匀分布的算法
            // 虚化若干个服务节点，到环上
            for (int i = 0; i < 8; i++){
                // 计算hash值，e是addressList中的server element。
                long hash = hash(e.getId() + i);
                //将address放进来
                address.put(hash,e);
            } });

        Long hash = hash(String.valueOf(hashId));

        // 获取大于hash的值，比如传进去的值是3，则获取的值是4等(比三大的整数值)
        SortedMap<Long, Server> last = address.tailMap(hash);

        // 当request URL 的hash值大于任意一个服务器对应的hashKey
        // 取address中的第一个节点
        if (last.isEmpty()){
            address.firstEntry().getValue();
        }

        return last.get(last.firstKey());
    }

//    用来计算hash值的
    public Long hash(String key) {
        // md5有必须检查的异常
        MessageDigest md5;
        try {
            md5 = MessageDigest.getInstance("MD5");
        } catch (NoSuchAlgorithmException e) {
            // RuntimeException封装一下
            throw new RuntimeException(e);
        }

        byte[] keyByte = null;
        try {
            keyByte = key.getBytes("UTF-8");
        } catch (UnsupportedEncodingException e) {
            throw new RuntimeException(e);
        }

        //将md5更新到key里,把key塞到md5这个算法里
        md5.update(keyByte);
        // 做出摘要，digest利用md5输出byte数组，即为摘要(16位的)
        byte[] digest = md5.digest();

        //根据只要生成hashCode
        //从第三位开始,下标为2((long) (digest[2] & 0xFF << 16))
        // 2 "& 0xFF" 转成long型 ， << 16表示往前移16位
        long hashCode = ((long) (digest[2] & 0xFF << 16))
                | ((long) (digest[2] & 0xFF << 8))
                | ((long) (digest[2] & 0xFF ));

        //将一个整数（hashCode）与0xffffffffL进行按位与操作，
        // 以保留其低32位。这样可以确保返回的哈希值是一个无符号整数。
        return hashCode & 0xffffffffL;
    }
}