1、几种常见注册中心区别

2、在分布式数据库中的CAP原理

2.1 传统关系型数据库的ACID分别是什么

关系型数据库遵循ACID规则：事务在英文中是transaction，和现实中的交易很类似，它有如下四个特性：

• A(Atomicity)原子性
• C(Consistency)一致性
• I(Isolation)隔离性
• D(Durabilly)持久性
  所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。（执行单个逻辑功能的一组指令或操作称为事务）

A(Atomicity) 原子性：原子性体现在对于一个事务来讲，要么一起执行成功要么一起失败，执行的过程中是不能被打断 或 者执行其他操作的。
C(Consistency) 一致性：一致性表现为事务进行过后和执行前，整体系统都是稳定的，比如对于入账出账操作是不会有总资金的变化的。
I(Isolation) 隔离性：隔离性表示各个事务之间不会互相影响，数据库一般会提供多种级别的隔离。实际上多个事务是并发执行的，但是他们之间不会互相影响。
D(Durability) 持久性：持久性表示一旦一个事务成功了，那么他的改变是永久性的被记录和操作。

详细见：https://blog.csdn.net/u012440687/article/details/52116108

2.2 nosql数据库的CAP是什么

CAP是分布式系统中进行平衡的理论，它是由 Eric Brewer发布在2000年。

• C(Consistency)强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
• A(Availability)可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• P(Partition tolerance)分区容错性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

2.3 CAP图谱分析

CAP理论就是说在分布式存储系统中，最多只能同时较好的满足两个，而由于当前的网络硬件要求肯定会出现延迟丢包等问题，所以分区容错性是必须实现的。（只能在一致性和可用性之间权衡，没有nosql系统能同时保证这三点）
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求。因此，根据CAP原理将nosql数据库分成了满足CA原则、满足CP原则和满足AP原则三大类：

• CA – 单点集群，满足一致性、可用性的系统，通常在可扩展性上不太强大，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
• CP – 满足一致性，分区容错性的系统，通常性能不是特别高。很多传统的数据库分布式事务都属于这种模式
• AP – 满足可用性，分区容错性的系统，通常可能对一致性要求低一些（淘宝双11选择ap）

2.4 作为注册服务中心，eureka比zookeeper好在哪里？

(1)Zookeeper 保证的是CP（一致性和分区容错性）

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

(2)Eureka 保证的是AP（可用性和分区容错性）

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种之外保护机制，如果再15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

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