1 Eureka
一般注册中心会用比较高配置的机器来做，如：8核16G、16核32G等高配置机器，基本上可以做到每台机器的QPS到几千没有问题。
1、AP和CP
2、时效性，如ZK的Leader挂掉的情况下的时效性
1.1 服务注册和发现
服务注册表：即存储服务注册的数据
多级缓存：ReadWriteCache、ReadOnlyCache。
注册：当服务A向Eureka中注册服务信息后，会
服务注册表的数据会立刻同步给ReadWriteCache。而ReadOnlyCache的缓存通过定时任务从ReadWriteCache中定时同步-
发现：服务C只会从
ReadOnlyCache中获取服务注册信息注：若
ReadOnlyCache为空，则会从ReadWriteCache中获取，若ReadWriteCache为空，则会从服务注册表中获取。获取到数据后，同步到ReadWriteCache和ReadOnlyCache中，之后就只从ReadOnlyCache中获取。即：服务C ---->ReadOnlyCache(空)---->ReadWriteCache(空)---->服务注册表 目的：多级缓存用于避免并发。即：若服务发现直接从
服务注册表中读数据，服务注册同时也会向服务注册表中写数据。就会有并发读写情况
注意，多级缓存的数据：无论服务A上线or下线，都会将ReadWriteCache内容清空。
1.2 心跳与故障
基本逻辑：
服务A和服务B定时发送心跳
Eureka中定时任务A如果发现服务A挂掉，则会清理
服务注册表中服务A的信息Eureka会立刻将
ReadWriteCache中的所有注册信息都清除在此期间，服务C仍然会拉取
ReadOnlyCache中的数据（即仍然包含服务A），因此调用服务A的请求会失败直到定时任务B将
ReadWriteCache中的空列表同步给ReadOnlyCache，此时ReadOnlyCache也会为空此时服务C在进行服务发现时，就会从
服务注册表中获取最新的列表，并填充到ReadWriteCache和ReadOnlyCache中
1.3 ZK和Eureka
1、服务发现
ZK（Push）：服务监听ZK节点列表变更事件，服务列表发生变更后，由ZK主动通知
Eureka（Pull）：服务自己定时主动拉取
2、数据一致性
Eureka（AP）：peer-to-peer，部署一个集群，但集群所有Eureka节点地位同等，各服务都可以向任何一个Eureka节点进行服务注册和发现。集群中任何一个Eureka节点接收到写请求后，会自动同步给其他所有Eureka实例。
Eureka的最终一致：假如有Eureka集群，E1、E2两台。当S1向E1注册后，E1尚未同步给E2即E1就挂掉了，S1和E1心跳发现E1宕机后，S1会继续向E2注册。
3、服务注册的时效性
ZK，时效性更好，注册或者挂了，一般秒级就可以感应到
Eureka，默认配置糟糕，服务发现感知要几十秒，甚至分钟级别。
4、容量
ZK，不适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送大量数据通知到所有的其他服务实例，所以一旦服务规模太大，到了几千个服务实例的时候，会导致网络带宽被大量占用。一般上百到1千就差不多了。即：ZK服务节点变更，会大规模推送数据到服务节点。
Eureka，也很难支撑大规模的服务实例，因为每个Eureka实例都要接受所有的请求，实例多了压力太大扛不住，也很难到几千服务实例。即：点对点服务，会产生大量的心跳同步信息。
3 ZK脑裂
1、ZK脑裂
对于Zookeeper来说，判断一个节点是否死亡的方式是：心跳。使用ZooKeeper来做master HA通用模式如下：
每个节点都尝试注册一个象征master的临时节点，注册成功则成为Master
没有注册成功的则成为slaver，并且通过watch机制监控着master所创建的临时节点
Zookeeper通过内部心跳机制来确定master的状态
一旦master出现意外Zookeeper能很快获悉并且通知其他的slaver，其他slaver在之后作出相关反应。这样就完成了一个切换
心跳出现超时可能有2种情况：
是master挂了
master和ZK之间网络出现问题。
情况2即假死。master并未死掉，但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换，这样slaver中就有一个成为了master，但是原本的master并未死掉。此时系统可能短暂出现混乱：
2、分布式锁的问题
如果ZK客户端A和ZKServer之间因为网络问题，导致通信暂时异常（没有任何服务器宕机），此时ZKServer没有收到心跳之后，就会将锁删除。ZKServer就会通知ZK客户端B进行加锁，ZK客户端B也加锁成功
