共计 1717 个字符，预计需要花费 5 分钟才能阅读完成。
某年某月的某一天，就像一张破碎的脸。。。
错了，重来。
某天，突然发现大量的告警，通过多番考察钻研考查（此处省略 3000 字），发现是因为 Eureka 服务下线太慢，而依然有大量的申请打进来导致的报错。
于是，又通过了大量具体周密的考查和钻研，终于找到了问题并且解决了（此处省略 5000 字）。
全文完。
… …
好了，那是不可能的啦，怎么说也要意思一下写个 300 字凑个原创啊。
为啥服务都下线了还会有那么多的申请始终进来呢？
呐，咱们都晓得 Eureka 是 AP 模型，其实根本原因在于 Eureka 应用了三级缓存来保留服务的实例信息，如下图所示。
咱们的服务注册的时候会和 server 放弃一个心跳，这个心跳的工夫是 30 秒，服务注册之后，客户端的实例信息保留到 Registry 服务注册表当中，注册表中的信息会立即同步到 readWriteCacheMap 之中。
而客户端如果感知到这个服务，要从 readOnlyCacheMap 去读取，这个只读缓存须要 30 秒的工夫去从 readWriteCacheMap 中同步。
客户端和 Ribbon 负载平衡 都放弃一个本地缓存，都是 30 秒定时同步。
依照下面所说，咱们来计算一下客户端感知到一个服务下线极其的状况须要多久。
- 客户端每隔 30 秒会发送心跳到服务端
- registry 保留了所有服务注册的实例信息，他会和 readWriteCacheMap 放弃一个实时的同步，而 readWriteCacheMap 和 readOnlyCacheMap 会每隔 30 秒同步一次。
- 客户端每隔 30 秒去同步一次 readOnlyCacheMap 的注册实例信息
- 思考到如果应用 ribbon 做负载平衡的话，他还有一层缓存每隔 30 秒同步一次
如果说一个服务的失常下线，极其的状况这个工夫应该就是 30+30+30+30 差不多 120 秒的工夫了。
如果服务非正常下线，还须要靠每 60 秒执行一次的清理线程去剔除超过 90 秒没有心跳的服务，那么这里的极其状况可能须要 3 次 60 秒能力检测进去，就是 180 秒的工夫。
累计可能最长的感知工夫就是：180 + 120 = 300 秒，5 分钟的工夫，这个工夫属实有点夸大了，如果思考到可能有些中间件画龙点睛加了点啥清理的工作，这个工夫几乎就是灾难性的。
那有人就问了，我在 Eureka 控制台看见服务高低线十分快啊，你这不跟我扯犊子吗？
大哥啊，控制台的显示是间接获取的 Registry 的信息，那必定快啊，所以咱们不能这样来判断。
那怎么解决呢，解决方案当然就是改这些工夫了，这个工夫须要依据理论生产的状况来判断批改，这里仅提供一个示例。
批改 ribbon 同步缓存的工夫为 3 秒：ribbon.ServerListRefreshInterval = 3000
批改客户端同步缓存工夫为 3 秒：eureka.client.registry-fetch-interval-seconds = 3
心跳间隔时间批改为 3 秒：eureka.instance.lease-renewal-interval-in-seconds = 3
超时剔除的工夫改为 9 秒：eureka.instance.lease-expiration-duration-in-seconds = 9
清理线程定时工夫改为 5 秒执行一次：eureka.server.eviction-interval-timer-in-ms = 5000
同步到只读缓存的工夫批改为 3 秒一次：eureka.server.response-cache-update-interval-ms = 3000
须要留神的是这里的只读缓存其实是能够敞开的，通过批改参数 eureka.server.use-read-only-response-cache = false 能够做到，
然而倡议不要没有太大必要不要这样做，Eureka 自身就是 AP 模型，用它你就应该有这个觉醒了，另外这个配置只针对原生的 Eureka 失效，SpringCloud Eureka 是没有的，必须肯定会从 readOnlyCacheMap 去读。
如果依照这个工夫参数设置让咱们从新计算可能感知到服务下线的最大工夫：
失常下线就是 3+3+3+3=12 秒，非正常下线再加 15 秒为 27 秒。
OK，明天内容就到这儿了，我是艾小仙，下期见。