eureka参数的优化

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

为什么要破坏Eurake本身的规范 按Netfix的建议，这些配置应该保持默认,通过重试+冥等来解决发布重启过程中的接口超时问题。一般公司的场景不是像Netfix那种视频网站，我们需要保护用户的调用尽量不要超时， 不要重试。按照默认配置,有节点出现问题后,需要90-120秒，服务消费者才能感知到节点下线，这期间会有大量超时，甚至可能出现数据错误，这个在某些场景是不可接受的。 另外一个重要的原因是,我们希望发布过程尽量快速且平滑，所以决定采用下述配置。
# eruake优化 加速服务发现
EurekaServer修改如下配置：
#默认30s，修改为3s
eureka.server.responseCacheUpdateIntervalMs=3000
#默认180s，由于启用了evict所以这个配置保持不变
eureka.server.responseCacheAutoExpirationInSeconds=180
#启用主动失效，并且每次主动失效检测间隔为3s
eureka.server.eviction-interval-timer-in-ms=3000
# 心跳间隔，3秒
eureka.instance.leaseRenewalIntervalInSeconds=3
# 没有心跳的淘汰时间，9秒
eureka.instance.leaseExpirationDurationInSeconds=9
# 增加tomcat线程数到400。默认200
server.tomcat.max-threads=400
EurekaClient修改如下配置：
#默认90s，超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除，修改为9s
eureka.instance.lease-expiration-duration-in-seconds=9
#默认30s每隔这个时间会主动心跳一次,修改为3s
eureka.instance.lease-renewal-interval-in-seconds=3
#默认30s，eureka client刷新本地缓存时间。修改为1s
eureka.client.registry-fetch-interval-seconds=1
#默认30s，Ribbon会定时更新服务可用节点的缓存（见PollingServerListUpdater）,定时任务执行间隔,eureka客户端ribbon刷新时间。修改为3s  
ribbon.ServerListRefreshInterval=1000
下线时间：
1.主动取消注册后，1+3=4s后调用方可感知到节点下线。
registry-fetch-interval-seconds【1s】+ServerListRefreshInterval【3s】
2.节点异常下线，直接kill -9，9+3+3+1+3=19s后调用方可感知到节点下线。
"lease-expiration-duration-in-seconds"【9s】 + "eviction-interval-timer-in-ms"【3s】+ "responseCacheUpdateIntervalMs"【3s】+ "registry-fetch-interval-seconds"【1】 + "ServerListRefreshInterval【3s】"
关闭应用的接口  POST http://localhost:8081/actuator/eurekamgmt/shutdown

以上是 eureka参数的优化 的全部内容， 来源链接： utcz.com/z/511550.html

回到顶部