创新互联建站-专业网站定制、快速模板网站建设、高性价比江陵网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式江陵网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖江陵地区。费用合理售后完善,十载实体公司更值得信赖。
服务注册中心不可能是单点的,一定会有一个集群,那么集群中的服务注册信息如何在集群中保持一致的呢?
首先要明确的是 Eureka 是弱数据一致性的。
下面从2个方面来说明:
我们知道 ZooKeeper 也可以实现数据中心,ZooKeeper 就是强一致性的。
分布式系统中有一个重要理论:CAP。
该理论提到了分布式系统中的3个特性:
分布式系统中,数据会存在多个副本中,有一些问题会导致写入数据时,一部分副本成功、一部分副本失败,造成数据不一致。
满足一致性就要求对数据的更新操作成功后,多副本的数据必须保持一致。
在任何时候客户端对集群进行读写操作时,请求能够正常响应。
发生通信故障时,集群被分割为多个无法通信的分区时,集群仍然可用。
CAP 理论指出:这3个特性不可能同时满足,最多满足2个。
P 是客观存在的,不可绕过,那么就是选择 C 还是选择 A。
ZooKeeper 选择了 C,就是尽可能的保证数据一致性,某些情况下可以牺牲可用性。
Eureka 则选择了 A,所以 Eureka 具有高可用性,在任何时候,服务消费者都能正常获取服务列表,但不保证数据的强一致性,消费者可能会拿到过期的服务列表。
Eureka 的设计理念:保留可用及过期的数据总比丢掉可用的数据好。
分布式系统的数据在多个副本之间的复制方式,主要有:
就是 Master-Slave 模式,有一个主副本,其他为从副本,所有写操作都提交到主副本,再由主副本更新到其他从副本。
写压力都集中在主副本上,是系统的瓶颈,从副本可以分担读请求。
就是 Peer to Peer 模式,副本间不分主从,任何副本都可以接收写操作,然后每个副本间互相进行数据更新。
对等复制模式,任何副本都可以接收写请求,不存在写压力瓶颈,但各个副本间数据同步时可能产生数据冲突。
Eureka 采用的就是 Peer to Peer 模式。
Eureka Server 本身依赖了 Eureka Client,也就是每个 Eureka Server 是作为其他 Eureka Server 的 Client。
Eureka Server 启动后,会通过 Eureka Client 请求其他 Eureka Server 节点中的一个节点,获取注册的服务信息,然后复制到其他 peer 节点。
Eureka Server 每当自己的信息变更后,例如 Client 向自己发起注册、续约、注销请求, 就会把自己的最新信息通知给其他 Eureka Server,保持数据同步。
如果自己的信息变更是另一个Eureka Server同步过来的,这是再同步回去的话就出现数据同步死循环了。
Eureka Server 在执行复制操作的时候,使用 HEADER_REPLICATION
这个 http header 来区分普通应用实例的正常请求,说明这是一个复制请求,这样其他 peer 节点收到请求时,就不会再对其进行复制操作,从而避免死循环。
还有一个问题,就是数据冲突,比如 server A 向 server B 发起同步请求,如果 A 的数据比 B 的还旧,B 不可能接受 A 的数据,那么 B 是如何知道 A 的数据是旧的呢?这时 A 又应该怎么办呢?
数据的新旧一般是通过版本号来定义的,Eureka 是通过 lastDirtyTimestamp
这个类似版本号的属性来实现的。
lastDirtyTimestamp
是注册中心里面服务实例的一个属性,表示此服务实例最近一次变更时间。
比如 Eureka Server A 向 Eureka Server B 复制数据,数据冲突有2种情况:
(1)A 的数据比 B 的新,B 返回 404,A 重新把这个应用实例注册到 B。
(2)A 的数据比 B 的旧,B 返回 409,要求 A 同步 B 的数据。
还有一个重要的机制:hearbeat 心跳,即续约操作,来进行数据的最终修复,因为节点间的复制可能会出错,通过心跳就可以发现错误,进行弥补。
例如发现某个应用实例数据与某个server不一致,则server放回404,实例重新注册即可。