Eureka

缓存：

1. 消费者每30s发送一个心跳，每30s请求更新一次服务注册表，则每分钟4次请求注册中心服务端。

假设有2000个消费者、提供者实例，则每分钟有4 * 2000 = 8000 次请求。每秒 8000 / 60 = 133 的并发量。

2. 将注册表基于内存进行操作可以提高速度，但是容易出现读写（消费者读，提供者写）并发问题。所以进行将内存进行读写分离。

3. 消费者会30s请求只读缓存（Google 开发的一个只读缓存策略，定时器每30s请求一次读写缓存）。

4. 读写缓存起到一个缓冲作用，作用于只读缓存和注册表内存中间，避免只读缓存直接落到注册表内存。

5. 当用户消费者第一次拉取服务注册表的时候，只读缓存和读写缓存都为空。先找只读缓存，找不到，再找读写缓存，再找不到，再找注册表内存，拉取到一个订单服务实例。

6. 订单服务再注册一个实例，到注册表内存，即注册表内存发生了变化。

7. 就会过去过期读写缓存，但不会使只读缓存发生变化。

8. 只读缓存，只有当定时器30s到了，才会去同步读写缓存，发现读写缓存过期了为空，则只读缓存拉取就为空，使自己只读缓存也为空。

9. 当用户消费者30s，到只读缓存拉取注册表为空，则去读写缓存拉取注册表，发现还是空，再去注册表内存拉取新的两个订单服务的实例。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

注意：第一次只读缓存、读写缓存都为空

流程：

1. provider注册到注册中心

2. consumer 第一次到只读缓存拉取服务注册表，为空，再到读写缓存拉取服务注册表，为空，再到注册表内存拉取服务注册表，一个provider实例。

3. 当第二个provider实例注册到注册中心，使注册表内存发生变化。

4. 当注册表内存发生变化，会使读写缓存过期，使读写缓存为空。

5. 只读缓存定时器，每30s同步一次读写缓存，但读写缓存为空，则同步自己（只读缓存）也为空。

6. 当consumer 定时器每30s请求一次只读缓存拉取服务注册表，发现为空，再到读写缓存拉取服务注册表，为空，再到注册表内存拉取服务注册表，两个provider实例。

注意：当只读缓存，不为空时，不会去同步读写缓存。所以当只读缓存为空时，才会同步读写缓存。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

运行流程：

1. 服务提供者需要将自己注册到注册中心服务端（原理：将元数据封装成一个Restful接口请求发送到注册中心服务端）。

2. 注册中心将服务保存到一个双层Map中，第一层Key为服务名，第二层Key为实例名。

3. 注册完成后，服务提供者需要维护一个心跳机制（每30s发送一个心跳到注册中心，注册中心每60s将会踢出90s没有发送心跳的实例，即就是连续3次30s没有发送心跳）—— 服务续约。

4. 服务消费者每30s会发送一个请求（Restful接口）到注册中心，获取一份只读注册清单，该清单每30s更新一次。

5. 服务消费者拿到 ip + portal + host，Rabbin 调用服务提供者（默认是轮询）—— 服务调用。

6. 如果需要关闭服务提供者，或者下线服务提供者，也会发送下线请求（ip + portal 元数据Restful接口）到注册中心，注册中心再将此实例的下线时间广播到各个实例。

7. 如果服务提供者异常shutdown，服务注册中心每60s会检查当前清单中，超过90s没有发送心跳（即就是连续3次30s没有发送心跳）的实例进行踢出 —— 失效踢出。

8. 如果有一片区域的集群机器网络波动网络问题，大批量机器没有发送心跳没有3次续约，则Eureka注册中心服务端会有一个自我保护机制（服务注册中心会在运行期间统计服务续约的比例，当所有的服务在15min内心跳比率是否低于阈值85%，就将当前的实例注册信息保护起来，再发出警告warn，并且不会再删除注册表中的信息）。缺点：导致由于异常未发送心跳（续约通知）的服务不能够被正常的踢出，消费者容易获取已经失败的服务提供者。

9. 修改心跳续约30s，可能会导致自我保护机制失效。eureka客户端默认是30s发送心跳机制，注册中心服务端期望收到最大的心跳算法公式时间是：  

	实例数 * 每分钟收到心跳次数 * 阈值
例如：	2 * 60s / 30s * 85% = 3.4 个
发送心跳续约时间修改为：	2 * 60s / 15s * 85% = 6.8 个
如果实例数挂掉一个为：	1 * 60s / 15s * 85% = 3.4 个

eureka注册中心服务端期望收到心跳的时间间隔为30s，期望每分钟收到2次心跳，写死在源码中。换句话说，就是，修改客户端心跳续约时间，并不能修改注册中心服务端的期望心跳续约数值，因为服务端期望数值30s是在源码中写死的。

10. 服务同步，注册中心服务端集群，会维护一个注册信息表，相互同步注册信息。

Q

1. 如果eureka突然宕机，服务间是否还能继续通信？

是可以的。消费者会缓存一份注册信息到本地，通过ip + portal + host 可以继续访问提供者。