ZooKeeper与CAP是什么关系？适用于哪些场景？
从今天，我们正式开始大数据常用组件的讨论。要想在大数据这条路坚持走下去，并用好大数据，有几点建议：
1、系统的了解大数据生态中的技术框架（可通过以下文章了解）。
典型大数据架构有哪些？我该怎么选择？
2、要有亲自动手的意识，并积极主动接触和学习新技术。
PS：最好能有一个自己的测试环境（有大量朋友因为环境而止步！）
3、学到的知识，多在合适的业务场景进行试用和验证。
4、一开始，不要面面俱到(不然容易受打击)，针对典型的场景涉及的技术点不断深入研究。
另外，传统大数据生态涉及的技术点主要有：
1、操作系统方面：Linux常用命令、Shell编程（会ansible等类似技术更佳）。
PS：绝大部分朋友，平时工作环境应该以windows操作为主，为方便大家熟悉linux的环境，以及顺利部署和使用各个组件，后面我会专门补充一篇linux常用操作的文章。敬请期待。
2、编程语言方面：以Java/Python/Scala为主。
3、常用（或者叫 必须知道的）的组件有：
zookeeper
Flume
kafka
Elasticsearch
spark
HDFS
Hive
其他 
ZooKeeper在大数据生态圈，常常被称为动物园管理员。原因是和ZooKeeper在生态中的功能定位有关。
| 一个开源的针对大型分布式系统的可靠协调系统。 设计目标是：将复杂且容易出错的分布式式一致性服务封装起来，构成一个高效可靠的原语集，并以简单易用的接口提供给用户使用。是大数据生态下多种组件的协调者。 大数据生态下多种组件的LOGO以动物为主（见上面图中所示），而ZooKeeper作为协调者，大家就称之为动物园管理员了。 |
1、ZooKeeper是为大型分布式系统服务，先了解一下分布式系统的特点：
《分布式系统概念与设计》一书中给分布式系统的定义：一个硬件或软件组件分布在不同的网络计算机上，彼此之间通过消息传递进行通信和协调的系统
| 分布式系统的特点 | 分布性 对等性 并发性 缺乏全局时钟 故障总是会发生（害怕不 ... ... |
| 分布式系统常见问题 | 节点故障 通信异常 网络分区（俗称“脑裂” ） 服务的三态（成功、失败、超时） ... ... |
分布式系统存在一个比较有名的概念：CAP定理
CAP理论是分布式系统开发的基础。CAP三个字母分别代表了分布式系统中三个相互矛盾的属性:
| Consistency 一致性 |
分布式系统各节点上在同一时间点看到的数据完全相同的（数据强一 致性）。 |
| Availability 可用性 |
每个请求无论成功还是失败，都会保证收到响应。 |
| Partition Tolerance 分区容忍性 |
系统部分功能失效 或 系统间部分数据 丢失，不影响整个分布式系统的操作（高容错性）。 |
CAP理论是指，无法设计一种分布式协议，使得同时完全具备CAP三个属性。
即：目前还不存在数据始终是强一致性；系统的服务始终是可用的；可容忍任何网络分区异常，具备高容错性的完美分布式系统，分布式系统均是在CAP三者中进行折中处理（示例如下：）。
说明：两个节点，主节点负责更新，备节点从主节点同步更新。
客户端通过应用A写入主节点，主节点发送同步消息到备节点，完成备节点数据更新。
客户端从备节点读取到最新数据。
假设主节点到备节点消息发送失败
(1)如果想让系统具备故障容忍能力，整个系统必须运行，只是备节点上数据是旧的，这样数据无法一致性。
(2)如果要保证数据一致性，则主节点到备节点的消息为原子事务，这样主节点发送同步消息后等待备节点确认，备节点响应的时间是不确定的，从而使整个系统在这段时间不可用。
| 不同场景下，取舍的选取是不一样的： 1、分布式系统中，分区容忍性肯定是要满足，不然体现不出分布式的强项。所以必须在可用性和强一致性做出权衡。 2、对于大多数WEB应用，其实不需要强一致性。目前多数分布式应用通过牺牲强一致性来换取应用高可用性。
|
Zookeeper保证的是CP,即一致性(Consistency)和分区容错性(Partition-Tolerance)，牺牲了部分可用性(Available)。
在强一致性的条件下,必须先暂停服务,达成一致性再提供服务,这个同步过程中,请求得不到回应,降低了可用性（Zookeeper中明显不可用的时段只有Leader选举阶段,此时无法写入）。
Zookeeper的其他特性还包括：
| 顺序性 | 从同一个客户端发起的事务请求，最终会严格地按照其发送顺序被应用到Zookeeper中。 |
| 可靠性 | 一旦服务器成功的应用一个事务，并完成了客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下去。 |
| 实时性 | Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 |
| 原子性 | 一次数据更新要么成功，要么失败。 |
| 单一视图 | 无论客户端连接到哪个服务器，看到的数据模型都是一致的。 |
2、ZooKeeper典型的应用场景
ZooKeeper作为一个开源的针对大型分布式系统的可靠协调系统，他的设计目标是将复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以简单易用的接口提供给用户使用。
ZooKeeper典型的应用场景包括：统一命名服务、配置管理、集群管理、分布式锁、发布/订阅，分布式协调/通知等。
| 统一命名服务 | 1、分布式环境下按照层次结构组织服务/应用名称，便于识别不同的服务 2、全局唯一I |
| 配置管理 | 分布式环境下配置文件管理和同步是一个常见问题， 配置信息写入Zookeeper的一个Znode上；各个节点监听这个Znode，配置修改及时通知各节。 该特性，也可应用于发布/订阅、分布式协调/通知等场景。 |
| 集群管理 | 分布式系统中实时掌握各节点的状态是有必要的，方便根据节点状态做出一些调整。 将节点信息写入到一个Znode上，监听这个Znode可获取它的实时状态变化（上下线、Master选举等） |
| 分布式锁 | Zookeeper是强一致和独占的：多个客户端同时在Zookeeper上创建相同znode，只有一个创建成功。其他的等待。创建临时znode（类型为CreateMode.EPHEMERAL_SEQUENTIAL），该znode可掌握全局访问时序 |
| 分布式队列 | 先进先出队列 和 同步队列 1、分布式锁实现先入先出队列 2、同步队列：多个节点到位才进行 为聚合计算创建一个znode，各节点在该znode下创建临时节点，上层znode可知道可节点是否聚齐 |
为了能把各个组件介绍清楚，每个组件估计要用 2-3篇来介绍，内容安排如下：
-
第1篇：先介绍组件相关理论和组件特点，以及适用场景。
-
第2篇：介绍组件体系架构
-
第3篇：介绍安装部署和典型场景实战。
下一篇，介绍ZooKeeper的体系架构
如果觉得这篇文章对您有帮助，欢迎关注公众号 “学点儿编程”，公众号不断推送干货文章！
