标签：enter   执行   idt   ddl   问题   接受   更新   body   nsis   

Eureka简介

　　Eureka是Nerflix公司开源的一款服务发现（或注册中心）组件，该组件提供的服务发现可以为负载均衡、failover等提供支持。

　　Eureka包括Eureka Server和Eureka Client。Eureka Server提供REST服务，Eureka Client则是使用Java编写的客户端，用于简化与Eureka Server的交互。

服务发现组件对比

CAP理论

　　分布式领域有个重要的CAP理论：

1. Consistency：数据一致性，即数据存在多个副本的情况下，可能由于网络、机器故障、软件系统等问题导致数据写入部分副本成功，部分副本失败，进而造成副本之间的数据不一致，存在冲突。满足数据一致性要求对数据的更新操作成功后，多副本的数据报保持一致。
2. Availability：高可用，即任何时候客户端对集群进行读写操作时，请求能正常响应，即在一定的延迟内完成。
3. Partition Tolerance：分区容忍性，即发生通信故障时，整个分区被分割为多个相互独立的无法通信的分区时，集群仍可用。

　　对于分布式系统，一般网络条件不可控，出现网络分区是不可避免的，因此系统必须具备分区容忍性。

分布式系统的数据在多个副本之间的复制方式

　　一般而言，分布式系统的数据在多个副本之间的复制方式可分为主从复制和对等复制。

　　主从复制即Master-Slave模式，即有一个主副本，其他副本为从副本。所有对数据的写操作都提交到主副本，最后再由主副本更新到从副本，具体的更新方式有同步更新、异步更新、同步及异步混合。对于主从复制模式，写操作的压力主要都在主副本，从副本帮主副本分担读操作请求。

　　对等复制即Peer to Peer，即任何副本都是对等的，任何副本都可以接收写操作请求，然后每个副本进行数据更新。

Zookeeper的CP原则

　　Zookeeper默认并不是严格的强一致性，比如客户端A提交一个写操作，Zookeeper在半数节点操作成功后就返回，此时假设客户端B读操作请求的恰好是A写操作尚未同步到的节点，那么读取到的就不是客户端A写操作成功后的数据。

　　如果需要保证数据的强一致性，则需要在读取数据的时候先执行一下sync操作，即与leader节点先同步下数据。

　　Zookeeper不满足高可用特性，当 master 节点(主副本)因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。

Eureka的AP原则

　　Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。

　　而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。

　　除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中.

　　因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样便整个注册服务瘫痪。

SpringCloud Eureka认知(一)

标签：enter   执行   idt   ddl   问题   接受   更新   body   nsis   

原文地址：https://www.cnblogs.com/dandelZH/p/11051905.html