Eureka 系列（02）Eureka 一致性协议

0. Spring Cloud 系列目录 - Eureka 篇

表1：Spring Cloud 服务发现方案对比

注：以上数据来源于小马哥技术周报。

表2：Spring Cloud 服务发现数据模型

不同的框架对应的数据结构不太一致，在此做一些约定：

服务器集群 Server：指的是 Eureka Server 本身的集群。用 Server 代替，也可能是 ServerList 之类，总之与 Server 或 Peer 或 Node 相关的都代表框架自身的集群。
服务 Service：代表一个应用，可能包含多个服务实例。 Service(服务) 或 serviceId 或 Application(应用) 或 appName 。
集群 Cluster：一个 Service 可能包含多个 Cluster，Cluster 包含多个具体的实例。这是 Nacos 中的概念。
服务实例 ServiceInstance：代表注册的一个具体实例。ServiceInstance(服务实例)或 InstanceInfo(实例id)或 Instance(实例)。

Eureka 和 Zookeeper 的最大区别： Eureka 是 AP 模型，Zookeeper 是 CP 模型。在出现脑裂等场景时，Eureka 可用性是每一位，也就是说出现脑裂时，每个分区仍可以独立提供服务，是去中心化的。更多 Eureka与ZooKeeper 的比较。

那 Eureka 是如何实现最终一致性的呢？

Eureka Server 管理了全部的服务器列表（PeerEurekaNodes）
当 Eureka Server 收到客户端的注册、下线、心跳请求时，通过 PeerEurekaNode 向其余的服务器进行消息广播，如果广播失败则重试，直到任务过期后取消任务，此时这两台服务器之间数据会出现短暂的不一致。
注意： 虽然消息广播失败，但只要收到客户端的心跳，仍会向所有的服务器（包括失联的服务器）广播心跳任务。
如果网络恢复正常，收到了其它服务器广播的心跳任务，此时可能有三种情况：
1. 一是脑裂很快恢复，一切正常；
2. 二是该实例已经自动过期，则重新进行注册；
3. 三是数据冲突，出现不一致的情况，则需要发起同步请求，其实也就是重新注册一次，同时踢除老的实例。
总之，通过集群之间的消息广播可以实现数据的最终一致性。

Spring Cloud Eureka 在应用启动时，会在 EurekaAutoServiceRegistration 这个类初始化的时候，主动去 Eureka Server 端注册。
Eureka 在启动完成之后会启动一个 40 秒执行一次的定时任务，该任务会去监测自身的 IP 信息以及自身的配置信息是否发生改变，如果发生改变，则会重新发起注册。
续约返回 404 状态码时，会去重新注册

Eureka 会在 spring 容器销毁的时候执行 shutDown 方法，该方法首先会将自身的状态改为 DOWN，接着发送cancle 命令至 Eureka Server 请求下掉自己的服务。

健康检测，一般都是 TTL(Time To Live) 机制。eg: 客户端每 5s 发送心跳，服务端 15s 没收到心跳包，更新实例状态为不健康， 30s 未收到心跳包，从服务列表中删除。

Eureka Server 默认每 30s 发送心跳包，90s 未收心跳则删除。这个清理过期实例的线程，每 60s 执行一次。

Spring Cloud Eureka 启动时，在初始化 EurekaServerBootstrap#initEurekaServerContext 时会调用 PeerAwareInstanceRegistryImpl#syncUp 从其它 Eureka 中同步数据。

发生脑裂后：和 Eureka Server 同区的服务可以正常访问，而不同区的服务则自动过期。
脑裂恢复后：接收其它 Eureka Sever 发送过来的心跳请求，此时有三种情况：一是脑裂很快恢复，一切正常；二是该实例已经自动过期，则重新进行注册；三是数据冲突，出现不一致的情况，则需要发起同步请求。

当有多个 Eureka Server 时，第一台宕机时会从下一台同步数据。注意：只有当第一台宕机时才会同步第二台，否则永远只会从第一台同步数据。

如果每分钟的续约数小于阀值时，则开启自我保护机制，Eureka Server 将不会主动清除过期实例。

每天用心记录一点点。内容也许不重要，但习惯很重要！