java zookeeper分布式原子操作_使用Zookeeper实现分布式锁(一)--Zookeeper介绍

什么是分布式系统?

与分布式系统相对应的就是集中式系统,什么是集中式系统呢?将一个软件安装部署到一台计算机上对外提供服务,这台计算机响应所有客户端的请求,就是一个集中式系统.

而很多台计算机组成了一个整体,一个整体一致对外处理同一个请求就是分布式系统.

分布式系统内部的每一个台计算机可以相互通信(RPC/REST/WebService/消息队列)

分布式系统的典型应用就是客户端到服务端的一次请求到响应结束会历经多个计算机.

图例一: 分布式文件系统

1.jpg

图例二: 购物流程:

2.png

为什么要使用分布式系统?

更好的服务用户:

当用户量增加的时候,用户请求会分流,整体的负载和性能会有一个很大的提高

面向服务的架构

将整个系统划分为不同的服务模块,这样降低了耦合性,提高系统功能的扩展性

分布式系统的协调服务Zookeeper

地铁上的人流负载

分布式系统如果操作相同的共享数据,由于存在多个进程进行资源的竞争,所以可能会出现数据的一致性问题,造成数据不安全.

3.jpg

Zookeeper负责分布式系统的协调服务

Zookeeper就像是拥挤的地铁站中的指挥人员,负责协调分布式系统各个服务之前相互协作以及数据的安全共享.

Zookeeper的特性:

一致性,数据的一致性,数据按照顺序分批次入库

原子性:事务要么成功,要么失败,不会局部化

单一视图:客户端连接集群中任意一个zk节点,数据都是一致性的

可靠性,每一次的ZK的操作状态都会保存到服务端

实时性: 客户端可以读取到zk服务端的最新数据

Hadoop生态

Zookeeper作为分布式系统协调服务,在Hadoop生态中扮演重要作用,被称为(Zookeeper)动物管理员.

4.jpg

Zookeeper的数据结构模型和特点

zk的数据结构模型

zknode.png

zk数据结构特点(这些特点后续都会用到):

zk存储数据的结构如上图,是树状结构

每个子目录项如NameService都被称作znode,这个znode是被它所在的路径唯一标识,如Server1这个znode的标识为/NameService/Server1

znode可以有子节点目录,每一个znode必须存储数据

znode是有版本version,也就是一个访问路径可以存储多份不同版本数据

znode可以是临时节点,退出zk客户端与服务端失去联系就删除,也可以是永久节点

znode可以设置权限访问

znode可以被监控,通过设置一个监听事件来判断这个znode的增删改情况

Zookeeper的安装

分为集群模式和单机模式,安装在linux机器上,可以自行百度查询.

Zookeeper的会话原理

客户端与服务端的连接存在一个会话

每一个会话都可以设置一个超时时间

心跳机制原理:zk客户端向服务端的ping包请求

会话过期后:则临时节点znode会被抛弃

心跳结束后:会话过期

Zookeeper常用查询命令

./zKcli.sh 打开zk的命令行客户端

ls 命令和 ls2命令

ls : 查看一个目录下面有哪些内容

ls2 : 查看一个目录下面的内容和内容状态信息

ls2 = ls + stat

get 和 stat 命令

stat : 就是 status

get : 把某个节点所有的数据取出来

stat状态

cZxid : 创建后分配的id

ctime : 创建事件

mZxid : 修改后分配的id

mtime : 修改时间

pZxid : 子节点的id

cversion : 子节点的version

dataVersion : 当前节点数据的版本号

aclVersion : 版本号

dataLength : 数据长度

mChildren : 子节点数量

ephemeralOwner : 如果不是0x0就表示是临时节点


Zookeeper的增删改命令

create 命令 :创建znode节点

create [-s] [-e] path data acl

临时节点 : create -e /lyric/tmp hello

永久节点 : create /lyric lilike

创建顺序节点 : create -s /lyric/sec seq

delete path [version] : 删除znode

delete /lyric 1

set path data [version]

set /lyric like 1

Zookeeper的Watcher机制及其命令

针对每一个节点操作(增删改),都有一个监督者 --- Wather

当监控的某个对象(znode)发生了变化,就会触发wather事件

zk的wather是一次性的,触发后就会立即销毁

针对不同类型的操作,触发的Wather事件也会不同:

创建事件: NodeCreated

修改事件: NodeDataChanged

删除事件: NodeDeleted

监听了某个znode之后无论是父节点,子节点,本znode发生变化,都会监听到

使用步骤:

设置监听事件

进行相应操作触发事件

设置事件:

ls path watch

stat path watch

ls2 path wathch

创建节点触发: NodeCreated

create /big one

ls /big watch

create /big/yun one

修改节点触发: NodeDataChanged

create /big one

get /big watch

set /big two

删除节点触发: NodeDelete

create /big one

ls /big watch

delete /big

7.png

Watch使用场景

分布式系统的统一资源配置

8.png

分布式锁

9.png

ACL(access control lists)权限控制

针对znode节点可以设置读写权限,目的是保障数据的安全性

权限permissions可以指定不同权限范围及角色

getAcl : 获取某一个节点acl权限信息

getAcl path

setAcl : 设置某个节点的acl权限信息

setAcl path acl

addauth: 输入认证授权信息,注册时输入明文密码(登录),但是在zk的系统里面,密码以加密方式存在

zk 的 acl通过 [scheme:id:permissions]来构成权限列表

scheme : 代表采用的某种权限机制

id : 代表允许访问的用户

permissions : 权限组合字符串

world : world 下只有一个id,就是只有一个用户,也就是anyone,组合写法就是world:anyone:[permissions]

auth : 需要认证登录,需要注册用户有权限就可以,形式是auth:user:password:[permissions]

digest:需要对密码进行加密才能访问,组合形式:

digest:username:BASE64(SHA1(password)):[permissions]

简而言之:auth和digest的区别就是前者是明文,后者是密文:

setAcl/path auth:lee:lee:cdrwa

与

setAcl/path digest:lee:BASE64(SHA1(password))cdrwa

是等价的,在通过

addauth digest lee:lee后都能操作指定节点的权限

ip : 当设置为ip指定的ip地址,此时限制ip进行访问

比如 ip:192.168.1.1:[permissions]

super : 代表超级管理员,拥有所有的权限

权限字符串 crdwa:

CREATE : 创建子节点

READ : 获取节点/子节点

WRITE : 设置子节点权限

DELETE : 删除子节点

ADMIN : 设置权限

ACL命令行练习

world: anyone :cdrwa

getAcl /lilike/abc

setAcl /lilike/abc world:anyone:cwrd

auth:user:pwd:cdrwa

digest:user:BASE64(SHA1(pwd)):cdrwa

addauth digest user:pwd

代码:

addauth digest like:like -- 添加用户

setAcl /names/imooc auth:like:like:cdrwa -- 设置权限

使用digest:

退出当前用户 ctrl + c

setAcl /names/test digest:imooc:XwEDaL3J0JQGkRQzM0DpO6zMzZs=:cdra

addauth digest imooc:imooc -- 登录还是要用明文去登录

使用ip:

create /names/ip ip

getAcl /names/ip

setAcl /names/ip ip:192.168.1.1:cwrd

使用supser进行超级用户登陆:

修改zkServer.sh增加super管理员

重启zkServer.sh

进入zkCli.sh 客户端之后,需要登录超级管理员之后才有权限

ACL使用场景

开发和测试环境分离,开发者无权操作测试库的节点,只能看

生产环境上控制指定ip的服务可以访问相关的节点,防止混乱

常用的ZK java客户端

ZK原生API

超时重连,不支持自动,需要手动操作

Watch注册一次之后会失效

不支持递归创建节点

ZKclient:

第三方开源项目

Apache curator

Apache的开源项目

解决了watcher的注册一次就失效

提供了常用的Zookeeper的工具类

编程风格更爽

Apache curator的使用

导入包:

org.apache.curator

curator-framework

4.0.0

org.apache.curator

curator-recipes

4.0.0

具体可参考文档: http://curator.apache.org/getting-started.html

Quick-Start:

RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3) // 重试机制:重试超时和重试次数

CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);

client.start(); // 创建一个客户端

client.create().forPath("/my/path", myData) // 创建一个Zookeeper的znode节点

Zookeeper用来解决分布式系统中的数据一致性问题

在集中式系统中高并发的情况下,多条线程之间对共享资源进行抢夺使用权并进行数据修改,可能会导致数据的不一致问题,我们可以采用同步锁的方式来解决.

在分布式系统中,实际上是多个进程对共享数据的修改,此时线程的同步锁已经无法解决这个问题例如分布式系统:

订单服务和商品服务可能同时操作订单表,对订单表进行增删改操作

而这两个服务是部署到不同的机器上的,所以他们是不同的进程

我们可以采用分布式锁的方式对这两个进程进行限制

下一篇我将使用Zookeeper实现分布式锁,来保证分布式系统中数据的一致性.