Eureka的服务保护模式，多级缓存机制和心跳机制

1、服务保护模式（自我保护模式）

一般情况下，微服务在Eureka上注册后，会每30秒发送心跳包，Eureka通过心跳来判断服务时候健康，同时会定期删除超过90秒没有发送心跳服务。

导致Eureka Server接收不到心跳包的可能：一是微服务自身的原因，二是微服务与Eureka之间的网络故障。通常微服务的自身的故障只会导致个别服务出现故障，一般不会出现大面积故障，而网络故障通常会导致Eureka Server在短时间内无法收到大批心跳。虑到这个区别，Eureka设置了一个阀值，当判断挂掉的服务的数量超过阀值时，Eureka Server认为很大程度上出现了网络故障，将不再删除心跳过期的服务。

那么这个阀值是多少呢？Eureka Server在运行期间，会统计心跳失败的比例在15分钟内是否低于85%，如果低于85%，Eureka Server则任务是网络故障，不会删除心跳过期服务。

这种服务保护算法叫做Eureka Server的服务保护模式。

这种不删除的，90秒没有心跳的服务，称为无效服务，但是还是保存在服务列表中。如果Consumer到注册中心发现服务，则Eureka Server会将所有好的数据（有效服务数据）和坏的数据（无效服务数据）都返回给Consumer。

2、关闭服务保护模式

关闭自我保护:true为开启自我保护，false为关闭自我保护
eureka.server.enableSelfPreservation=false

清理间隔(单位:毫秒，默认是60*1000)，当服务心跳失效后多久，删除服务。
eureka.server.eviction.interval-timer-in-ms=60000

3、Eureka多级缓存机制

Eureka Server为了避免同时读写内存数据结构造成的并发冲突问题，还采用了多级缓存机制来进一步提升服务请求的响应速度。

1、在拉取注册表的时候：

首先从ReadOnlyCacheMap里查缓存的注册表。 若没有，就找ReadWriteCacheMap里缓存的注册表。 如果还没有，就从内存中获取实际的注册表数据。

2、在注册表发生变更的时候：

会在内存中更新变更的注册表数据，同时过期掉ReadWriteCacheMap。 此过程不会影响ReadOnlyCacheMap提供人家查询注册表。

一段时间内（默认30秒），各服务拉取注册表会直接读ReadOnlyCacheMap 30秒过后，Eureka Server的后台线程发现ReadWriteCacheMap已经清空了，也会清空ReadOnlyCacheMap中的缓存 下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充各个缓存。

多级缓存机制的优点是什么？

尽可能保证了内存注册表数据不会出现频繁的读写冲突问题。 并且进一步保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高。

4、Eureka心跳机制

在应用启动后，节点们将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。