SpringCloud五大神兽之Eureka服务注册（三）——Eureka的自我保护

一、ACID与CAP

传统ACID：

A：atomicity   原子性

C：consistency    一致性

I：isolation    独立性

D：durability    持久性

目前流行的CAP：

C：consistency    强一致性

A：availability      高可用性

P：partition tolerance     分区容错性

二、分布式下的CAP

目前市面上没有任何一个分布式系统能够同时满足CAP的三个特性，只能三进二，即三个中仅能选择满足其中的两个。而在目前的分布式系统中必须得满足P，所以只能选CP或者AP。

例如：在淘宝的双十一节期间只能选择AP型，要首先保证系统的高可用性，否则一旦使得系统崩溃，损失将会是致命的。但在双十一节过后，需要对每一个商品的种类，，每一个宝贝进行收藏，购买等的统计，就必须要满足数据的强一致性，则应该选择CP。

三、Eureka保证CP，Zookeeper保证AP

在使用zookeeper作为分布式时，若出现网络延迟等原因，导致某一个节点，尤其是主节点死机的情况下，剩下的zookeeper节点就会重新进行选举，而选举时长会长达好几分钟，此时的zookeeper是不可用的，系统无法被访问，这对高可用的系统是致命的。

而Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样导致整个注册服务瘫痪。这是由于Eureka的自我保护机制。

四、什么是Eureka的自我保护机制

当Eureka在15分钟以内注册中心的微服务突然85%失去心跳时，Eureka就会认为客户端和注册中心（Eureka）出现了网络故障，就会开启自我保护机制。

1.不会再从注册表中移除长时间没有心跳而应该过期的服务

2.仍能够接受新服务的注册和查询请求，但不会同步到其他节点上去。（保证当前节点可用）

3.当网络稳定时，当前实例新的注册信息会被同步到其他节点中。

一句话：某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该服务的信息进行保存。

在自我保护模式中，Eureka Server 会保护服务注册表中的信息，不再注销任何服务实例。当它收到心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目的注销任何可能健康的服务实例，即好死不如赖活着。

综上所述，自我保护模式是一种应对网络异常的安全保护措施。使用自我保护模式，可以让Eureka集群更加的健壮稳定。

在SpringCloud中，可以使用 eureka.server.enable-self-preservation = false 禁用自我保护模式。

Eureka的自我保护机制虽然很好的解决了因网络故障带来的系统无法访问的问题，但也为数据的一致性产生了风险。