zookeeper作为注册中心，也可以作为分布式锁的一种实现。
- ZooKeeper主要服务于分布式系统，可以用ZooKeeper来做：统一配置管理、统一命名服务、分布式锁、集群管理。
- 使用分布式系统就无法避免对节点管理的问题(需要实时感知节点的状态、对节点进行统一管理等等)，而由于这些问题处理起来可能相对麻烦和提高了系统的复杂性，ZooKeeper作为一个能够通用解决这些问题的中间件就应运而生了。
Zookeeper的数据结构可以看做一棵树，每个节点叫做ZNode,每个节点可以通过路径标识。
Znode分为两种类型：
- 短暂/临时：当客户端和服务端断开连接后，所创建的Znode(节点)会自动删除
- 持久：当客户端和服务端断开连接后，所创建的Znode(节点)不会删除
Zookeeper配合监听器才能做好多事情：
常见的监听场景有以下两项：
- 监听Znode节点的数据变化
- 监听子节点的增减变化
每一个微服务中都有eureka client，用于服务的注册于发现，每一个微服务启动的时候，都需要去eureka server注册
Zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等）当A服务需要调用B服务时，需要从eureka服务端获取B服务的服务列表，然后把列表缓存到本地，然后根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用此B服务
当A服务下次再此调用B服务时，如果发现本地已经存储了B的服务列表，就不需要再从eureka服务端获取B服务列表，直接根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用B服务
微服务，默认每30秒，就会从eureka服务端获取一次最新的服务列表
如果某台微服务down机，或者添加了几台机器， 此时eureka server会通知订阅他的客户端，并让客户端更新服务列表， 而且还会通知其他eureka server更新此信息
心跳检测，微服务每30秒向eureka server发送心跳， eureka server若90s之内都没有收到某个客户端的心跳，则认为此服务出了问题， 会从注册的服务列表中将其删除，并通知订阅它的客户端更新服务列表， 而且还会通知其他eureka server更新此信息
eureka server保护机制，通过打卡开关，可以让eureka server处于保护状态，主要是用于某eureka server由于网络或其他原因，导致接收不到其他微服务的心跳，此时不能盲目的将其他微服务从服务列表中删除。
具体规则：如果一段时间内，85%的服务都没有发送心跳，则此server进入保护状态，此状态下，可以正常接受注册，可以正常提供查询服务，但是不与其他server同步信息，也不会通知订阅它的客户端，这样就不会误杀其他微服务
每启动一个微服务，就会去zk注册一个临时子节点，
当有一个服务down机，由于是临时接点，此节点会立即被删除，并通知订阅该服务的微服务更新服务列表 （zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）
每当有一个新的微服务注册进来，就会在对应的目录下创建临时子节点，并通知订阅该服务的微服务更新服务列表 （zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）
每个微服务30s向zk获取新的服务列表
CAP基本概念分布式系统的三个指标
- Consistency 一致性
- Availability 高可用性
- Partition tolerance 分区容错性
eureka基于AP
zookeeper基于CP
由于作为注册中心可用性的需求高于一致性，所以eureka要比zookeeper更合理一些
