zookeeper(二) 应用概述

基本概念

ZAB协议

客户端脚本

javaAPI

ZKClient & Curator

应用场景

        数据发布订阅

        负载均衡

        命名服务

        分布式协调/通知

        集群管理

     Master选举

        分布式锁

        分布式队列

        使用优化

(一)分布式基础知识

分布式的特点：分布性、对等性、并发性、缺乏全局时钟、故障总会发生

分布式环境下的各种问题：通讯异常、网络分区、成功失败超时三态、节点故障

从ACID到BASE的变化

一致性协议：

• 2pc（请求处理-->提交确认）与3pc（事务处理能力询问-->处理后待提交-->提交确认）的特点及优缺点比较】
• Paxos协议的原理及在Chubby、Hypertable上的实践。

(二)Zookeeper可以保证的分布式一致性特性：

顺序一致性：同一个客户端发起的事务请求，严格按其顺序处理

原子性：事务请求处理的原子性

单一视图：无论客户端连接到哪个服务器，看到的数据模型是一致的

可靠性：对事务的处理完成并反馈后，状态会一致保留直到被其他事务改变

实时性：一定时间段内，客户端最终一定能从服务器上读取到最新的数据状态

(三)Zookeeper中的核心概念/特性：

        全部存储在内存中的树形数据节点ZNode，分为持久（顺序）型与临时（顺序）节点（生命周期与客户端会话绑定），每个ZNode只能由一台服务器创建，且节点的sequential自增数字保障兄弟节点按顺序无重复

三种集群角色

1. Leader：

        处理事务请求并保证事务请求的顺序性（事务指能够改变Zookeeper服务状态的操作，一般包括数据节点的创建删除与内容更新、客户端会话创建与失效。每一个事务有全局唯一的ZXID）；集群内部各服务器的调度

2. Follower:

        处理客户端非事务请求、转发事务请求给Leader、参与事务请求Proposal投票、参与Leader选举投票

3. Observer：

        只处理非事务服务，不参与任何形式的投票

说明：ZXID是一个64位的数字，其中低32位针对客户端每一个事务请求，Leader服务器在产生一个新的事务proposal时进行+1，高32位代表本轮Leader周期的epoch标号，当新选举一个Leader后会对此epoch+1以区分出Leader周期的变化。集群中拥有XZID最大的proposal的机器会成为Leader，因为它一定具有所有已经提交的提案。