Zookeeper之CAP理论

CAP理论概述

1.一致性(C：Consistency)

• 数据一致更新，所有数据变动都是同步的

2.可用性(A：Availability)

• 系统具有好的响应性能

3.分区容错性(P：Partition tolerance)

• 一个服务崩溃不影响整体服务可用
• 系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，也就是说无论任何消息丢失，系统都可用

4.总结

• 任何分布式系统只可同时满足两点，无法三者兼顾

一致性分类

1.强一致性

• 任何时刻，任何用户都能读取到最近一次成功更新的数据
• 这会导致分步式系统可用性A下降

2.单调一致性

• 任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值
• 也就是说，可获取的数据顺序必是单调递增的

3.会话一致性

• 任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这个值更旧的值
• 会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障

4.最终一致性

• 用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障

5.弱一致性

• 用户无法在确定时间内读到最新更新的值

ZooKeeper与CAP理论

• ZooKeeper从以下几点保证了数据的一致性

1.顺序一致性

• 任意客户端的更新都会按其发送顺序被提交
• 如果一个客户端将Znode z的值更新为a，在之后的操作中，它又将z的值更新为b，则没有客户端能够在看到z的值是b之后再看到值a（如果没有其他对z的更新）

2.原子性

• 每个更新要么成功，要么失败
• 意味着如果一个更新失败，则不会有客户端会看到这个更新的结果

3.单一系统映像

• 客户端无论连接到哪一台服务器，它看到的都是同样的系统视图
• 如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比在之前服务器上所看到的更老
• 当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该连接请求，除非这些服务器赶上故障服务器

4.持久性

• 更新一旦成功，其结果就会持久存在并且不会被撤销
• 表明更新不会受到服务器故障的影响

ZooKeeper的一致性级别

• 只有写请求时，满足线性一致

zk按写的时间提交到FIFO队列，先提交的写操作一定先发生

• 从读写角度来看，满足顺序一致

每次只能读到最新的数据

• 保证单调一致

每次只能读到最新的数据