- eureka功能
- eureka注册生效延时
- CAP定理在eureka中的应用
- eureka的数据复制方式
Eureka功能
Eureka是spring cloud生态下的服务注册中心组件, 类似功能的常用组件还有zookeeper, consul等, 在spring cloud中, eureka提供如下功能的服务
- 服务注册
微服务架构中的提供者也就是Eureka客户端，在其启动的时候，回向Eureka服务器注册自己的信息，同时Eureka服务器会维护一个一注册的服务列表
- 服务发现
Eureka客户端启动时会从Eureka服务器中获取注册表信息，并将其缓存在本地，改注册表信息定期（默认30秒）从Eureka服务器中进行同步，每次返回注册列表信息可能不同，有Eureka客户端自动处理。
- 服务续约
当注册成功后，eureka客户端会每隔30秒（可配置）的频率想Eureka服务器发送一次心跳，发送心跳其实就是执行服务续约操作，避免自己的注册信息被Eureka服务器删除，续约处理和服务注册基本一致。
- 服务下线
当服务实例关闭时，会先向Eureka服务器发送服务下线申请，Eureka服务器会将该实例从注册表中删除
Eureka注册生效延时
在Eureka服务治理环境下，一个微服务上线有3处缓存处理和1处延迟处理，经过这些处理后才能够被服务消费方获取道并使用 1. Eureka服务器对服务注册列表进行缓存，默认30秒。也就是即使注册车更能够给你也不会立即在结果中出现 2. Eureka客户端/消费方对注册服务信息进行缓存，默认时间30秒。也就是客户端本地刷新并发现其他实例可能需要30秒 3. Ribbon负载均衡，获取Eureka客户端的服务列表，并将负载均衡后的结果缓存30秒 4. Eureka客户端启动时（不是启动完成）不是立即向Eureka服务器注册自己，而是延迟默认40秒后才会注册 综上：一个新的实例从启动到可用最多可能需要2分钟左右。
CAP定理在Eureka中的应用
Eureka用的是AP，在大规模部署的情况下（比如微服务），失败是不可避免的，包括Eureka服务本身的失败等，需要Eureka再出现网络分区的时候依然可用，也就是AP。在实际生产实践中，服务注册即发现中心保留可用及过期的数据总比丢失掉可用的数据要好，这样的话集群中所有的节点并不是强一致性的，即使注册中心的不同节点保存的服务提供者信息不相同，也不会造成灾难性的后果, 这就需要客户端支持负载均衡及失败重试，在Netflix的生态中，有ribbon提供这个功能
Eureka的数据复制方式
一般而言，分布式系统数据在多个副本间的复制方式，可分为主从复制和对等复制 主从复制：也就是Master-Slave模式，又一个主副本，其他的为从副本，所有的对数据的写操作都要提交到主副本，在后再有主副本更新到其他副本， 更新方式分为同步更新、异步更新、同步异步混合。 由于写操作都在主副本上，所以他是整个系统的瓶颈，读操作是可分担到从副本上 对等复制：Peer to Peer模式，副本间部分主从，任何副本都可以接受读写操作然后相互更新各个副本之间的同步及冲突处理是比较棘手的问题, Eureka采用的就是这种方式
