当 Eureka 实例在自我保护关闭的情况下跳过针对 Eureka 服务器的心跳时会发生什么？
What happens when Eureka instance skips a heartbeat against a Eureka server with self preservation turned off?
考虑这个设置：
- 禁用自我保护模式的 Eureka 服务器，即
enableSelfPreservation: false
- 2 个 Eureka 实例，每个实例用于 2 个服务（比如服务#1 和服务#2）。共 4 个实例。
其中一个实例（比如 srv#1inst#1，service#1 的一个实例）发送了心跳，但没有到达 Eureka 服务器。
据我所知，服务器端会依次执行以下操作：
- ServerStep1：服务器观察到特定实例错过了心跳。
- ServerStep2：服务器将实例标记为逐出。
- ServerStep3：服务器的逐出调度程序（定期运行）从注册表中逐出实例。
现在在实例 (srv#1inst#1) 端：
- InstanceStep1：它跳过了一个心跳。
- InstanceStep2: 发现心跳没有到达Eureka Server。它以指数退避重试。
据我所知，驱逐和登记不会立即发生。 Eureka 服务器定期为这两个任务运行单独的调度程序。
我有一些与此过程相关的问题：
- 顺序正确吗？如果没有，我错过了什么？
- 关于驱逐和注册调度程序的假设是否正确？
- 服务#2 的实例在 ServerStep2 之后立即从服务器请求新的注册表副本。
- srv#1inst#1 是否会在新的注册表副本中，因为它尚未被驱逐？
- 如果是，srv#1inst#1 会被标记为 UP 还是 DOWN？
- 来自 srv#1inst#1 的 InstanceStep2 的重试请求在 ServerStep2 之后立即到达服务器。
- 是否会立即更改注册表？
- 这将如何影响对服务#2 请求新注册表的响应？它将如何影响驱逐调度程序？
此问题已由 qiangdavidliu in one of the issues of eureka's GitHub repository 回答。
为了完整起见，我在这里添加他的解释。
在我具体回答问题之前，这里有一些关于心跳和驱逐的高级信息（基于默认配置）：
- 实例只有在连续错过 3 次心跳时才会被逐出
- (most) 心跳不会重试，它们是每 30 秒尽力而为。 heartbeat 唯一会重试的时间是如果 heartbeating 线程上存在线程级别错误（即
Timeout 或 RejectedExecution），但这种情况应该很少见。
让我试着回答你的问题：
Are the sequences correct? If not, what did I miss?
答：顺序正确，以上说明。
Is the assumption about eviction and registration scheduler correct?
A：驱逐由内部调度程序处理。注册由注册请求的处理程序线程处理。
An instance of service#2 requests fresh registry copy from server right after ServerStep2.
- Will srv#1inst#1 be in the fresh registry copy, because it has not been evicted yet?
- If yes, will srv#1inst#1 be marked UP or DOWN?
答：这里有几点：
- 直到实例被实际驱逐，它将成为结果的一部分
- 驱逐不涉及更改实例的状态，它只是从注册表中删除实例
- 服务器保存了30s的世界状态缓存，返回的就是这个缓存。因此，在逐出场景中，客户端看起来的确切结果仍然取决于它何时落入缓存的更新周期。
The retry request from InstanceStep2 of srv#1inst#1 reaches server right after ServerStep2.
- Will there be an immediate change in registry?
- How that will affect the response to instance of service#2's request for fresh registry? How will it affect the eviction scheduler?
答：再说几件事：
- 当实际驱逐发生时，我们会检查每个被驱逐者的时间，看是否有资格被驱逐。如果一个实例能够在此事件之前更新它的心跳，那么它就不再是驱逐的目标。
- 有问题的 3 个事件（驱逐时评估驱逐资格、更新实例的心跳状态、生成要返回给读取操作的结果）都是异步发生的，它们的结果将取决于评估执行时的上述标准。
考虑这个设置：
- 禁用自我保护模式的 Eureka 服务器，即
enableSelfPreservation: false - 2 个 Eureka 实例，每个实例用于 2 个服务（比如服务#1 和服务#2）。共 4 个实例。
其中一个实例（比如 srv#1inst#1，service#1 的一个实例）发送了心跳，但没有到达 Eureka 服务器。
据我所知，服务器端会依次执行以下操作：
- ServerStep1：服务器观察到特定实例错过了心跳。
- ServerStep2：服务器将实例标记为逐出。
- ServerStep3：服务器的逐出调度程序（定期运行）从注册表中逐出实例。
现在在实例 (srv#1inst#1) 端：
- InstanceStep1：它跳过了一个心跳。
- InstanceStep2: 发现心跳没有到达Eureka Server。它以指数退避重试。
据我所知，驱逐和登记不会立即发生。 Eureka 服务器定期为这两个任务运行单独的调度程序。
我有一些与此过程相关的问题：
- 顺序正确吗？如果没有，我错过了什么？
- 关于驱逐和注册调度程序的假设是否正确？
- 服务#2 的实例在 ServerStep2 之后立即从服务器请求新的注册表副本。
- srv#1inst#1 是否会在新的注册表副本中，因为它尚未被驱逐？
- 如果是，srv#1inst#1 会被标记为 UP 还是 DOWN？
- srv#1inst#1 是否会在新的注册表副本中，因为它尚未被驱逐？
- 来自 srv#1inst#1 的 InstanceStep2 的重试请求在 ServerStep2 之后立即到达服务器。
- 是否会立即更改注册表？
- 这将如何影响对服务#2 请求新注册表的响应？它将如何影响驱逐调度程序？
此问题已由 qiangdavidliu in one of the issues of eureka's GitHub repository 回答。
为了完整起见，我在这里添加他的解释。
在我具体回答问题之前，这里有一些关于心跳和驱逐的高级信息（基于默认配置）：
- 实例只有在连续错过 3 次心跳时才会被逐出
- (most) 心跳不会重试，它们是每 30 秒尽力而为。 heartbeat 唯一会重试的时间是如果 heartbeating 线程上存在线程级别错误（即
Timeout或RejectedExecution），但这种情况应该很少见。
让我试着回答你的问题：
Are the sequences correct? If not, what did I miss?
答：顺序正确，以上说明。
Is the assumption about eviction and registration scheduler correct?
A：驱逐由内部调度程序处理。注册由注册请求的处理程序线程处理。
An instance of service#2 requests fresh registry copy from server right after ServerStep2.
- Will srv#1inst#1 be in the fresh registry copy, because it has not been evicted yet?
- If yes, will srv#1inst#1 be marked UP or DOWN?
答：这里有几点：
- 直到实例被实际驱逐，它将成为结果的一部分
- 驱逐不涉及更改实例的状态，它只是从注册表中删除实例
- 服务器保存了30s的世界状态缓存，返回的就是这个缓存。因此，在逐出场景中，客户端看起来的确切结果仍然取决于它何时落入缓存的更新周期。
The retry request from InstanceStep2 of srv#1inst#1 reaches server right after ServerStep2.
- Will there be an immediate change in registry?
- How that will affect the response to instance of service#2's request for fresh registry? How will it affect the eviction scheduler?
答：再说几件事：
- 当实际驱逐发生时，我们会检查每个被驱逐者的时间，看是否有资格被驱逐。如果一个实例能够在此事件之前更新它的心跳，那么它就不再是驱逐的目标。
- 有问题的 3 个事件（驱逐时评估驱逐资格、更新实例的心跳状态、生成要返回给读取操作的结果）都是异步发生的，它们的结果将取决于评估执行时的上述标准。