| 服务注册发现原理 | 一致性保障-CAP原理 | 服务注册发现的时效性 | 容量 | |
|---|---|---|---|---|
| zookeeper | 集群中分为1个leader其他的机器为follower，只有leader能够进行写操作，即服务注册，然后把数据同步给follower，leader/follower都可以进行读 | 保证CP，即一致性，当zk集群中的leader挂掉，会重新进行leader的选举，在此期间整个集群处于不可用状态，直到选举出leader | 时效性更好，注册或者挂了，一般秒级就能感知到 | zk不适合部署大规模服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例（consumer），所以一旦服务规模太大，到了几千个机器的时候，会导致网络带宽短时间被大量占用 |
| erueka | peer-to-peer,集群中每台机器的地位是相等的，各个服务可以向任何一个Eureka实例进行服务注册和服务发现，集群里任何一个Eureka实例接收到写请求之后，会自动同步给其他所有的Eureka实例 | 保证AP，一台Eureka刚接受到服务注册信息没来得及同步到其他实例就挂了，其他实例依然可以提供服务发现功能，只不过数据不是最新的，只能保证最终一致性 | 默认配置下，服务发现和感知需要十几秒甚至分钟级别 | eureka也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求 |
为什么zk时效性好
zk的客户端可以在znode上创建watch对象，用于监听znode的相关事件 新增子node、修改、删除等，当发生事件时会及时获得通知。
而eureka采用多级缓存，定时轮询等存储更新服务列表，所以时效性相对较差
