Zookeeper(一)
概述
官网描述:
Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.
解释:ApacheZooKeeper致力于开发和维护开源服务器,它能够实现**高度可靠的分布式协调**
非官方解释:
zookeeper是一种分布式协调服务;(要点:可以协调分布式应用);
背景:
最初目的;构建于Yahool之上,用于简单而稳健的访问他们的应用程序。
如今发展:广泛应用于Hadoop、HBase和其他分布式框架中;
题外话1:分布式应用
- 结构:Server服务器和Client客户端。服务器应用程序是分布式的,具有通用接口,以便客户端可以链接到集群中的任何服务器并获得相同的结果。客户端是与分布式应用进行交互的工具。
- 优点
高可用性:单台机器宕机不会引起整个服务挂掉
重用度高:模块化的直接结果
迭代快:开发和发布速度快
扩展性高:模块化的开发,需要什么模块,直接接入即可 - 缺点
服务URL管理难度大
服务依赖关系复杂
服务容量问题
服务统一配置
服务消费
核心服务挂掉带来的影响大 - 问题
分布式事务:单体应用的话,无论单线程还是多线程,我们操作的都是一个jvm下的数据,我们很容易可以使用spring或者数据库的事务,控制数据操作的原子性;分布式应用下,事务的控制则大大不同。首先,分布式应用后,每个服务使用的都是各自的jvm数据,服务之间调用的话,操作的也不是自己jvm的数据。而且分布式下,某些业务的原子性可能是跨服务的,对于这种跨服务的业务,仅仅依靠spring的事务是不能实现的。(解决方案:1 分布式锁(会增加系统复杂度,并且事务跨越的服务越多,消耗的资源越大,性能越低)、2 重试机制(考虑幂等性:设置一个唯一的键,在写入的时候检查是否已经存在,避免重复写入,幂等的前提是高可用))
负载均衡:分布式服务下,每个服务的提供者会有很多,如何路由请求到这些服务器上?如何高效的使用这些服务器?
服务注册与发现:服务提供者越来越多,怎么才能让消费者知道呢?服务提供者上下线时,如何让消费者知道?
数据库性能和高可用:传统数据库很难像应用服务器那样做到线性扩容,尤其是关系数据库,多个服务提供者,可能都要操作同一个数据库,数据库连接也相应的越来越多,势必可能会造成数据库的压力大增,如何保证这些性能?并且随之而来的,如果数据库挂掉,如何保证系统的健壮性,是否要做数据库的高可用?
原理
- 数据结构:
- 节点介绍
- 内部命令
- Paxos的应用
安装、使用
- windows 安装
- linux安装
- 配置文件
- 启动
- 关闭
- 服务端
- 客户端
zookeeper集群相关操作
- 集群概述
- 集群配置
- 原理
- TODO