Zookeeper学习笔记

Zookeeper概念_集中式到分布式

注意：

集群：多个人在一起做同样的事

分布式：多个人在一起做不同的事

单机架构

一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上，整个项目所有的服务都由这台服务器提供。

 

缺点：

●服务性能存在瓶颈

●不可伸缩性

●代码量庞大，系统臃肿，牵一发动全身

●单点故障问题

集群架构

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一 个集群。

集群存在的问题:

当你的业务发展到一定程度的时候，你会发现一个问题无论怎 么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用分布式架构了。

 什么是分布式

分布式架构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

分布式的优势:

●系统之间的耦合度大大降低，可以独立开发、 独立部署 、 独立测试 ， 系统与系统之间的边界

非常明确 ， 排错也变得相当容易，开发效率大大提升。

●系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。

●服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以

使用该系统作为用户系统，无需重复开发。

Zookeeper概念_CAP定理

分布式系统正变得越来越重要，大型网站几乎都是分布式的。分布 式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点

分布式系统的三个指标

●Consistency（一致性）

●Availability （可用性）

●Partition tolerance （分区容错性）

它们的第一个字母分别是 C 、 A 、 P 。

这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

分区容错性

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个 区。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

结论

分区容错无法避免，因此可以认为 CAP 的 P 总是成立。 CAP 定理告诉我们，剩下的 C 和 A 无法同时做到

一致性

写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0 ， 用户向 G1 发起一个写操作，将其改为 v1 。

 

接下来，用户的读操作就会得到 v1 。这就叫一致性。

问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0 。 G1 和 G2 读操作的结果不一致，这就不满足一致性了

 

 

为了让 G2 也能变为 v1， 就要在 G1 写操作的时候，让 G1 向 G2 发 送一条消息，要求G2 也改成 v1 。

可用性

只要收到用户的请求，服务器就必须给出回应。

解释：

用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是v0 还是 v1 ，否则就不满足可用性。

 一致性和可用性的矛盾

 

解释：

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的 读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性。

一致性和可用性如何选择

一致性

特别是涉及到重要的数据，就比如钱，商品数量，商品价格。

可用性

网页的更新不是特别强调一致性，短时期内，一些用户拿到老版本，另一些用户拿到新版本，问题不会特别大。

Zookeeper概念_什么是Zookeeper

分布式架构

 

多个节点协同问题：

●每天的定时任务由谁哪个节点来执行？

●RPC调用时的服务发现 ?

●如何保证并发请求的幂等

这些问题可以统一归纳为多节点协调问题，如果靠节点自身进行协调这是非常不可靠的，性能上也不可取。必须由一个独立的服务做协调工作，它必须可靠，而且保证性能。

一个应用程序，涉及多个进程协作时， 业务逻辑代码中混杂有大量复杂的进程协作逻辑

上述多进程协作逻辑，有 2 个特点：

●处理复杂

●处理逻辑可重用

 因此，考虑将多进程协作的共性问题拎出，作为基础设施，让 RD更加专注业务逻辑开发，即：

Zookeeper从何而来

ZooKeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。

解决：

雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。

Zookeeper