Spring Cloud(3)——Eureka配置与CAP原则

1、Eureka配置

• Eureka Client服务启动时，会将自己的信息注册到Eureka Server上

• 当Eureka Client调用其他服务时，先查询本地有没有目标服务的信息，没有则从Eureka Server上拉取

• Eureka Client定时向Eureka Server发送一次消息(心跳请求)，以通知注册中心自己处于“还活着”状态。默认是30s发送一次心跳请求，如果Eureka Server在给定时间内没有收到Eureka Client的消息，则会认为这个Client已经宕机，那么Eureka Server会移除掉此Eureka Client的注册信息。心跳间隔和宕机判定时间可通过如下参数设置：

  eureka:
    instance:
      lease-renewal-interval-in-seconds: 45			#心跳间隔时间，单位s
      lease-expiration-duration-in-seconds: 120		        #宕机判断时间，单位s
  

• Eureka Client会定时从Eureka Server更新一次本地缓存中的注册信息。默认也是30s，可通过如下参数设置：

  eureka:
    client:
      registry-fetch-interval-seconds: 45
  

• Eureka Server自我保护机制：当15分钟内，如果一个服务的心跳发送比例低于85%，Eureka Server就会启动此机制。表现为：

  • 不会移除长时间未发送心跳信息的服务，以保证服务的可用性
  • 在网络稳定时，Eureka Server节点之间才会同步服务注册信息

  Eureka Server的自我保护机制可通过如下配置启用或关闭：

  eureka:
    server:
      enable-self-preservation: true		#是否开启Eureka Server的自我保护机制，默认为true——开启
  

2、CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡。

• 满足CA舍弃P，也就是满足一致性和可用性，舍弃容错性。但是这也就意味着你的系统不是分布式的了，因为涉及分布式的想法就是把功能分开，部署到不同的机器上。

• 满足CP舍弃A，也就是满足一致性和容错性，舍弃可用性。如果你的系统允许有段时间的访问失效等问题，这个是可以满足的。就好比多个人并发买票，后台网络出现故障，你买的时候系统就崩溃了。

• 满足AP舍弃C，也就是满足可用性和容错性，舍弃一致性。这也就是意味着你的系统在并发访问的时候可能会出现数据不一致的情况。

实时证明，大多数都是牺牲了一致性。像12306还有淘宝网，就好比是你买火车票，本来你看到的是还有一张票，其实在这个时刻已经被买走了，你填好了信息准备买的时候发现系统提示你没票了。这就是牺牲了一致性。

但是不是说牺牲一致性一定是最好的。就好比mysql中的事务机制，张三给李四转了100块钱，这时候必须保证张三的账户上少了100，李四的账户多了100。因此需要数据的一致性，而且什么时候转钱都可以，也需要可用性。但是可以转钱失败是可以允许的。

Eureka使用的是AP模式。

原文：https://www.cnblogs.com/wind-ranger/p/14496067.html