分布式协调服务-zookeeper
分布式环境的特点：分布性、并发性（基于进程的）、无序性（进程之间消息通信）
分布式环境面临的问题：网络通信（网络本身是不可靠的）、网络分区（脑裂，网络延时导致部分节点能够正常通信）、三态（成功、失败、超时）、分布式事务（ACID：原子性、一致性、隔离性、持久性）
中心化和去中心化：冷备、热备
分布式架构里面，很多的架构思想采用：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。最经典的是：zookeeper/etcd
1. CAP/BASE 理论
CAP理论是指在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），三者不可同时满足，最多满足两个
- 一致性：所有节点上的数据，时刻保持一致
- 可用性：每个请求都能够收到一个响应，无论响应成功或者失败
- 分区容错：系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系
CP/AP
CAP理论仅适用于原子读写的NoSql场景，不适用于数据库事务（因为更新一些错误的数据导致数据出现紊乱），虽然XA事务可以保证数据库在分布式系统下ACID特性，但是会带来性能方面的影响。
BASE理论是指Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性），是对CAP中一致性和可用性权衡的结果，每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
- 基本可用：分布式系统在出现不可预知故障的时候，允许损失部分可用性，比如响应时间增加、功能损失（降级）
- 软状态：又称弱状态，允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性
- 最终一致性：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态
2. 初识zookeeper
zookeeper是一个开源的分布式协调服务，是由雅虎创建的，基于google chubby（解决分布式锁），是一种分布式数据一致性的解决方案。
zookeeper应用场景：数据的发布/订阅（disconf）、负载均衡（dubbo）、命名服务、master选举（kafka、hadoop、hbase）、分布式队列、分布式锁等。
zookeeper特性：顺序一致性、原子性、可靠性、实时性
- 顺序一致性：从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中
- 原子性：所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、要么全都不应用
- 可靠性：一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的。
- 实时性：一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态（zookeeper仅仅保证在一定时间内，近实时）
2.1 zookeeper安装
2.1.1 单机环境
- 下载安装包：http://apache.fayea.com/zookeeper/stable/zookeeper-3.4.12.tar.gz
- 解压：tar -zxvf zookeeper-3.4.12.tar.gz
- 配置文件：cd conf 后，复制一份样本配置文件，cp zoo_sample.cfg zoo.cfg
- 运行：sh zkServer.sh
- 客户端连接：sh zkCli.sh -server ip:port
2.1.2 集群环境
zookeeper集群有三种角色：Leader/Follower/Observer
- Leader：负责进行投票的发起和决议，接受所有Follower的提案请求，并统一协调发起提案的投票，负责与所有的follower进行内部的数据交换（同步），更新系统状态
- Follower：接收客户端请求并向客户端返回结果，并参与提案的投票，同时与leader进行数据交换（同步）
- Observer：接收客户端请求，返回读操作结果，如果是写操作转发给Leader节点，但不参与提案的投票，只同步Leader状态，同时与leader进行数据交互（同步）
observer是一种特殊的zookeeper节点，可以帮助解决zookeeper的扩展性：如果大量客户端访问zookeeper集群，为了提高可用性需要增加zookeeper集群机器数量，会导致zookeeper写性能下降，因为zookeeper需要半数以上服务器投票通过，增加投票成本，而observer不参与投票，只接收投票结果。
环境情况：
| 节点IP | 部署位置 | zk选举 |
|---|---|---|
| 192.168.1.131 | /opt | Leader |
| 192.168.1.132 | /opt | Follower |
| 192.168.1.133 | /opt | Follower |
| 192.168.1.134 | /opt | Follower |
| 192.168.1.135 | /opt | Observer |
部署步骤：
-
部署前准备：关掉防火墙、selinux
-
下载zookeeper软件包、解压、复制配置文件
-
修改配置文件
tickTime=2000 dataDir=/opt/zookeeper-3.4.12/data dataLogDir=/tmp/zookeeper/log clientPort=2181 initLimit=10 syncLimit=5 # 经测试，域名不能用 server.1=192.168.1.130:2888:3888 server.2=192.168.1.131:2888:3888 server.3=192.168.1.132:2888:3888 server.4=192.168.1.135:2888:3888:observer- tickTime：Client-Server通信心跳时间（单位：ms）
- dataDir：数据文件目录
- dataLogDir：表示配置 zookeeper事务日志的存储路径，默认指定在dataDir目录下
- initLimit：Leader-Follower初始通信时限（单位：tickTime的数量）
- syncLimit：Leader-Follower同步通信时限（单位：tickTime的数量）
- clientPort：客户端连接端口
- 服务器名称与地址：集群信息（服务器编号，服务器地址，Leader-Follower通信端口，选举端口）
-
创建data数据目录：
mkdir -p /opt/zookeeper-3.4.12/data # myid：服务器编码 echo "1" >> /opt/zookeeper-3.4.12/data/myid -
scp分别传到各个work节点
scp -r /home/gmr/zookeeper-3.4.12 [email protected]:/home/gmr/ scp -r /home/gmr/zookeeper-3.4.12 [email protected]:/home/gmr/ scp -r /home/gmr/zookeeper-3.4.12 [email protected]:/home/gmr/ -
修改myid
echo "2" >> /home/gmr/zookeeper-3.4.12/data/myid echo "3" >> /home/gmr/zookeeper-3.4.12/data/myid echo "4" >> /home/gmr/zookeeper-3.4.12/data/myid -
主从节点分别启动
/home/gmr/zookeeper-3.4.12/bin/zkServer.sh start /home/gmr/zookeeper-3.4.12/bin/zkServer.sh stop /home/gmr/zookeeper-3.4.12/bin/zkServer.sh status
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。