ZK

ZK介绍 ZK = zookeeper ZK 是微服务解决方案中拥有服务注册发现最为核心的环境，是微服务的基石。作为 服务注册发现模块 ，并不是只有ZK一种产品，目前得到行业认可的还有：Eureka、Consul。 这里我们只聊ZK，这个工具本身很小zip包就几兆，安装非常傻瓜，能够支持集群部署。 官网地址： https://zookeeper.apache.org/ 背景 在集群环境下ZK的leader&follower的概念，已经节点异常ZK面临的问题以及如何解决。ZK本身是java语言开发，也开源到Github上但官方文档对内部介绍的很少，零散的博客很多，有些写的很不错。 提问： zookeeper选举算法中的过半票数才提供正常服务，这是什么逻辑？ ZK集群单节点状态（每个节点有且只有一个状态），ZK的定位一定需要一个leader节点处于lading状态。 looking：寻找leader状态，当前集群没有leader，进入leader选举流程。 following：跟随者状态，接受leading节点同步和指挥。 leading：领导者状态。 observing：观察者状态，表名当前服务器是observer。 过半选举算法 ZK中有三种选举算法，分别是LeaderElection,FastLeaderElection,AuthLeaderElection

PS：本篇博客仅仅是个人的笔记，且是个人的理解，文字较为口语化，如有错误，请大牛指出。如果想了解更深入的，可以根据我这篇博客的情况自行查找网上资料（官网或者其他大牛的博客详解） 一、zookeeper的工作流程 zookeeper是整个集群的注册中心，所有的client端想要发起请求，都要经过zookeeper，并通过投票（超过半数）才能得到响应。 二、zookeeper投票机制 zookeeper集群中可以有多个zookeeper server，其中会有一个leader server，其他的都是follower server，当然，leader server也是通过投票选出来的，当票数过半是就可以通过，如果只有一个zookeeper的话，那这个zookeeper就是leader server。client发起的请求（增删改操作，查询操作是由server直接返回，不需要投票）也是通过这种投票机制得到响应的。 三、zookeeper的个数 一般zookeeper的个数要是奇数个，偶数个也是可以的，但没必要。 1、容错：例如，搭建3个和搭建4个zookeeper集群，此时如果要通过client发起的请求，那么3个zookeeper的集群要2票就能通过，那么这个集群就允许一台zookeeper挂掉；而4台zookeeper的集群就要3票才能通过，那么集群也只允许挂一台。既然都允许挂掉一台

现在很流行的Dubbo很多朋友都听说过吧，最近我也在看这方面的东西，分享先我的心得笔记。 很简单重在实现基于 zookeeper的dubbo注册。 框架：springmvc+spring+zookeeper+dubbo 项目分三层，model存放数据，view页面展示、controller下面具体逻辑实现。通过dubbo消费方和供应方注册，供应方给消费方暴露接口，供消费方调用。 工程部署需要配置文件有： applicationContext-dubbo.xml {-- <-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 --> <-- 使用zookeeper注册中心暴露服务地址 --> <-- 生成远程服务代理，可以像使用本地bean一样使用demoService --> <dubbo:reference id="demoService" interface="com.unj.dubbotest.provider.DemoService" /> --} dubbo.properties {-- <--基于ZooKeeper的Dubbo注册中心直接部署tomcat，修改WEB-INF下文件--> dubbo.registry.address=zookeeper://127.0.0.1:2181 dubbo.admin.root.password=root

什么是 ZK Watcher 基于 ZK 的应用程序的一个常见需求是需要知道 ZK 集合的状态。为了达到这个目的，一种方法是 ZK 客户端定时轮询 ZK 集合，检查系统状态是否发生了变化。然而，轮询并不是一种高效的方式，尤其是在状态变化的发生频率很低的时候 因此，ZK 提供了一种通过通知客户端感兴趣的具体时间来避免轮询造成的性能问题的方式，即设置 Watcher 的方式。通过设置 Watcher，ZK 客户端可以对指定的 znode 注册一个通知请求，在 znode 发生变化时收到一个单次的通知。例如，在 znode 被删除时向 Watcher 发送节点被删除的通知 应用 ZK Watcher 的代码通常遵循如下的框架 zk.exists("myZnode", myWatcher, existsCallback, null); Watcher myWatcher new Watcher() { public void process(WatchedEvent event) { // process the watch event } } StatCallback existsCallback = new StatCallback() { public void processResult(int rc, String path, Object ctx, Stat stat) { /

　　什么是 ZK Watcher 　　基于 ZK 的应用程序的一个常见需求是需要知道 ZK 集合的状态。为了达到这个目的，一种方法是 ZK 客户端定时轮询 ZK 集合，检查系统状态是否发生了变化。然而，轮询并不是一种高效的方式，尤其是在状态变化的发生频率很低的时候 　　因此，ZK 提供了一种通过通知客户端感兴趣的具体时间来避免轮询造成的性能问题的方式，即设置 Watcher 的方式。通过设置 Watcher，ZK 客户端可以对指定的 znode 注册一个通知请求，在 znode 发生变化时收到一个单次的通知。例如，在 znode 被删除时向 Watcher 发送节点被删除的通知 　　应用 ZK Watcher 的代码通常遵循如下的框架 　　zk.exists("myZnode", myWatcher, existsCallback, null); 　　Watcher myWatcher new Watcher() { 　　public void process(WatchedEvent event) { 　　// process the watch event 　　} 　　} 　　StatCallback existsCallback = new StatCallback() { 　　public void processResult(int rc, String path,

Kafka 作为一个流式数据平台，对开发者提供了三种客户端：生产者 / 消费者、连接器、流处理。本文着重分析这三种客户端的线程模型。看到最后的通常都有惊喜。 消费者的线程模型 0.8 版本以前的消费者客户端会创建一个基于 ZK 的消费者连接器，一个消费者客户端是一个 Java 进程，消费者可以订阅多个主题，每个主题也可以多个线程。为了让消息在多个节点被分布式地消费，提高消息处理的吞吐量，Kafka 允许多个消费者订阅同一个主题，这些消费者需要满足“一个分区只能被一个消费者中的一个线程处理”的限制条件。通常，我们会将同一份相同业务处理逻辑的应用程序部署在不同机器上，并且指定一个消费组编号。当不同机器上的消费者进程启动后，所有这些消费者进程就组成了一个逻辑意义上的消费组。 消费组中的消费者数量是动态变化的，当有新消费者加入消费组，或者旧消费者离开消费组，都会触发基于 ZK 的消费组“再平衡”操作。当“再平衡”操作发生时，每个消费者都会在客户端执行分区分配算法，然后从全局的分配结果中获取属于自己的分区。它的缺点是消费者会和 ZK 产生频繁的交互，造成 ZK 集群的压力过大，并且容易产生羊群效应和脑裂等问题。 在 0.8 版本以后，Kafka 重新设计了客户端，并且引入了“协调者”和“消费组管理协议”。新的消费者将“消费组管理协议”和“分区分配策略”进行了分离。协调者负责消费组的管理

环境： dubbo 2.5.3 ZooKeeper 3.4.11 docker容器 异常： Forbid consumer 10.233.102.178 access service io.newbanker.modules.sys.service.ExhibitionCenterConfigService from registry zk-0:2181 use dubbo version 2.5.3, Please check registry access list (whitelist/blacklist). 源码分析： https://my.oschina.net/grindwheel/blog/522932 (其实并没有解决，只是分析问题原因。) 排查思路： 1、首先在ZooKeeper注册中心上，查看providers是否存在： 如果不存在，则说明providers未成功注册。则转到第2条。 2、查看docker容器中，providers程序是否运行正常。 如果运行不正常：则问题在dubbo providers服务。查看provider日志、重启等操作。 如果运行正常： 【前提：一段时间后，重试仍然报错 （排除provider侧因网络抖动等原因，出现和注册中心断开的情况） 】 0.最基本的：这种情况是consumer端找不到提供者，检查注册中心环境，consumer

zookeeper 简介 Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。 zookeeper 单机使用 访问http://zookeeper.apache.org/releases.html 并下载最新版本的ZooKeeper，这里我使用的版本是3.4.8。 下载完成后解压缩。进入conf目录，创建zoo.cfg配置文件(可复制已有的zoo_sample.cfg修改)。 tickTime=2000 initLimit=10 syncLimit=5 dataDir=/tmp/zookeeper clientPort=2181 说明一下几个配置项的意义(initLimit和syncLimit暂时先不管，后面有说明)： tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。 dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。 clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口

大型分布式系统原理概述 分布式系统三要素 ​ CPU:处理器 ​ Memory:内存 ​ IO:外存 ​ MultiCore:多核心 ​ LocalDisk:本地磁盘 ​ Networker:网络，网络存储 ​ RDMA:远程内存直接访问 ​ NUMA:分布式系统CPU和内存进行整合，对内存进行捆绑，是硬件层级的，（相似与ThreadLocal,将数据和实时运行线程绑定到一起），网卡直接绕过CPU共享内存，速度非常快 ​ 分布式系统三要素的进化 ​ 桌面级八核心十六线程CPU于2014年诞生，2015年Intel预计发布18核心桌面级CPU ​ NUMA在大中型系统上一直非常盛行，NUMA能很好提升系统吞吐能力，特别对于Java以及数据这样占用大内存的系统，但一直以来没有得到 DBA 们足够的重视、 Java领域也很少有人研究 ​ RDMA（远程内存直接访问，网络传输协议，类似TCP,更低延迟）是超高性能计算UHPC的重要基础之一，而Direct Socket Protocol （SDP）作为RDMA的传输协议已经在很多关键领域取代了TCP，Java7也正式开始支持SDP，跨入了UHPC的领地。 ​ IO方面，万兆网正在崛起，万兆网的ISCSI存储， 单通道可达到500MB/s， 每秒500,000个IO能力，而目前主流的SSD硬盘的速度是400-550MB/s。 ​ ===

session会话机制 client请求和服务端建立连接,服务端会保留和标记当前client的session,包含 session过期时间,sessionId ,然后服务端开始在session过期时间的基础上倒计时,在这段时间内,client需要向server发送心跳包,目的是然server重置session过期时间 使用quit命令,退出可端,但是server端的session不会立即消失,使用ls / 依然可以看到创建的临时节点 节点的类型: 持久节点,不加任何参数,默认创建的是持久节点 临时节点: 当客户端断开连接时,这个节点会消失 持久顺序节点: 父节点为他的第一级子节点维护一份时序,标记节点的创建顺序,这个标记其实就是一个数字后缀,作为新节点的名字,数字的范围就是整形的最大值(1024*1024) 临时顺序节点,同上. (临时节点不能再创建的节点) 创建节点时,可以指定每个节点的data信息,zookeeper默认每个节点的数量的最大上限是1M 常用命令 创建节点: 语法 : create /path data [zk: localhost:2181(CONNECTED) 2] create /changwu 1 Created /changwu [zk: localhost:2181(CONNECTED) 3] ls / [changwu, zookeeper]