zookeeper平滑升级_zookeeper学习

什么是zookeeper

高性能分布式协调服务，主要解决分布式一致性。

适用于读多写少场景，实现了CAP的C和P(即一致性和分区容忍性)，但是需要注意的是，这里是弱一致性。

服务端使用java语言开发，提供JAVA和C的API。

弱一致性解读

zk机器需要有n+1台机器，最大允许n台机器同时失效，当发起写入请求时，当有n+1台机器返回成功，即为成功；

如果此时另外n台失效节点无法连通，则这些节点的客户端读取到的数据并非最新数据，只有当这些节点加入集群后，会从leader同步最新数据，此时整个cluster才能提供统一的逻辑视图。

zookeeper特点

顺序一致性：按照客户端请求分配ZXID(全局唯一事务ID)，并顺序更新数据。

原子性：要么成功要么失败，不存在中间状态。

可靠性：数据更新成功将一直保持

及时性：客户端会在一个确定的时间内得到更新数据

zookeeper集群

集群要求：2n+1台服务，最大允许n个服务失效(为啥？查看下面脑裂部分)。

zookeeper集群只能有一个leader，负责写数据，剩下的都是follower。

follower负责提供读请求，客户端无论连接哪一台，发送写请求后都会传递给leader，然后由leader更新数据并同步至follower。

当一台节点连接到集群(集群状态变更)，或者leader接收到写请求，都会产生全局唯一事务ID:ZXID.

客户端可以设置多个zookeeper地址，当发送请求到zookeeper上后得到确认会返回消息，此时会维护一个connection(TCP长连接)。

客户端通过TCP长连可以向服务端发送心跳，也由此接收服务端watcher通知。

zookeeper节点状态

zk节点存在以下状态：

LEADING，领导者状态。

LOOKING，竞选状态。

FOLLOWING，随从状态，同步leader状态，参与投票。

OBSERVING，观察状态,同步leader状态，不参与投票。

集群leader选举

什么时候发生选举：

客户端启动(初始化)

follower无法和leader保持通讯(leader挂了、或网络导致的假死)

选举影响：集群选举的过程中将会暂停对外服务。

选举过程

每个服务端，发送本机myid和zxid给集群所有机器(包括自己)进行投票，表示方式：(myid，zxid)。

每个服务端，接收到请求

判断是否looking状态、epoch参数(详看脑裂部分)。

判断zxid是否小于自己记录的zxid，小则丢弃，大则替换，等同则比较myid，并求出最大。

广播投票结果，接受被广播发送的ACK

判断ACK数量是否超过过半服务器

确认Leader，变更服务器状态

zookeeper  API

connect - 连接到ZooKeeper集群

create- 创建znode

exists- 检查znode是否存在及其信息

getData - 从特定的znode获取数据

setData - 在特定的znode中设置数据

getChildren - 获取特定znode中的所有子节点

delete - 删除特定的znode及其所有子项

close - 关闭连接

zookeeper 节点类型

client可以通过api创建节点，创建的节点有如下类型：

持久节点：节点创建后，就一直存在

持久顺序节点：基于持久节点，会分配顺序数字，例如创建节点test，则zk会自动给test_后面补充数字

临时节点：临时节点的生命周期和客户端会话绑定，客户端关闭/丢失连接，节点删除

临时顺序节点： 同上

zookeeper 脑裂

什么是脑裂：一个cluster产生两个leader。

产生原因：假设两台zk服务器相互通信ok，则会选举一个leader；如果通信不ok，则cluster会出现两个leader(自我选举)。

zk解决方式：设置法定人数：Quorums，3节点Quorums是2，也就是上面说的2n+1个节点最多容忍N个节点失效；每次选举必须达到法定人数才可以。

假设旧leader假死，其他节点选举新leader，则旧leader发起写入数据操作会被拒绝；

如何会拒绝？集群选举leader后会产生递增的epoch，可理解为leader的编号；写入数据时会对这个参数进行判断。

观察者Observer

根据上面zk状态发现，有一个OBSERVING状态存在，拥有这个状态的即是观察者。

功能：不参与投票从而提高性能；因为投票会进行多轮对比，所以当观察者上、下线后，不会让集群产生投票动作。

场景：多数据中心、网络不稳定的情况下，观察者上下线不会影响集群。

zookeeper 缺点

选举过程服务不可用。

当集群存活node少于选举leader的法定人数Quorums时整个集群不可用。(降级方案：客户端加点缓存，但是会破坏CP。

大规模服务发现、大规模健康监测等方面有天然的短板(网络闪断、tcp心跳不能反馈更多信息)。

容量不可以横向扩展(Znode的大小限制为1M)。

zookeeper 优点

分布式锁(db、redis可替代)。

分布式选主。

分布式一致性。

选型场景

大数据场景适用(mapreduce、spard等分布式一致性，分布式协调)。

交易场景不可用(不能保证可用性，服务发现场景有缺陷)。

相关资料