ZK

zk集群的选举机制： 半数机制 ：zk集群中的有半数以上的节点存活，zk就能正常运行，所以zk集群节点最好是奇数个。Zk集群中只有一个leader，其他都是follower 选举机制 :会经过投票，票数大于半数以上的第一台服务器，当选leader Server1 server2 server3 server4 server5 (id大的不给id小的投票，id小的会给id大的投票，server1-5，id依次增大) 5台机器：server1开始投票，server1投自己，因为server1 id最小，所以server1只有一票 Server2：server2会投自己，server1也会投server2一票，server2 两票 Server3：server3会投自己，server1和server2各自投server3一票，那么server3就三票，三票在半数以上(一共五台机器)，所以就选server3当leader， 后边的server4(4票)和server5(5票)虽然来都比server3票数多，但是server3是第一个票数大于半数以上的，所以就选择server3当leader Zokeeper的监听的原理：(重点) 1）首先要有一个main()线程 2）在main()线程中创建zookeeper的客户端，这时就会创建两个线程，一个负责网络连接通信(connect)

问题描述 测试环境ZK集群的三个节点中zk1状态虽然是 follower ，启动也能正常启动（通过telnet也能telnet 2181端口）; 无法通过zk客户端去连接2181端口，状态一致是 CONNECTING 查看zk集群所有节点状态 /data/zookeeper-new-1/bin/zkServer.sh status /data/zookeeper-new-2/bin/zkServer.sh status /data/zookeeper-new-3/bin/zkServer.sh status 得到zk2是主节点 查看各个节点的data数据大小 du -h /data/zookeeper/tmp/zk1/data/version-2/ --max-depth=1 du -h /data/zookeeper/tmp/zk2/data/version-2/ --max-depth=1 du -h /data/zookeeper/tmp/zk3/data/version-2/ --max-depth=1 [appadm@moonmall_Z1 zookeeper]$ du -h /data/zookeeper/tmp/zk1/data/version-2/ --max-depth=1 2.4G /data/zookeeper/tmp/zk1/data/version-2/

1.1. 集群模式 1.1.1. 数据同步总流程 1.1.1.1. OBSERVING 1.1.1.2. FOLLOWING 1.1.1.3. LEADING 1.1.2. 领导选举 1.1.2.1. 领导选举初始化 1.1.2.2. 线程逻辑 1.1.2.2.1. 发送请求用到的线程 1.1.2.2.2. 接收请求用到的线程 1.1.2.2.3. 发送 / 接收总览 1.1.2.3. 领导选举算法 来源： https://www.cnblogs.com/Soy-technology/p/11404343.html

1.1. ZAB 协议是什么？ ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。 ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。 当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的 Leader 服务器，然后集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步，当集群中超过半数机器与该 Leader 服务器完成数据同步之后，退出恢复模式进入消息广播模式， Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。 1.2. Znode 有哪几种类型 PERSISTENT- 持久节点 除非手动删除，否则节点一直存在于 Zookeeper 上 EPHEMERAL- 临时节点 临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与 zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。 PERSISTENT_SEQUENTIAL- 持久顺序节点 基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。 EPHEMERAL_SEQUENTIAL- 临时顺序节点

原理简介： 一般在部署ActiveMQ集群的时候，更倾向于使用基于ZooKeeper的Replicated LevelDB Store方式，该方式是Master Slave部署方案的其中一种策略，也是在多台主机实现ActiveMQ集群的主流部署方式。 此教程只保证了高可用性。要想保证负载均衡得再结合Broker Clusters 部署方案，配置网络连接器。 工作流程： 在ZooKeeper中管理多个Broker节点，根据 Master选举策略让其中一个 Broker选举为Master（只有Master才具备对外提供服务的能力），剩下Broker为slave。 编码时，client端（消费者）通过failover协议来连接ActiveMQ集群。 一、服务端配置 1. ZooKeeper伪集群配置 -- 服务端口 集群通信端口 节点目录/opt/下 zk1 2181 2887:3887 /zookeeper/zk1 zk2 2182 2888:3888 /zookeeper/zk2 zk3 2183 2889:3889 /zookeeper/zk3 集群通信端口：第一个端口是master和slave之间的通信端口，默认是2888；第二个端口是leader选举的端口，集群刚启动的时候选举或者leader挂掉之后进行新的选举的端口默认是3888。 在/opt

一、kafka各成员 kafka： 分布式消息系统，将消息直接存入磁盘，默认保存一周。 broker： 组成kafka集群的节点，之间没有主从关系，依赖zookeeper来协调，broker负责满息的读写和存储，一个broker可以管理多个partition. producer： 消息的生产者，自己决定向哪个partition中去生产消息，两种机利：hash，轮循。 consumer： 消息的消费者，consumer通过zookeeper去维护消费者偏移量。consumer有自己的消费者组，不同的组之间消费同一个topic数据，互不影响， 相同的组内的不同的consumer消费同一个topic，这个topic中相同的数据只能被消费一次。 topic： 一类消息总称/一个消息队列。topic是由partition组成的，有多少？-> 创建指定。 partition： 组成topic的单元，每个partition有副本，有多少？-> 创建topic时指定。每个partition只能由一个broker来管理，这个broker就是这个partition的leader。 zookeeper： 协调kafka broker，存储原数据：consumer的offset+broker信息+topic信息+partition信息； 二、分析zookeeper元数据存储 1、创建topic [root

目录 过滤器（Filter） HBase过滤器的分类 比较过滤器 专用过滤器 正文 回到顶部 过滤器（Filter） 　　基础API中的查询操作在面对大量数据的时候是非常苍白的，这里Hbase提供了高级的查询方法：Filter。Filter可以根据簇、列、版本等更多的条件来对数据进行过滤，基于Hbase本身提供的三维有序（主键有序、列有序、版本有序），这些Filter可以高效的完成查询过滤的任务。带有Filter条件的RPC查询请求会把Filter分发到各个RegionServer，是一个服务器端（Server-side）的过滤器，这样也可以降低网络传输的压力。 　　要完成一个过滤的操作，至少需要两个参数。 一个是抽象的操作符 ，Hbase提供了枚举类型的变量来表示这些抽象的操作符：LESS/LESS_OR_EQUAL/EQUAL/NOT_EUQAL等； 另外一个就是具体的比较器（Comparator） ，代表具体的比较逻辑，如果可以提高字节级的比较、字符串级的比较等。有了这两个参数，我们就可以清晰的定义筛选的条件，过滤数据。 抽象操作符（比较运算符） LESS < LESS_OR_EQUAL <= EQUAL = NOT_EQUAL <> GREATER_OR_EQUAL >= GREATER > NO_OP 排除所有 比较器（指定比较机制） BinaryComparator

ps.本文为《从Paxos到Zookeeper 分布式一致性原理与实践》笔记之一 ZooKeeper ZooKeeper曾是Apache Hadoop的一个子项目，是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等。 ZooKeeper是Google的Chubby一个开源的实现，由雅虎创建，是Hadoop和Hbase的重要组件。 ZooKeeper没有直接采用paxos算法，而是采用了一种被称为ZAB（Zookeeper Atomic Broadcast）的一致性协议 ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper可以保证如下分布式一致性特性 顺序一致性：从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中； 原子性：所有事务的请求结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么在整个集群中所有机器上都成功应用了某一个事务，要么都没有应用，没有中间状态； 单一视图：无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。 可靠性：一旦服务端成功应用了一个事务，并完成对客户端的响应

分布式锁有几种实现形式 n个线程同时并发－countdown zk配置中心，watch机制底层 zk分布式锁 并发的实践 说说springcloud组件 自己实现一个生产者、消费者 java 基本类型与包装类型 redis底层zset实现 mysql索引底层说一下 B＋树 自平衡 myisam和innordb区别，myisam为什么快 truncate与delete区别，trucate为什么快 联合索引原则 like模糊查询如何优化 来源： https://www.cnblogs.com/silyvin/p/11380098.html

一、节点增删改查 1.1 启动服务和连接服务 # 启动服务 bin/zkServer.sh start #连接服务 不指定服务地址则默认连接到localhost:2181 zkCli.sh -server hadoop001:2181 1.2 help命令 使用 help 可以查看所有命令及格式。 1.3 查看节点列表 查看节点列表有 ls path 和 ls2 path 两个命令，后者是前者的增强，不仅可以查看指定路径下的所有节点，还可以查看当前节点的信息。 [zk: localhost:2181(CONNECTED) 0] ls / [cluster, controller_epoch, brokers, storm, zookeeper, admin, ...] [zk: localhost:2181(CONNECTED) 1] ls2 / [cluster, controller_epoch, brokers, storm, zookeeper, admin, ....] cZxid = 0x0 ctime = Thu Jan 01 08:00:00 CST 1970 mZxid = 0x0 mtime = Thu Jan 01 08:00:00 CST 1970 pZxid = 0x130 cversion = 19 dataVersion = 0 aclVersion