Eureka和Zookeeper

eureka做注册中心的流程

1）注册

客户端把自己的ip地址和端口注册到eureka，发生第一次心跳

2）更新

客户端每30秒发送一次心跳到eureka，告知eureka仍存活，如果eureka在90秒时间内没有接收到更新，那么会把客户端从服务列表上删除

3）获取信息

客户端每30秒从eureka获取一张服务列表，如果不同则更新

4）取消

当客户端关机则会发送一个取消的消息给eureka，eureka会把该客户端从服务列表上删除

zookeeper的ZAB协议

1、消息广播模式(数据同步)

1）leade服务器收到事务请求后，会将这个消息赋予一个zxid，并将这些转成一个propose(提议)并放入到一个FIFO的缓存队列中

2）leader将每一个propose分发给每一个follower服务器，follower服务器会把propose这个事务写入磁盘，写入成功后会返回一个ack给leader服务器

3）当leader收到过半数的ack后会向follower发起commit请求

注意：广播过程observer不需要参与

2、崩溃恢复模式(数据恢复)

这种情况在刚启动或者leader宕机时生效

1）通过投票机制选取leader

2）当leader收到半数以上follower的ack后挂掉了，那么所有的follower都需要执行这个事务消息，防止事务被丢失(防止多一条事务)

3）当leader没收到半数以上follower的ack就挂掉了，那么选取新的leader后，原来挂掉的leader重新启动被注册成了follower，并删除最新的一条消息数据，因为要保证整个系统的状态是一致的(防止少一条事务)

CAP定理

C：数据一致性

A：高可用性

P：分区容错性，即整个系统被隔离开，产生网络分区，整个系统仍然可以工作

Eureka保证AP

A：多个eureka相互注册，这些eureka上都保留着服务列表，当某台eureka服务器宕机了，整个eureka系统仍然可以使用，因此eureka具备A

zookeeper保证CP

C：zookeeper的ZAB协议可以保证数据的一致性，但是无法保证高可用性，原因在于当zookeeper里的leader宕机时，整个zookeeper集群会进入选举状态，选举过程中不对外提供服务