微信公众号:Java患者 专注Java领域技术分享
目前这三个指标不可能同时做到。这个结论就叫CAP定理。
大多数的分布式系统都分布在多个服务器下的子网络。每个子网络就叫做一个区(partition)。
比如一台服务器放在北京,另外一台服务器放在东京,这就是两个区,他们之间的通信可能失败,可以理解为分区容错。
上图,server1跟server是两台跨区的服务器,server1向server2发送一条消息,server2可能无法收到。所以一般来说,分区容错是无法避免的,因此CAP的P总是成立的。
Consistency 一致性,理解为 当有一个写操作之后的读操作,就必须返回该值,假如server1中有一个变量i = 1,client向server1发起了一个写操作 i = 2 ,那么client读到的就是i = 2。
但是 用户可能从server2中发起读操作,由于server2的值没有发生变化,因此返回的i=1,所以server1跟server2读取的值不一致,这就不满足一致性。
所以为了让server1跟server2返回的值一致,我们需要在往server1执行写操作的时候,让server1给server2发送一条消息,让server2的i = 2。
可用性,意思就是server收到用户的请求,服务器就必须给出回应,不管是哪台服务器,只要收到,不管这个时候是i=1还是i=2 ,都要回应给客户,否则就不满足可用性。
当我们为了要保证一致性的时候,server1跟server2就必须数据同步,在同步的过程中,server2就必须有一个锁定的时间,只要同步完数据之后,才能重新放开读写操作,这个时候满足了一致性,但是却不满足可用性。所以C跟A只能选择一个。
Eureka 在设计的时候遵循的是AP原则,因为各个节点都是平等的,当搭建了eureka集群之后,就算有宕机了eureka,服务依然可以注册到剩余的eureka。只要有一台eureka还在,就能保证注册时可用的,保证了可用性。但是查询到的信息不一定是最新的,不保证强一致。
Zookeeper在设计的遵循的是CP原则,当master节点故障的时候,剩余的节点会重新选举一个master出来,而选举过程中整个zookeeper集群是不可以用的,因此做不到高可用。