zookeeper2

数据发布订阅/ 配置中心实现配置信息的集中式管理和数据的动态更新实现配置中心有两种模式：push 、pull。长轮训zookeeper采用的是推拉相结合的方式。 客户端向服务器端注册自己需要关注的节点。一旦节点数据发生变化，那么服务器端就会向客户端发送watcher事件通知。客户端收到通知后，主动到服务器端获取更新后的数据数据量比较小数据内容在运行时会发生动态变更集群中的各个机器共享配置负载均衡请求/数据分摊多个计算机单元上分布式锁通常实现分布式锁有几种方式redis。 setNX 存在则会返回0， 不存在数据方式去实现创建一个表， 通过索引唯一的方式create table (id , methodname …) methodname增加唯一索引insert 一条数据XXX delete 语句删除这条记录mysql for update 行锁，杜占锁zookeeper实现排他锁利用路径唯一共享锁（读锁） locks当中是有序节点，控制使用权限，每一个客户端写一个节点之后，获取到最小节点，获取数据，有写的操作，优先处理写的节点，利用节点特性实现共享锁，使用java api的方式package zk.lock;import org.apache.zookeeper.CreateMode;import org.apache.zookeeper.KeeperException;import org.apache.zookeeper.ZooDefs;import org.apache.zookeeper.ZooKeeper;import java.io.IOException;import java.util.List;import java.util.Random;import java.util.SortedSet;import java.util.TreeSet;import java.util.concurrent.CountDownLatch;import java.util.concurrent.TimeUnit;public class DistributeLock { //根节点 private static final String ROOT_LOCKS = “/LOCKS”; private ZooKeeper zooKeeper; //节点的数据 private static final byte[] data = {1, 2}; //会话超时时间 private int sessionTimeOut; //记录锁节点id private String lockID; private CountDownLatch countDownLatch = new CountDownLatch(1); public DistributeLock() throws IOException, InterruptedException { this.zooKeeper = ZookeeperClient.getInstance(); this.sessionTimeOut = ZookeeperClient.getSESSIONTIMEOUT(); } /** * 获取锁的方法 * * @return / public synchronized boolean lock() { try { //LOCKS/000001 lockID = zooKeeper.create(ROOT_LOCKS + “/”, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); System.out.println(Thread.currentThread().getName() + “->” + “成功创建了lock节点[” + lockID + “,开始竞争锁]”); //获取根节点下的所有子节点 List<String> childrenNodes = zooKeeper.getChildren(ROOT_LOCKS, true); // 排序，从小到大 TreeSet<String> sortedSet = new TreeSet<>(); for (String children : childrenNodes) { sortedSet.add(ROOT_LOCKS + “/” + children); } //获取到最小的节点 String first = sortedSet.first(); if (lockID.equals(first)) { //表示当前就是最小的节点 System.out.println(Thread.currentThread().getName() + “–>成功获得锁，locak节点为：【” + lockID + “]”); return true; } SortedSet<String> lessThanLockId = sortedSet.headSet(lockID); if (!lessThanLockId.isEmpty()) { //获取到比当前LockId这个节点更小的上一个节点 String prevLockId = lessThanLockId.last(); //监控上一个节点 zooKeeper.exists(prevLockId, new LockWatcher(countDownLatch)); //如果会话超时或者节点被删除（释放）了 countDownLatch.await(sessionTimeOut, TimeUnit.MILLISECONDS); System.out.println(Thread.currentThread().getName() + “成功获取锁：【” + lockID + “】”); return true; } } catch (KeeperException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } return false; } public synchronized boolean unLock() { System.out.println(Thread.currentThread().getName() + “–>开始释放锁”); try { zooKeeper.delete(lockID, -1); System.out.println(“节点” + lockID + “被释放了”); return true; } catch (InterruptedException e) { e.printStackTrace(); } catch (KeeperException e) { e.printStackTrace(); } return false; } public static void main(String[] args) { CountDownLatch countDownLatch = new CountDownLatch(10); Random random = new Random(); for (int i = 0; i < 10; i++) { new Thread(() -> { DistributeLock lock = null; try { lock = new DistributeLock(); countDownLatch.countDown(); countDownLatch.await(); lock.lock(); Thread.sleep(random.nextInt(500)); } catch (IOException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } finally { if (lock != null) { lock.unLock(); } } }).start(); } }}package zk.lock;import org.apache.zookeeper.WatchedEvent;import org.apache.zookeeper.Watcher;import java.util.concurrent.CountDownLatch;public class LockWatcher implements Watcher { private CountDownLatch countDownLatch; public LockWatcher(CountDownLatch latch) { this.countDownLatch = latch; } @Override public void process(WatchedEvent event) { if (event.getType() == Event.EventType.NodeDataChanged) { countDownLatch.countDown(); } }}命名服务master选举 724小时可用， 99.999%可用master-slave模式 slave监听master节点，如果master节点挂掉，slave自动接替master,心跳机制维持，出现网络异常，slave认为master挂掉了，可能出现双主节点的情况，重复处理数据使用zookeeper解决上述问题，往某一个节点注册master节点，只有一个能够注册成功，注册成功的为master，如果失去联系，节点会被删除，不会出现脑裂问题 per实现原理讲解分布式队列master选举改成多线程(多进程)模型（master-slave） 创建三个工程，while去抢分布式队列activeMQ、kafka、….先进先出队列通过getChildren获取指定根节点下的所有子节点，子节点就是任务确定自己节点在子节点中的顺序如果自己不是最小的子节点，那么监控比自己小的上一个子节点，否则处于等待接收watcher通知，重复流程Barrier模式 在一个节点下只能允许多少数据，只有子节点达到一定数量，才执行 curator 提供应用场景的封装 curator-reciples master/leader选举 分布式锁（读锁、写锁）分布式队列LeaderLatch写一个master LeaderSelector每一个应用都写一个临时有序节点，根据最小的节点来获得优先权 curator 提供应用场景的封装 curator-reciples master/leader选举 分布式锁（读锁、写锁）分布式队列…LeaderLatch 写一个master LeaderSelector 每一个应用都写一个临时有序节点，根据最小的节点来获得优先权zookeeper集群角色leader leader是zookeeper集群的核心。事务请求的唯一调度者和处理者，保证集群事务处理的顺序性集群内部各个服务器的调度者follower处理客户端非事务请求，以及转发事务请求给leader服务器参与事务请求提议（proposal）的投票（客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader commit； leader会发起一个提案，要求follower投票）参与leader选举的投票observer 观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上。 增加observer不影响集群中事务处理能力，同时还能提升集群的非事务处理能力zookeeper的集群组成 zookeeper一般是由 2n+1台服务器组成leader选举选举算法： leaderElection AuthFastLeaderElection FastLeaderElectionQuorumPeer startLeaderElection源码地址：https://github.com/apache/zoo…需要的条件： jdk 1.7以上 、ant 、ideaFastLeaderElectionserverid : 在配置server集群的时候，给定服务器的标识id（myid）zxid : 服务器在运行时产生的数据ID， zxid的值越大，表示数据越新Epoch: 选举的轮数server的状态：Looking、 Following、Observering、Leading 第一次初始化启动的时候： LOOKING所有在集群中的server都会推荐自己为leader，然后把（myid、zxid、epoch）作为广播信息，广播给集群中的其他server, 然后等待其他服务器返回每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后，开始判断投票的有效性a) 判断逻辑时钟(Epoch) ，如果Epoch大于自己当前的Epoch，说明自己保存的Epoch是过期。更新Epoch，同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况b) 如果Epoch小于目前的Epoch，说明对方的epoch过期了，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要讲自己的信息发送给对方c) 如果sid等于当前sid，根据规则来判断是否有资格获得leader 接受到来自其他服务器的投票后，针对每一个投票，都需要将别人的投票和自己的投票进行对比，zxid，zxid最大的服务器优先统计投票ZAB协议拜占庭问题一组拜占庭将军分别各率领一支军队共同围困一座城市。为了简化问题，将各支军队的行动策略限定为进攻或撤离两种。因为部分军队进攻部分军队撤离可能会造成灾难性后果，因此各位将军必须通过投票来达成一致策略，即所有军队一起进攻或所有军队一起撤离。因为各位将军分处城市不同方向，他们只能通过信使互相联系。在投票过程中每位将军都将自己投票给进攻还是撤退的信息通过信使分别通知其他所有将军，这样一来每位将军根据自己的投票和其他所有将军送来的信息就可以知道共同的投票结果而决定行动策略。系统的问题在于，将军中可能出现叛徒，他们不仅可能向较为糟糕的策略投票，还可能选择性地发送投票信息。假设有9位将军投票，其中1名叛徒。8名忠诚的将军中出现了4人投进攻，4人投撤离的情况。这时候叛徒可能故意给4名投进攻的将领送信表示投票进攻，而给4名投撤离的将领送信表示投撤离。这样一来在4名投进攻的将领看来，投票结果是5人投进攻，从而发起进攻；而在4名投撤离的将军看来则是5人投撤离。这样各支军队的一致协同就遭到了破坏。由于将军之间需要通过信使通讯，叛变将军可能通过伪造信件来以其他将军的身份发送假投票。而即使在保证所有将军忠诚的情况下，也不能排除信使被敌人截杀，甚至被敌人间谍替换等情况。因此很难通过保证人员可靠性及通讯可靠性来解决问题。假始那些忠诚（或是没有出错）的将军仍然能通过多数决定来决定他们的战略，便称达到了拜占庭容错。在此，票都会有一个默认值，若消息（票）没有被收到，则使用此默认值来投票。上述的故事映射到计算机系统里，将军便成了计算机，而信差就是通信系统。虽然上述的问题涉及了电子化的决策支持与信息安全，却没办法单纯的用密码学与数字签名来解决。因为电路错误仍可能影响整个加密过程，这不是密码学与数字签名算法在解决的问题。因此计算机就有可能将错误的结果提交去，亦可能导致错误的决策。 paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题ZAB协议，基于paxos协议的一个改进。zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcastzab协议的原理在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，把数据的状态变更以事务请求的形式广播到其他的节点zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫followerleader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息崩溃恢复原子广播zab协议的工作原理什么情况下zab协议会进入崩溃恢复模式(没有接受到的数据进行同步)当服务器启动时当leader服务器出现网络中断、崩溃或者重启的情况集群中已经不存在过半的服务器与该leader保持正常通信zab协议进入崩溃恢复模式会做什么当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步问题 假设一个事务在leader服务器被提交了，并且已经有过半的follower返回了ack。 在leader节点把commit消息发送给follower机器之前leader服务器挂了怎么办 zab协议，一定需要保证已经被leader提交的事务也能够被所有follower提交zab协议需要保证，在崩溃恢复过程中跳过哪些已经被丢弃的事务回顾zookeeper数据模型 临时节点（有序）、 持久化节点（有序） 临时节点其他节点也能看到zookeeper是一个开源的分布式协调框架; 数据发布订阅、负载均衡、集群、master选举。。。原子性： 要么同时成功、要么同时失败 （分布式事务）单一视图： 无论客户端连接到哪个服务器，所看到的模型都是一样可靠性：一旦服务器端提交了一个事务并且获得了服务器端返回成功的标识，那么这个事务所引起的服务器端的变更会一直保留实时性： 近实时zookeeper并不是用来存储数据的，通过监控数据状态的变化，达到基于数据的集群管理。分布式集群配置修改zoo.cfgserver.id=ip:port:port 第一个Port 数据同步通信、 第二个port ：leader选举（3181）id=myid (myid 参与leader选举、 在整个集群中表示唯一服务器的标识)dataDir目录下 创建一个myid的文件 ， 内容： server.id对应当前服务器的id号如果增加observer 需要在第一步中， server.id=ip:port:port:observer ; peerType=observer会话NOT_CONNECTED - > CONNECTING ->CONNECTED ->ClOSE数据模型数据模型是一个树形结构，最小的数据单元是ZNODE临时节点和持久化节点临时有序节点持久化有序节点状态信息StatcZxid = 0xb0000000f ctime = Sun Aug 13 20:24:03 CST 2017mZxid = 0xb0000000fmtime = Sun Aug 13 20:24:03 CST 2017pZxid = 0xb0000000fcversion = 0dataVersion = 0aclVersion = 0ephemeralOwner = 0x15dda30f72f0000dataLength = 2numChildren = 0zab协议 ： 如果客户端发了一个事务请求给到leader， 而leader发送给各个follower以后，并且收到了ack，leader已经commit。 在准备ack给各个follower节点comit的时候，leader挂了，怎么处理的。选举新的leader（zxid的最大值）同步给其他的folowerwatcherEventyTypeNone 客户端与服务器端成功建立会话NodeCreated 节点创建NodeDeleted 节点删除NodeDataChanged 数据变更：数据内容NodeChildrenChanged 子节点发生变更： 子节点删除、新增的时候，才会触发watcher的特性一次性触发： 事件被处理一次后，会被移除，如果需要永久监听，则需要反复注册zkClient （ 永久监听的封装）curator java api的话， zk.exists , zk.getData 创建一个watcher监听zookeeper序列化使用的是JuteAcl权限的操作保证存储在zookeeper上的数据安全性问题schema(ip/Digest/world/super)授权对象（192.168.1.1/11 , root:root / world:anyone/ super）数据存储内存数据和磁盘数据zookeeper会定时把数据存储在磁盘上。DataDir = 存储的是数据的快照快照： 存储某一个时刻全量的内存数据内容DataLogDir 存储事务日志zxid :服务器运行时产生的日志idlog.zxid查看事务日志的命令java -cp :/mic/data/program/zookeeper-3.4.10/lib/slf4j-api-1.6.1.jar:/mic/data/program/zookeeper-3.4.10/zookeeper-3.4.10.jar org.apache.zookeeper.server.LogFormatter log.200000001zookeeper 有三种日志zookeeper.out //运行日志快照 存储某一时刻的全量数据事务日志 事务操作的日志记录