Merge pull request 0voice#7 from pyinx/master

完善部分zookeeper的内容
Awesome-Interview · Jul 17, 2019 · 191f7ed · 191f7ed
2 parents 38fb623 + 70d991d
commit 191f7ed
Show file tree

Hide file tree

Showing 9 changed files with 93 additions and 12 deletions.
diff --git a/12.1.0 zookeeper是什么？.md b/12.1.0 zookeeper是什么？.md
@@ -0,0 +1,6 @@
+#### **参考答案**：
+
+> A high-performance coordination service for distributed applications
+
+Zookeeper是基于Google Chubby论文的开源实现，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、配置管理 等等。
+由于Hadoop生态系统中很多项目都依赖于zookeeper，如Pig，Hive等， 似乎很像一个动物园管理员，于是取名为Zookeeper。
diff --git a/12.1.4 zookeeper通知机制.md b/12.1.4 zookeeper通知机制.md
@@ -2,4 +2,17 @@
 
 #### **参考答案**：
 
-client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。
+client端会对某个znode建立一个watcher事件，当该znode发生变化时，zk会主动通知watch这个znode的client，然后client根据znode的变化来做出业务上的改变等。
+
+#### watcher的特点：
+- 轻量级：一个callback函数。
+- 异步性：不会block正常的读写请求。
+- 主动推送：Watch被触发时，由Zookeeper服务端主动将更新推送给客户端。
+- 一次性：数据变化时，Watch只会被触发一次。如果客户端想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch。
+- 仅通知：仅通知变更类型，不附带变更后的结果。
+- 顺序性：如果多个更新触发了多个Watch，那 Watch 被触发的顺序与更新顺序一致。
+
+#### 使用watch的注意事项：
+- 由于watcher是一次性的，所以需要自己去实现永久watch
+- 如果被watch的节点频繁更新，会出现“丢数据”的情况
+- watcher数量过多会导致性能下降
diff --git a/12.1.5 zookeeper有哪些应用场景？.md b/12.1.5 zookeeper有哪些应用场景？.md
@@ -2,12 +2,14 @@
 
 #### **参考答案**：
 
-1、命名服务
+1、名字服务
 
 2、配置管理
 
 3、集群管理
 
 4、分布式锁
 
-5、队列管理
+5、队列管理
+
+6、消息订阅
diff --git a/12.2.2 zk中zab的工作原理.md b/12.2.2 zk中zab的工作原理.md
@@ -0,0 +1,7 @@
+#### **题目**：zk中zab的工作原理
+
+#### **参考答案**：
+
+ZAB 是 ZooKeeper Atomic Broadcast （ZooKeeper 原子广播协议）的缩写，它是特别为 ZooKeeper 设计的崩溃可恢复的原子消息广播算法。ZooKeeper 使用 Leader来接收并处理所有事务请求，并采用 ZAB 协议，将服务器数据的状态变更以事务 Proposal 的形式广播到所有的 Follower 服务器上去。这种主备模型架构保证了同一时刻集群中只有一个服务器广播服务器的状态变更，因此能够很好的保证事物的完整性和顺序性。
+
+Zab协议有两种模式，它们分别是恢复模式(recovery)和广播模式(broadcast)。当服务启动或者在leader崩溃后，Zab就进入了恢复模式，当leader被选举出来，且大多数follower完成了和leader的状态同步以后， 恢复模式就结束了，ZAB开始进入广播模式。
diff --git a/12.2.2 zk的工作原理.md b/12.2.2 zk的工作原理.md
diff --git a/12.2.4 zk集群下server工作状态.md b/12.2.4 zk集群下server工作状态.md
@@ -2,10 +2,12 @@
 
 #### **参考答案**：
 
-每个Server在工作过程中有三种状态： 
+每个Server在工作过程中有四种状态： 
 
 LOOKING：当前Server不知道leader是谁，正在搜寻
 
-LEADING：当前Server即为选举出来的leader
+LEADING：当前server角色为leader
 
-FOLLOWING：leader已经选举出来，当前Server与之同步
+FOLLOWING：当前server角色为follower
+
+OBSERVING：当前server角色为observer
diff --git a/12.2.6 zk同步流程.md b/12.2.6 zk同步流程.md
@@ -14,4 +14,23 @@
 
 5. Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。
 
-<img src="zk_sync.png" />
+<img src="zk_sync.png" />
+
+
+数据同步的4种方式：
+
+1、SNAP-全量同步
+  - 条件：peerLastZxid<minCommittedLog
+  - 说明：证明二者数据差异太大，follower数据过于陈旧，leader发送快照SNAP指令给follower全量同步数据，即leader将所有数据全量同步到follower
+
+2、DIFF-增量同步
+  - 条件：minCommittedLog<=peerLastZxid<=maxCommittedLog
+  - 说明：证明二者数据差异不大，follower上有一些leader上已经提交的提议proposal未同步，此时需要增量提交这些提议即可
+
+3、TRUNC-仅回滚同步
+  - 条件：peerLastZxid>minCommittedLog
+  - 说明：证明follower上有些提议proposal并未在leader上提交，follower需要回滚到zxid为minCommittedLog对应的事务操作
+
+4、TRUNC+DIFF-回滚+增量同步
+  - 条件：minCommittedLog<=peerLastZxid<=maxCommittedLog
+  - 说明：leader a已经将事务truncA提交到本地事务日志中，但没有成功发起proposal协议进行投票就宕机了；然后集群中剔除原leader a重新选举出新leader b，又提交了若干新的提议proposal，然后原leader a重新服务又加入到集群中说明：此时a,b都有一些对方未提交的事务，若b是leader, a需要先回滚truncA然后增量同步新leader b上的数据。
diff --git a/12.2.8 zk的session机制.md b/12.2.8 zk的session机制.md
@@ -0,0 +1,35 @@
+#### **题目**：zk的session机制
+
+#### **参考答案**：
+
+zookeeper会为每个客户端分配一个session，类似于web服务器一样，用来标识客户端的身份。
+
+session的作用：
+
+
+- 客户端标识
+- 超时检查
+- 请求的顺序执行
+- 维护临时节点的生命周期
+- watcher通知
+
+session的状态：
+
+- CONNECTING
+- CONNECTED
+- RECONNECTING
+- RECONNECTED
+- CLOSED
+
+session的属性：
+
+- SessionID：会话ID，全局唯一
+- TimeOut：会话超时时间
+- TickTime：下次会话超时时间点
+- isClosing：会话是否已经被关闭
+
+sessionID的构成：
+
+- 高8位代表创建Session时所在的zk节点的id
+- 中间40位代表zk节点当前角色在创建的时候的时间戳
+- 低16位是一个计数器，初始值为0
diff --git a/README.md b/README.md
@@ -864,6 +864,8 @@
 
 ##### [12.2.7 分布式通知和协调](12.2.7%20%E5%88%86%E5%B8%83%E5%BC%8F%E9%80%9A%E7%9F%A5%E5%92%8C%E5%8D%8F%E8%B0%83.md)
 
+##### 12.2.8 zk的session机制
+
 
 <br>