zk基础—2.架构原理和使用场景一
大纲
1.zk的使用场景
2.zk主要会被用于那些系统
3.为什么在分布式系统架构中需要使用zk集群
4.zk分布式系统具有哪些特点
5.zk集群机器的三种角色
6.客户端与zk之间的长连接和会话
7.zk的数据模型znode和节点类型
8.zk最核心的Watcher监听回调机制
9.ZAB协议的主从同步机制和崩溃恢复机制
10.ZAB协议流程之集群启动-数据同步-崩溃恢复
11.采用2PC两阶段提交思想的ZAB消息广播流程
12.zk到底是强一致性还是最终一致性
13.ZAB协议下两种可能存在的数据不一致问题
14.崩溃恢复时新Leader和Follower的数据同步
15.ZAB协议会如何处理需要丢弃的消息的
16.zk的Observer节点的作用
17.zk适合小集群部署 + 读多写少场景的原因
18.zk特性的总结
1.zk的使用场景
(1)分布式锁
(2)集群元数据管理
(3)分布式协调(HA)
(4)zk使用场景总结
Kafka里使用zk进行元数据管理、Master选举、分布式协调，Canal也一样使用zk进行元数据管理、Master选举(HA主备切换)，HDFS的HA也是基于zk来做的。
(1)分布式锁
在分布式架构中的分布式锁，就有：Redis分布式锁和zk分布式锁。
(2)集群元数据管理
Kafka和Canal是在分布式集群中运行的分布式架构，都需要一个地方集中式地存储和管理分布式集群的核心元数据，所以它们都选择把分布式集群的核心元数据放在zk中。
(3)分布式协调(HA)
如果有客户端对zk中的数据做了变更，然后zk会通知其他监听这个数据的客户端数据发生变更了。
非常经典的几个分布式协调的场景：
一.Kafka
Kafka有多个Broker，多个Broker会竞争成为一个Controller的角色。如果作为Controller的Broker挂了，那么它在zk里注册的一个节点就会删除。然后其他Broker紧接着会被zk反向通知，继续竞争成为新的Controller。
二.HDFS
HDFS中NameNode的HA架构就部署主备两个NameNode，只有一个NameNode通过zk选举成为Master，另一个NameNode作为备份。
三.Canal
Canal的HA架构也是通过zk，确保一个节点挂掉后，可以通知其他备用节点进行切换，来保证HA。
(4)zk使用场景总结
zk封装了分布式架构中很多核心和主流的需求功能，比如很多分布式系统都需要分布式锁、集中式存储分布式集群的元数据、Master选举、分布式协调，这些功能需求都可以使用zk来实现。
2.zk主要会被用于那些系统
(1)分布式Java业务系统
(2)开源的分布式系统
(3)自研的分布式系统
(1)分布式Java业务系统
比如分布式电商平台、Java开发的互联网平台、或者是传统架构系统，都属于分布式Java业务系统。
这些系统大部分依赖Dubbo、Spring Cloud来对系统进行拆分，拆分成很多服务或子系统后，再相互协调工作来完成最终的功能。
但zk在这类Java业务系统中用得是比较少的，zk在这类Java业务系统中用得比较多的功能也只是分布式锁，即便是分布式锁的功能很多时候也会选择使用Redis分布式锁。
(2)开源的分布式系统
比如Dubbo、HBase、HDFS、Kafka、Canal、Storm、Solr，主要使用zk进行：集中式存储分布式集群的元数据、Master选举实现HA架构、分布式协调和通知。
Dubbo：使用zk作为注册中心 + 集中式存储分布式集群的元数据；
HBase：使用zk进行集中式存储分布式集群的元数据；
HDFS：使用zk进行Master选举实现HA架构；
Kafka：使用zk进行集中式存储分布式集群的元数据，分布式协调和通知；
Canal：使用zk进行集中式存储分布式集群的元数据，Master选举实现HA；Canal、Kafka、HDFS等这些技术都用了zk进行元数据管理和Master选举。
(3)自研的分布式系统
在很多自研类似的一些分布式系统，都可能会考虑：是否需要一个地方集中式存储分布式集群的元数据？是否需要一个组件辅助进行Master选举来实现HA架构？是否需要进行分布式协调和通知？
如果在自研分布式系统时，有类似这样的需求，那么就可以考虑引入zk来满足该需求。
3.为什么在分布式系统架构中需要使用zk集群
(1)自研一个类似zk的系统
(2)使用zk集群
当需要对分布式集群进行：集中式存储元数据、Master选举实现HA、分布式协调和通知时，可以自研一个类似zk的系统，也可以使用zk集群。
(1)自研一个类似zk的系统
如果是单机版本，只部署在一台机器上，里面提供了一些功能。虽然已实现存储一些元数据、支持Master选举、支持分布式协调和通知。但是对于单机版本的系统，万一挂掉了怎么办？
所以需要集群部署，通过多台机器保证高可用，即便挂掉一台机器，都可以继续运行下去。
假设现在有3台机器，要进行元数据的存储。已经向机器1写了一条数据，那么机器1应该怎么把数据同步给其他的机器？所以自研一个类似的zk系统一旦集群部署后，数据一致性应该怎么保证？
(2)使用zk集群
久经考验的zk，bug很少且功能全面，已用在很多工业级的分布式系统中，所以直接使用zk集群即可。
4.zk分布式系统具有哪些特点
(1)集群化部署
(2)树形结构的数据模型
(3)顺序写
(4)数据一致性
(5)高性能
(6)高可用
(7)高并发
(1)集群化部署
3~5台机器组成一个集群，每台机器都在内存保存zk的全部数据。机器间互相通信同步数据，客户端可连接任何一台机器。
(2)树形结构的数据模型
znode的数据结构跟文件系统类似，是有层级关系的树形数据结构。znode的数据结构是树形结构，纯内存保存，znode可以认为是一个节点而已。
create /usr/local/uid
create /usr/local/test_file
uid：可以写入一些数据的值，比如hello world
test_file：也可以写入一些数据的值(3)顺序写
集群中只有一台机器可以写，所有机器都可以读。所有写请求都会分配一个zk集群全局的唯一递增编号ZXID，ZXID的作用就是用来保证客户端发起的写请求都是有顺序的。
(4)数据一致性
任何一台zk机器收到了写请求后都会同步给其他机器，保证数据一致。客户端连接到任何一台zk机器看到的数据都是一致的。
(5)高性能
每台zk机器都在内存维护数据，所以zk集群绝对是高并发高性能的。如果让zk部署在高配置机器上，3台机器的zk集群能抗下每秒几万请求。
(6)高可用
哪怕集群中挂掉不超过一半的机器，都能保证集群可用，数据不会丢失。3台机器可以挂1台，5台机器可以挂2台。
(7)高并发
高并发是由高性能决定的，只要基于纯内存数据结构来处理，那么并发能力是很高的。使用高配置的物理机器进行写，比如1台16核32G可以支持几万QPS，3台16核32G可以支持十几万QPS。
5.zk集群机器的三种角色
通常来说zk集群里有三种角色的机器，分别是Leader、Follower、Observer。集群启动后会自动选举一个Leader出来，只有Leader可以写，Follower只能同步数据和提供数据的读取。如果Leader挂了，那么Follower会继续选举出新的Leader。Observer只能读，而且Observer不参与选举。
6.客户端与zk之间的长连接和会话
zk集群启动后，集群中的各个节点会自己分配好角色。之后客户端跟zk集群建立的连接，是TCP长连接。也就建立了一个会话Session，会通过心跳来感知会话是否存在。
7.zk的数据模型znode和节点类型
zk的核心数据模型就是znode树，往zk写数据就是创建树形结构的znode，里面可以写入值，存放在zk的内存中。
有两种节点：持久节点和临时节点。持久节点，就是哪怕客户端断开连接，也一直存在。临时节点，就是只要客户端断开连接，节点就没了。
顺序节点，就是创建节点时自增加全局递增的编号。
Curator中关于zk分布式锁的实现就是基于zk的临时顺序节点来实现的，加锁时会创建一个临时顺序节点。zk会自动给临时节点加上一个后缀，也就是全局递增的一个编号。如果客户端断开连接，就自动销毁这个客户端加的锁，此时其他客户端就会感知到而尝试去加锁。
如果进行元数据存储，则需要使用持久节点。如果进行分布式协调和通知，则通常使用临时节点。如果实现分布式锁，则通常使用临时顺序节点。
每个znode还有一个Stat用来存放数据版本：
一.version(znode的版本)
二.cversion(znode子节点的版本)
三.aversion(znode的ACL权限控制版本)8.zk最核心的Watcher监听回调机制
zk最核心的机制是：一个客户端可以对znode进行Watcher监听，当znode发生改变时zk会回调该客户端进行通知。
这是非常有用的一个功能，在分布式系统的协调中是非常有必要的。如果zk只支持写和读，那只能实现元数据存储、Master选举和部分功能，对于分布式系统的协调需求就没办法实现了。如系统A监听一个数据的变化，如果系统B更新了该数据，zk需要能通知系统A该数据的变化。
通过对zk内存数据模型(不同节点类型)进行这两种操作：写数据和读数据、监听数据变化(更新数据时反向通知数据变化)，就可以实现：存储集群元数据、分布式锁、Master选举、分布式协调监听等功能；
9.ZAB协议的主从同步机制和崩溃恢复机制
ZAB协议使用的是主从架构，需要划分集群角色，有Leader和Follower两种角色。其中Leader和Follower都可以处理读请求，但只有Leader可以处理写请求。
Leader收到事务请求后，会往本地磁盘日志文件写数据，然后转换为Proposal提议并同步给所有的Follower。Follower收到Leader的Proposal提议后，也会往本地磁盘日志文件写数据。
当Leader发现超过半数Follower都收到Proposal提议时，Leader会给所有Follower发送Commit消息提交事务写数据到内存。
如果Leader崩溃了，Follower会重新选举新的Leader保证服务运行。
所以ZAB协议涉及：角色划分、2PC(两阶段)、过半写机制。
10.ZAB协议流程之集群启动-数据同步-崩溃恢复
(1)zk集群启动时会进入数据恢复模式
(2)zk启动完后会进入消息广播模式
(3)Leader宕机时会进入数据恢复模式
(1)zk集群启动时会进入数据恢复模式
集群启动时会选举一个Leader。只要有过半机器认可某台机器是Leader，那么该机器就可以被选举为Leader。
Leader选举出来后，Leader会等待集群中过半Follower与它进行数据同步。只要过半Follower完成数据同步，集群就会退出恢复模式，就可以对外提供服务。当然还没完成数据同步的Follower会继续与Leader进行数据同步。
(2)zk启动完后会进入消息广播模式
客户端既可以连接Leader，也可以连接Follower，但要注意只有Leader可以处理写请求。
如果客户端发送了一个写请求给Follower，那么Follower会把写请求转发给Leader。Leader收到写请求后，会把写请求以Proposal提议的形式同步给所有Follower。过半Follower都收到Proposal后，Leader再发送Commit消息让Follower提交写请求。
(3)Leader宕机时会进入数据恢复模式
当Leader宕机时，Follower会重新选举一个Leader。只要过半Follower都承认一个Follower成为Leader，那么就可以完成选举。
所以在zk集群中，只要宕机的机器数小于一半，那么集群就还可以正常工作。因为还有过半机器存活下来进行重新选举，此时还可以重新选举出新的Leader。新的Leader选举出来后再重新等待过半Follower跟它进行数据同步，过半Follower完成数据同步后集群就会重新进入消息广播模式。
(4)总结
一.集群启动时的数据恢复模式
Leader选举(过半机器选举机制) + (剩余机器)进行数据同步。
二.消息写入时的消息广播模式
Leader采用2PC模式的过半写机制，来给Follower进行同步。
三.Leader宕机时的数据恢复模式
Leader宕机时，只要剩余存活机器超过一半，那么就还可以选举出新的Leader。选举出新的Leader后，Follower会重新进行数据同步。
11.采用2PC两阶段提交思想的ZAB消息广播流程
(1)Leader发起一个事务Proposal之前
(2)每个Follower收到一个事务Proposal后
(3)Leader自己也会进行Commit操作
对每一条消息进行广播时，都是通过2PC实现的。首先Leader广播Proposal提议，然后各个Follower返回ACK响应，Leader收到过半Follower的ACK响应后再广播Commit消息让Follower进行提交。
(1)Leader发起一个事务Proposal之前
Leader会分配一个全局唯一递增的ZXID来严格保证事务处理的顺序，而且Leader会为每个Follower创建一个FIFO队列。队列里会顺序放入发送给Follower的Proposal，从而保证事务处理的顺序。
(2)每个Follower收到一个事务Proposal后
Follower会立即写入本地磁盘日志，写入成功后就可以保证数据不丢失。然后Follower会返回一个ACK给Leader，当过半Follower都返回ACK时，Leader就会发送Commit消息给全部Follower。
(3)Leader自己也会进行Commit操作
Leader和Follower进行Commit之后，就意味这个数据可以被读取到了。