Eureka CPA学习内容

一、Eureka CPA学习内容

C(Consistency)强一致性

A(Avaliablitu)可用性

P(Partition tolerance)分区容灾

CAP的三进二： CA、 AP、 CP

== CAP理论的核心 ==

• 一个分布式系统不可能同事很好的满足一致性,可用性和分区容灾这三个需求。

• 根据CAP原理，将NoSql数据库分成了满足CA AP CP原则三大类：

  1、CA: 单点集群，满足一致性，可用性的系统，通常可扩展性较差。
  2、CP: 满足一致性，分驱容错性的系统，通常性能不是特别高。
  3、AP: 满足可用性，分区容错性的系统，通常可能对一致性要求低一些。

作为服务注册中心，Eureka比Zookeeper好在哪里？

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。
  * Zookeeper保证的是CP
  * Eureka保证的是Ap

zk当master节点down后与其他节点失去联系时，剩余节点会停止服务去选取leader，选举时常约在30~120s(因环境稳定)，选举期间zk集群都不可用，
注册服务瘫痪。

Eureka优先保证可用性A,由于Eureka的各个节点等级平等，所以只要有节点存活都不会出现系统奔溃现象；Eureka还有自我保护机制，如果在15分钟内超过85%的节点
都没有正常的心跳，那么Eureka就会认为客户端与注册中心出现了网络故障，此时会出现一下几种现象：

• Eureka不再从注册中心中移除因长时间没有收到心跳而应该过期的服务。
• Eureka依然能够接受新的服务的注册和查询请求，但是不会被同步到其他的节点上（既保证当前节点依然可用）
• 当网络稳定时，当前实例新的注册信息会被同步到其他的节点。

结论： Eureka可以很好的应对因为网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样瘫痪，但在极端情况下会出现各个节点数据不一致的现象。

二、Ribbon学习

• 添加依赖

		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

        <!--需要拿到实体类，所以配置api module-->
        <dependency>
            <groupId>org.yogn</groupId>
            <artifactId>springCloud-api</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

• 配置application、在RestTemplter中添加注解 @LoadBalanced 注解后，就可以用服务名称来调用接口了。

资料：http://c.biancheng.net/view/5356.html

• 测试通过IRule自定义负载均衡策略规则

• 自定义负载均衡策略