zkclient

最近的项目还是用的老的kafka版本（0.8），用spark 接数据的时候，如果spark 程序意外重启，重启时间内的kafka数据会丢失。我们需要实现最少消费一次，数据重复没有关系。但不能允许丢失数据。 在 Spark Streaming 中消费 Kafka 数据的时候，有两种方式分别是 1）基于 Receiver-based 的 createStream 方法和 2）Direct Approach (No Receivers) 方式的 createDirectStream 方法， 在生产上我们首先用第一种方式，发现性能有很多损耗，而且也不稳定，所以我们后来使用的是第2种方式。我们把kafka 的offset 保存在zookeeper中，实际测试发现zookeeper保存offset效率还不错，下面是具体代码修改记录, 供参考： val topics = Set[String](kafkaInputTopic) val kafkaParams = Map[String, String]( "metadata.broker.list" -> destBrokerHost, "serializer.class" -> "kafka.serializer.StringEncoder", "group.id" -> kafkaGroup) var offsetRanges = Array

在处理生产环境问题的过程中发现12号那天某kafka集群有少量的数据丢失，概率大致在千万分之三。 数据写入kafka之后，就完全消失了，消费者完全没有消费到这个数据。 通过找到那天的数据，查看有问题的数据在写入kafka的时候上下文应用日志发现有少量以下报错: [2019-10-12 11:03:43,xxx] This is not the correct coordinator. 理论上正常情况下kafka是不太可能丢数据的，如果出现这种情况，必然是开发人员或者硬件引发了什么问题，因为写入日志是有的，看了下应用配置 acks=1 马上意识到，问题突破口应该在这里。 acks=0 生产者能够通过网络吧消息发送出去，那么就认为消息已成功写入Kafka,一定会丢失一些数据 acks=1 master在疏导消息并把它写到分区数据问津是会返回确认或者错误响应，还是可能会丢数据 acks=all master在返回确认或错误响应之前，会等待所有同步副本都收到消息 可能以前是为了保证性能够快，选择了折中的应用配置 acks=1 。 马上想到去看下kafka的日志，猜测这个时间段必然出现出现了 master 不可用的情况才会导致数据丢失。 在kafka集群的57号节点的机器上看到这样一段日志： [2019-10-12 11:03:39,427] WARN Client session

一、前述 Dubbo是一种提供高性能,透明化的RPC框架.是阿里开源的一个框架。 官网地址：http://dubbo.io/ 二、架构 组件解释： Provider: 提供者.发布服务的项目. Registry: 注册中心.所有提供者必须去注册中心注册自己所有能发布的服务. Consumer: 消费者.调用服务的项目. Monitor: 监控中心.监控消费者和提供者调用服务的时间及次数.默认每1分钟向监控中心生成一次统计数据.之间调用必须遵守Dubbo支持的协议. Container: 容器.Dubbo依赖于Spring容器. 执行顺序： 0:由Spring容器启动服务. 1 向注册中心注册服务. 2 消费者向注册中心订阅需要调用的服务.在注册中心的服务列表中寻找需要调用的服务.获取到提供者真实地址. 3 注册中心通知消费提供者的真实地址.如果提供者的服务发生变化,注册中心会自动推送信息给消费者. 4 消费者调用提供者的服务. 5 在调用过程中向监控中心发送数据,进行统计调用时间和调用次数. 6 虚线都是异步请求,实线都是同步请求. 三、Dubbo支持的注册中心 1.Zookeeper注册中心 1.1 优点:支持集群. 1.2 缺点:稳定性受Zookeeper影响. 2.Redis注册中心 1.1 优点:基于服务器双写模式.性能高. 1.2 缺点:要求服务器时间必须一致. 3

包含时间顺序的ID 此场景最简单的实现方案，就是采用 twitter 的 Snowflake 算法。 ID总长64位，第1位不可用，41位表示时间戳，10位表示生成机器的id，后12位表示序列号。 为什么第一位不可用？第一位为0，可以确保ID在java的long类型数据一直为正整数递增 同一时间戳即毫秒内，能产生多少个ID？ 2^12 = 4096 个ID [ 0 ~ 4095 ] 唯一性？通过机器ID预先已经做了一次空间隔离，再通过时间戳做了一次时间隔离，最后通过时间戳内的计数实现了一定程度内的唯一 高性能？可以通过增加IDWorker来缓解高并发时的单机负载压力 缺点？时间受限，41位可以表示69年（不过可以减少机器位来增加时间位数） 自增序列 原理 根据key获取分布式锁，获得锁后取得序号，并偏移配置的偏移量，替换原先的序号，最后释放锁。 基于zookeeper实现 基于zookeeper可以很快实现自增序列服务，引入apache的curator封装的zookeeper客户端。 1 2 3 4 <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> </dependency> 建立zookeeper连接，打开zkclient后，如果重复会使用

基于1.1.5-alpha版本，具体源码笔记可以参考我的github：https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 本文将对canal的启动模块deployer进行分析。 Deployer模块(绿色部分)在整个系统中的角色如下图所示，用来启动canal-server. 模块内的类如下： 为了能带着目的看源码，以几个问题开头，带着问题来一起探索deployer模块的源码。 CanalServer启动过程中配置如何加载？ CanalServer启动过程中涉及哪些组件？ 集群模式的canalServer，是如何实现instance的HA呢？ 每个canalServer又是怎么获取admin上的配置变更呢？ 1.入口类CanalLauncher 这个类是整个canal-server的入口类。负责配置加载和启动canal-server。 主流程如下： 加载canal.properties的配置内容 根据canal.admin.manager是否为空判断是否是admin控制,如果不是admin控制，就直接根据canal.properties的配置来了 如果是admin控制，使用PlainCanalConfigClient获取远程配置

基于1.1.5-alpha版本，具体源码笔记可以参考我的github： https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 本文将对canal的启动模块deployer进行分析。 Deployer模块(绿色部分)在整个系统中的角色如下图所示，用来启动canal-server. 模块内的类如下： 为了能带着目的看源码，以几个问题开头，带着问题来一起探索deployer模块的源码。 CanalServer启动过程中配置如何加载？ CanalServer启动过程中涉及哪些组件？ 集群模式的canalServer，是如何实现instance的HA呢？ 每个canalServer又是怎么获取admin上的配置变更呢？ 1.入口类CanalLauncher 这个类是整个canal-server的入口类。负责配置加载和启动canal-server。 主流程如下： 加载canal.properties的配置内容 根据canal.admin.manager是否为空判断是否是admin控制,如果不是admin控制，就直接根据canal.properties的配置来了 如果是admin控制，使用PlainCanalConfigClient获取远程配置

zk实现分布式锁纵观网络各种各样的帖子层出不穷，笔者查阅很多资料发现一个问题，有些文章只写原理并没有具体实现，有些文章虽然写了实现但是并不全面 借这个周末给大家做一个总结，代码拿来就可以用并且每一种实现都经过了测试没有bug。下面我们先从最简单的实现开始介绍： 简单的实现 package com.srr.lock; /** * @Description 分布式锁的接口 */ abstract public interface DistributedLock { /** * 获取锁 */ boolean lock(); /** * 解锁 */ void unlock(); abstract boolean readLock(); abstract boolean writeLock(); } package com.srr.lock; /** * 简单的zk分布式做实现策略 * 性能比较低会导致羊群效应 */ public abstract class SimplerZKLockStrategy implements DistributedLock{ /** * 模板方法，搭建的获取锁的框架，具体逻辑交于子类实现 * @throws Exception */ @Override public boolean lock() { // 获取锁成功 if (tryLock()){

创作不易，如果觉得这篇文章对你有帮助，欢迎各位老铁点个赞呗，您的支持是我创作的最大动力！ 本系列主要总结下Zookeeper的基础使用，笔者准备写四篇文章： 博文内容 资源链接 Linux下搭建Zookeeper运行环境 https://blog.csdn.net/smilehappiness/article/details/105933433 Zookeeper入门，一篇就够啦 https://blog.csdn.net/smilehappiness/article/details/105933292 Zookeeper客户端ZkClient、Curator的使用，史上最详细的教程来啦~ https://blog.csdn.net/smilehappiness/article/details/105938058 Zookeeper使用总结（进阶篇） https://blog.csdn.net/smilehappiness/article/details/105938119 文章目录 前言 1 初识Zookeeper 2 Zookeeper运行环境 3 zoo.cfg配置文件详解 4 Zookeeper数据结构 5 Zookeeper客户端 5.1 图形界面客户端 5.2 命令行客户端 前言 本文主要介绍Zookeeper的一些概念，以及通过命令行的方式

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

教学视频 源码 - - - 01.课程介绍 02.概述 03.特点 04.数据结构 05.应用场景 06.下载地址 07.本地模式安装 08.配置参数解读 09.选举机制 10.节点类型 11.分布式安装 12.Shell命令操作 13.Stat结构体 14.监听器原理 15.写数据流程 16.创建ZooKeeper客户端 17.创建一个节点 18.获取子节点并监听节点变化 19.判断节点是否存在 20.服务器节点动态上下线案例分析 21.服务器节点动态上下线案例注册代码 22.服务器节点动态上下线案例全部代码实现 23.企业面试真题 - 01.课程介绍 ZooKeeper官网 ZooKeeper 3.4 Documentation 02.概述 Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的 Apache 项目。 ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by