Java eureka server集群 euraka集群配置

1.Eureka集群环境配置

本质：互相注册。

注意：但在一个服务器上去模拟集群部署时，需修改配置本地host文件的loaclhost镜像，因为相同intance.name会被默认为只有一个注册中心，而不会去访问其他EurekaSever

 

大致跟一个Eureka相似，不同之处在于EurekaServer之间要相互绑定，

eg:

 

 

注意：7001，7002，7003均是EurekaSever，就是端口号不同，上图就是7001绑定了7002，7003；7002，7003也这样修改就可以了，实现了互相的绑定，三者是平行关系，作用是备份

 

服务提供者相关配置：yaml格式

eureka:
  client:
    service-url:
      defaultZone:注册到所有EurekaSever中（url），每个url用逗号隔开

 

 

 

 

CAP原则

RDBMS（mysql，sqlsever，oracle）=》ACID原则

NoSql（redis，mongdb）=》CAP

ACID：

 A　 原子性（atomicity)

C　  一致性（consistency)

I　　隔离性（isolation）

D　 持久性（durability）

CAP：

C　　一致性（Consistency）

A　　可用性（Availability）

P　　分区容错性（Partition tolerance)

 

CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。（重点）

 

 

 

各组合的特点：

CA：单点集群，满足一致性和高可用性，通常扩展性比较差

CP；分区容错系统，因为一致性比可用性强，所以拉低了性能

AP；分区容错系统，一致性较低

 

注意：因为zookeeper和eureka都必须保留集群部署的能力所以，两者只能在CP，AP中选择

 

ZooKeeper保证的是CP

因为保证了CP,强调一致性（要体现一致性就必须保持主从关系才能实现），所以当集群中的master（主要的）节点，因网络故障等原因与其它节点失去联系时，剩余的节点会重新选举leader，er选举leader的时间会很长30s~120S这之间所有注册的服务都会瘫痪，这时不可容忍的情况

 

Eureka保证AP

自我保护机制就是AP的主要体现，注册中心和其他服务（包括注册中心服务）都是依靠心跳去监控各服务的健康的，当同一时间有大量服务没有心跳，就会自动触发自我保护机制，核心思想是，宁可保护一个可能是坏掉的服务，也不消除一个可能健康的服务，

这样的结果就是，即便在EurekaSever集群中的某个节点坏掉了，也不会影响整个系统的正常运行

 

总结：

　　zookeeper为强调一致性，他的注册中心集群会有主从关系，当主节点挂掉后，剩余的节点会重新选取leader，这期间整个注册与发现服务将会瘫痪，影响项目的运行

　　Eureka强调高可用性，集群节点间是平行关系，即便其中一个节点挂掉，并不会影响其他服务的运行