ZK应用于分布式环境的协调场景,首先看一下分布式的基础概念。
分布式系统:不同计算机之间彼此经过消息传输进行通信与协调的系统。
分布式特点:
- 分布性。服务分布在不同机器上,且会随时变动。
- 对等性。系统中的机器无主从之分,各节点平等。“副本”包括:
- 数据副本:不同节点持久化同一份数据,防止单点故障
- 服务副本:不同节点部署同一份服务,防止单点故障
- 并发性。不同节点会并发性的访问同一资源。
- 缺乏全局时钟。主要是缺少判断先后顺序的依据。系统中的进程分布在不同节点,不能判断进程之间的先后顺序;各进程交换消息过程中无法判断消息的先后顺序cew
- 故障总会发生
分布式环境中的各种问题:
- 通信异常。
- 消息延迟:分布式节点之间通过网络传输数据,而集中式是基于内存通信。
- 消息丢失:网络不可用,或者是网络设备故障。
- 网络分区。分布式系统中的一些节点可以正常通信,但是另一部分节点可能不能正常通信,有时这个小集群可能代替原有集群完成数据操作,这叫网络分区,又称为脑裂。
- 节点之间的请求与响应,存在三种状态:成功、失败、超时。超时:发送请求时由于网络原因丢失消息;响应请求时由于网络原因丢失消息。
- 节点故障
CAP基础
一个分布式系统最多满足一致性(Consistency)、可用性(Available)、分区容错性(Partition Tolerance)中的两个。
一致性:
各副本数据保持同步。
一致性级别:
强一致性:系统写入数据成功,承诺可以立刻读取到写入的值,用户体验很好,但是对系统性能影响很大。
弱一致性:系统写入数据成功,不承诺了课返回写入的数据,不承诺多久能达到一致状态,但是尽可能保证在某个时间界别内达到一致。
会话一致性:同一个客户端的会话内可以读到一致性的值,其他会话不能保证。
用户一致性:同一个用户可以读到一致性的值,其他用户不能保证。
最终一致性:是弱一致性的特例。保证在一定时间内可以达到数据一致性。
可用性:系统处于可用状态。关键点:有限时间内&返回结果
分区容错性:分布式系统遇到网络分区故障,仍能对外提供可用性、一致性的服务。
可用性与一致性冲突解释
如果保证一致性:
Client1将节点1的值修改成v1,接下来要将节点1的值v0加上读写所才能保证数据安全,将v1值同步到节点2。但是在这同步期间,节点1的值v1不可用,节点v1可能还没同步完成v1,也不可用。这就不能保证分布式系统中节点1中的v1值的可用性。
如果保证可用性:
client1将节点1的值更新成v1,不能锁定节点1,但是造成了节点1,节点2数据的不一致。
CAP应用
分布式系统中各服务分配到不同节点,必然会出现子网络,因此分布式系统要保证分区容错性,主要是权衡可用性与一致性问题。
- 可用性&一致性。放弃了系统扩展性。如果想避免出现网络分区带来的影响,将相关数据放在同一节点,数据集中式。
- 可用性&分区容错性。指的是放弃强一致性,保留最终一致性,需要考虑时间窗口即数据多长时间可以达到一致性。
- 一致性&分区容错性。系统在每个节点之间保持强一致性,一致性会带来节点暂时不可用。