**获取centos7 ip** ```bash ifconfig eth0 | grep "inet" | grep "192" | cut -d " " -f 10 ``` **查看主机名** - hostname **修改主机名(重启后无效)** - hostname hadoop **永久修改主机名** ```bash [root@zqq1 etc]# pwd & cat hostname [1] 8390 /etc #当前路径 zqq1 主机名 ``` *host 修改* ```bash [root@zqq1 etc]# pwd & cat hosts [1] 8442 /etc 192.168.5.5 zqq3 zqq3 192.168.5.4 zqq2 zqq2 192.168.5.3 zqq1 zqq1 192.168.5.2 zqq zqq 127.0.0.1 localhost #127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [1]+ 完成 pwd ``` *Zookeeper 优点* --- 特点 说明 最终一致性: 为客户端展示同一个视图，这是zookeeper里面一个非常重要的功能 可靠性: 如果消息被到一台服务器接受，那么它将被所有的服务器接受。 实时性: Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 独立性: 各个Client之间互不干预 原子性: 更新只能成功或者失败，没有中间状态。 顺序性: 所有Server，同一消息发布顺序一致。 ---- **zookeeper集群机制** - 半数机制：集群中半数以上机器存活，集群可用。 - zookeeper适合装在奇数台机器上！！！ **解压zookeeper到/usr/local (自定义) 修改 这个conf路径下的zoo_sample.cfg修改为zoo.cfg 修改dataDir/log路径为** > dataDir=/usr/local/zookeeper/data dataLogDir=/usr/local/zookeeper/logs **启动** ```bash [root@zqq1 zookeeper]# zkServer.sh start ZooKeeper JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED ``` *查看状态* ```bash [root@zqq1 zookeeper]# zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Error contacting service. It is probably not running. #未集群 [root@zqq1 zookeeper]# jps 8051 QuorumPeerMain #已经启动 8202 Jps ``` **配置集群** ```bash server.0=zqq1:2888:3888 server.1=zqq3:2888:3888 server.2=zqq2:2888:3888 ``` >配置参数解读 Server.A=B:C:D。 A是一个数字，表示这个是第几号服务器； B是这个服务器的ip地址； C是这个服务器与集群中的Leader服务器交换信息的端口； D是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。 **关于A参数** > 集群模式下配置一个文件myid，这个文件在dataDir目录下，这个文件里面有一个数据就是A的值，Zookeeper启动时读取此文件，拿到里面的数据与zoo.cfg里面的配置信息比较从而判断到底是哪个server。 ### 配置参数解读 **tickTime：** >通信心跳数，Zookeeper服务器心跳时间，单位毫秒 Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。 它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime) **initLimit：** >LF初始通信时限 集群中的follower跟随者服务器(F)与leader领导者服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。 投票选举新leader的初始化时间 Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。 Leader允许F在initLimit时间内完成这个工作。 **syncLimit：** >LF同步通信时限 集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime， Leader认为Follwer死掉，从服务器列表中删除Follwer。 在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。 如果L发出心跳包在syncLimit之后，还没有从F那收到响应，那么就认为这个F已经不在线了。 **dataDir：** > 数据文件目录+数据持久化路径 保存内存数据库快照信息的位置，如果没有其他说明，更新的事务日志也保存到数据库。 **clientPort：** > 客户端连接端口 监听客户端连接的端口 #### Zookeeper的核心 >Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协 议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者 崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后 ，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（ proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识 leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的 统治时期。低32位用于递增计数。 **每个Server在工作过程中有三种状态：** - LOOKING：当前Server不知道leader是谁，正在搜寻 - LEADING：当前Server即为选举出来的leader - FOLLOWING：leader已经选举出来，当前Server与之同步 **Zookeeper 的保证** - 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行 - 数据更新原子性，一次数据更新要么成功，要么失败 - 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的 - 实时性，在一定事件范围内，client能读到最新数据 **Follower主要有四个功能：** 1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）； 2. 接收Leader消息并进行处理； 3. 接收Client的请求，如果为写请求，发送给Leader进行投票； 4. 返回Client结果。 #### Follower的消息循环处理如下几种来自Leader的消息： 1. PING消息： 心跳消息； 2. PROPOSAL消息：Leader发起的提案，要求Follower投票； 3. COMMIT消息：服务器端最新一次提案的信息； 4. UPTODATE消息：表明同步完成； 5. REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息； 6. SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。 ##### zxid - znode节点的状态信息中包含czxid, 那么什么是zxid呢? - ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生. 创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加. ### Zookeeper工作原理 ```text Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。 实现这个机制的协议叫做Zab协议。 Zab协议有两种模式，它们分别是恢复模式和广播模式。 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。 状态同步保证了leader和server具有相同的系统状态。 一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。 这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。 待到同步结束，它也参与消息广播。 Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。 广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。 所有的提议(proposal)都在被提出的时候加上了zxid。 实现中zxid是一个64为的数字它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。 低32位是个递增计数。 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态 ``` #### Leader的选举 > 每个Server启动以后都询问其它的Server它要投票给谁。 对于其他server的询问，server每次根据自己的状态 都回复自己推荐的leader的id和上一次处理事务的 zxid（系统启动时每个server都会推荐自己） 收到所有Server回复以后，就计算出zxid最大的哪个 Server，并将这个Server相关信息设置成下一次要投 票的Server。 计算这过程中获得票数最多的的sever为获胜者，如 果获胜者的票数超过半数，则改server被选为leader 。否则，继续这个过程，直到leader被选举出来。 1. Leader 选举 2. leader就会开始等待server连接 3. Follower连接leader，将最大的zxid发送给leader 4. Leader根据follower的zxid确定同步点 5. 完成同步后通知follower 已经成为uptodate状态 6. Follower收到uptodate消息后，又可以重新接受client的 请求进行服务了 修改zookpeer.out的文件位置 修改zkEnv.sh的 ZOO_LOG_DIR="$ZOOKEEPER_PREFIX/logs"
*******************************************************************************************************************************
感谢阿贝云提供的免费云服务器和免费虚拟主机，1C1G5M配置，搭配内网穿透，真香，看视频听歌曲无压力，*
运行起来也相当流畅，网速个人使用是真的赞，欢迎大家使用
*******************************************************************************************************************************