<hr> <div id="div1"><h3> <font color=red> Zookeeper的读写机制 </font> <h3></div> - Zookeeper是一个由多个server组成的集群 - 一个leader，多个follower - 每个server保存一份数据副本 - 全局数据一致 - 分布式读写 - 更新请求转发，由leader实施 Zookeeper的保证 > 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行 数据更新原子性，一次数据更新要么成功，要么失败 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的 实时性，在一定事件范围内，client能读到最新数据 <hr> <div id="div1"><h3> <font color=red> </font> <h3></div> 选举状态： 1. LOOKING，竞选状态。 2. FOLLOWING，随从状态，同步leader状态，参与投票。 3. OBSERVING，观察状态,同步leader状态，不参与投票。 4. LEADING，领导者状态。 服务器ID： 比如有三台服务器，编号分别是1,2,3。 编号越大在选择算法中的权重越大。 顺序访问： 对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，这个编号也叫做时间戳——zxid（Zookeeper Transaction Id） 数据ID： 服务器中存放的最大数据ID. 值越大说明数据越新，在选举算法中数据越新权重越大。 逻辑时钟（投票的次数）：同一轮投票过程中的逻辑时钟值是相同的。每投完一次票该数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断 Leader服务器是整个zookeeper集群工作的核心，负责进行选举投票的发起和决议，更新系统状态。 Follower服务器是zookeeper集群状态的跟随者，用于接收客户端的请求并向客户端返回结果，在选举过程中参与投票 <hr> <div id="div1"><h3> <font color=red> Zookeeper的Leader选举 </font> <h3></div> (1) 状态变更：如果是服务器运行期间进行leader选举，需要对非Observer服务器进行状态变更为Looking。 (2) 进行投票：每台服务器都会选举自己作为leader，投票的内容包括服务器的myid（ZooKeeper集群搭建的时候每个服务器的编号）和ZXID(ZooKeeper为每一个事务请求分配的唯一一个全局事务ID) (3) 接收投票：接收来自其它服务器的投票, 判断投票的有效性。 (4) 处理投票：需要将其他服务器的投票与自己的投票比较，比较规则如下： 先比较ZXID，ZXID比较大的服务器会优先作为Leader。 ZXID相同的话，就比较myid，myid比较大的服务器作为Leader服务器。 (5) 统计投票：每次投票后，服务器都会统计所有投票，判断是否有过半的机器接收到相同的投票信息。 (6) 改变服务器状态：如果是follower, 就变更为Following，如果是leader, 就变更为leading。 <hr> <div id="div1"><h3> <font color=red> Zookeeper的分布式锁架构图 </font> <h3></div> 1. 获取分布式锁时在Lock节点下创建临时顺序节点，释放锁的时候删除该临时节点。 2. 客户端调用createNode方法在Lock节点下创建临时顺序节点。然后调用getChildren获取所有子节点。 2.1 如果发现当前自己创建的节点的序号是最小的话，就认定该客户端获取到锁。 2.2 如果发现不是最小的节点。说明获取锁失败，此时客户端需要找到比自己小的节点，对其注册事件监听器。 3. 当前获取到锁的客户端删除当前最小节点，那么注册过事件监听器的客户端会收到通知，此时再次判断是否自己的节点是最小的，是的话直接获取到锁，不是的话重复步骤监听比自己小的节点的事件。 CAP理论，即满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance） <hr> <div id="div1"><h3> <font color=red> 基于数据库实现分布式锁 </font> <h3></div> 基于数据库表 创建一张锁表。当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。 当我们想要锁住某个方法时，执行以下SQL：  因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。 当方法执行完毕之后，想要释放锁的话，需要执行以下Sql:   <hr> <div id="div1"><h3> <font color=red> Zookeeper的集群安装配置 </font> <h3></div> 1.上传zk安装包 2.解压 3.配置（先在一台节点上配置） 3.1添加一个zoo.cfg配置文件 $ZOOKEEPER/conf mv zoo_sample.cfg zoo.cfg 3.2修改配置文件（zoo.cfg） dataDir=/itcast/zookeeper-3.4.5/data server.5=itcast05:2888:3888 server.6=itcast06:2888:3888 server.7=itcast07:2888:3888 3.3在（dataDir=/itcast/zookeeper-3.4.5/data）创建一个myid文件，里面内容是server.N中的N（server.2里面内容为2） echo "5" > myid 3.4将配置好的zk拷贝到其他节点 scp -r /itcast/zookeeper-3.4.5/ itcast06:/itcast/ scp -r /itcast/zookeeper-3.4.5/ itcast07:/itcast/ 3.5注意：在其他节点上一定要修改myid的内容 在itcast06应该讲myid的内容改为6 （echo "6" > myid） 在itcast07应该讲myid的内容改为7 （echo "7" > myid） 4.启动集群 分别启动zk ./zkServer.sh start <hr> <div id="div1"><h3> <font color=red> Zookeeper的配置文件参数 </font> <h3></div> zookeeper的默认配置文件为zookeeper/conf/zoo_sample.cfg，需要将其修改为zoo.cfg。其中各配置项的含义，解释如下： - 1.tickTime：CS通信心跳时间 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单位。 tickTime=2000 - 2.initLimit：LF初始通信时限 集群中的follower服务器(F)与leader服务器(L)之间**初始连接**时能容忍的最多心跳数（tickTime的数量）。 initLimit=5 - 3.syncLimit：LF同步通信时限 集群中的follower服务器与leader服务器之间**请求和应答**之间能容忍的最多心跳数（tickTime的数量）。 syncLimit=2 - 4.dataDir：数据文件目录 Zookeeper保存数据的目录，默认情况下，Zookeeper将写数据的日志文件也保存在这个目录里。 dataDir=/home/michael/opt/zookeeper/data - 5.clientPort：客户端连接端口 客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。 clientPort=2181 - 6.服务器名称与地址：集群信息（服务器编号，服务器地址，LF通信端口，选举端口） 这个配置项的书写格式比较特殊，规则如下： server.N=YYY:A:B server.1=itcast05:2888:3888 server.2=itcast06:2888:3888 server.3=itcast07:2888:3888