CAP理论
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
以上内容摘自 百科
网络分区
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。
以上内容摘自：https://www.zhihu.com/question/54105974/answer/139037688
作者：邬江
因此，eureka作为服务注册中心，字然要保证高可用和容错性，而对于数据一致性不是注册中心所关注的。所以说eureka是一个典型的AP系统，而为了满足C（分区容错性），自然需要这样一个保护机制来保护因为网络或延时造成的服务暂时无法访问的实例，而不是将其剔除。
eureka自我保护机制
一般情况下，某个服务不可用时，例如一定时间内没有检测到心跳或者连接超时等，那么就会将该服务从可用服务列表中剔除，但是在微服务架构中，因为服务数量众多，可能存在跨机房或者跨区域的情况，所以当某个服务心跳探测失败后并不能完全说明其无法正常提供服务而将其剔除，并且服务一旦剔除后，再重新注册将会重新进行负载均衡等等一系列的操作，考虑到性能问题，eureka会将不可用的服务暂时断开，并期望能够在接下来一段时间内接收到心跳信号，而不是直接剔除，同时，新来的请求将不会分发给暂停服务的实例，这就是eureka的保护机制，它保护了因网络等问题造成的短暂的服务不可用的实例，避免频繁注册服务对整个系统造成影响。
自我保护机制实例
我们使用单机版的eureka作为eureka-server，使用1个eureka-client作为eureka的客户端进行服务注册，并且设置等待时间为1分钟(默认为300000ms，即5分钟)：
wait-time-in-ms-when-sync-empty: 60000
2分钟后在eureka的监控界面显示信息如下：
其中右上部分的信息含义为：
并且出现了：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
意为：Eureka可能错误地声称实例在未启动时启动。renews小于设定的阈值，但是不会过期而是保护起来。
说明eureka已经进入了保护模式。
产生原因：
由于只启动了单个eureka-server并且禁止自动注册，所以只有一台实例service-b注册到的注册中心，该实例会每隔30秒向eureka-server发送一次心跳，证明自己还存活，所以，最后1分钟收到的心跳数为2，小于期望收到的心跳次数3，所以会出现这个警告。
实际上，当eureka-server最后一分钟收到的心跳次数小于等于总心跳次数的85%(即小于等于Renews threshold)时会触发保护模式，下面简单说一下Renews threshold的计算方式。
renews阈值计算
Renews threshold 计算公式如下：
Renews threshold = 2 × n × 0.85
正常情况下Renews (last min)计算公式如下：
Renews (last min) = 2 × n
在上面的例子中可以看到，当启动了一个非注册的eureka-server和一个eureka-client时，阈值为3，这里面有一个问题：因为只有一个eureka-client即service-b启动，正常情况下因该是2×1×0.85=1，而不是3，根据测试结果，正确的计算方法应该是：
1.当erureka-server不注册自身时：
Renews threshold = 2 × (n+1) × 0.85
可以看到，当不注册自己时，在默认阈值情况下，当服务数量较小时一定会触发保护机制，其最小数量可由下式计算：
2 × (n+1) × 0.85 < 2 × n
n的最小取值为6
即当n>=6时，非自注册在默认阈值下才不会进入保护模式
2.当erureka-server注册自身时:
Renews threshold = 2 × n × 0.85
renews阈值调整
可以通过以下参数进行调整：
renewal-percent-threshold: 0.7