zookeeper集群

zookeeper 中间件，提供协调服务 作用分布式系统 特性 数据一致性，数据按照顺序分批入库 原子性：事务要么成功要么失败，不会局部化 单一视图：客户端连接集群中的任一zk节点，数据是一致的。 可靠性 每次对zk的操作状态保存在服务端 实时性 客户端可以读取zk服务端的最新数据 jdk 与 zookeeper 的安装 cd jdk8 pwd /usr/jdk8 vi /etc/profile 1 export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL 2 export JAVA_HOME=/usr/jdk8 3 export ZOOKEEPER_HOME=/usr/local/zookeeper 4 export CLASSPATH=.:JAVA_HOME%lib/dt.jar:%JAVA_HOME%/lib/tools.jar 5 #export PATH=$PATH:$JAVA_HOME/bin 6 export PATH=$PATH:$ZOOKEEPER_HOME/bin:$JAVA_HOME/bin 刷新配置文件 source /etc/profile 目录结构 bin 主要运行命令 conf 存放配置文件 contrib 附加一些功能 dist-maven mvn编译后的目录 docs 文档 lib

kafka下载： http://kafka.apache.org/downloads 版本： kafka_2.11-1.1.1.tgz 解压： tar -zxvf kafka_2.11-1.1.1.tgz -C /opt/install [root@hadoop002 kafka_2.11-1.1.1]# cd config/ 修改配置 : 参数说明： dataDir顾名思义就是zookeeper保存数据的目录,默认情况下zookeeper将写数据的日志文件也保存在这个目录里； clientPort这个端口就是客户端连接Zookeeper服务器的端口,Zookeeper会监听这个端口接受客户端的访问请求； server.A=B:C:D中的A是一个数字,表示这个是第几号服务器,B是这个服务器的IP地址，C第一个端口用来集群成员的信息交换,表示这个服务器与集群中的leader服务器交换信息的端口，D是在leader挂掉时专门用来进行选举leader所用的端口。 vi zookeeper.properties ########### clouster config ######################## 3 server.1= 192.168.25.143:2888:3888 server.2= 192.168.25.144:2888:3888 server.3= 192

Redis数据量日益增大，使用的公司越来越多，不仅用于做缓存，同时趋向于存储这一块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，保证单实例内存增大带来的一系列问题，下面所列出的codis方案目前正在不断测试过程中，测试过程没有展示出来，主要从以下几点出发。 测试架构 和性能 ： 　　1、keepalived+haproxy故障测试 　　2、Zookeeper集群节点测试 　　3、Codis-proxy集群节点测试 　　4、Codis-server集群节点测试 　　5、脚本写入大量测试数据并模拟数据迁移 　　6、性能测试 下面具体介绍codis和其他几大集群方案 集群方案： 　　1、 主从高可用（该方案就是单实例形式，只是为了保证数据的安全，对于用户数据少，业务的前期可以采用，目前我司缓存架构就是采用该方案） 　　2、 客户端分片（典型代表：Jedis。自主写分片算法，代码掌握在自己手中，可控性强，但是需要专业的开发运维人员维护，技术要求和维护成本高） 　　3、代理分片（典型代表：Twemproxy，redis集群没有正式推出之前官网推荐的方案，也是目前使用最多的） 　　4、 Redis cluster（3版本推出的集群方案，历时四年之多的开发） 　　5、 Codis集群（豌豆荚15年开源的解决方案

ZooKeeper 提供了分布式数据的发布/订阅功能, 在 ZooKeeper 中引入了 Watcher 机制来实现这种分布式的通知功能. ZooKeeper 允许客户端向服务端注册一个 Watcher 监听, 当服务器的一些特定事件触发了这个 Watcher, 就会向指定客户端发送一个事件通知. ZooKeeper 的 Watcher 机制主要包括客户端线程, 客户端 WatchManager 和 ZooKeeper 服务器三部分. ZooKeeper服务器: 部署在远程主机上的 ZooKeeper 单机或集群 Client 客户端: 分布在各处的 ZooKeeper jar 包, 被引用在各个独立应用程序中. WatchManager: 一个接口, 用于管理各个监听器, 只有一个方法 materialize() 返回一个 Watcher 的 set. 在具体流程上, 客户端编写一个类实现 Watcher 接口, 向 ZooKeeper 服务器注册这个 Watcher 实例的同时会将实例存储在客户端的 WatchManager 中, 当ZooKeeper 服务器触发 Watcher 事件后, 会向客户端发送通知, 客户端线程从 WatchManager 的实现类中取出对应的 Watcher 对象来执行回调逻辑. 工作机制 ZooKeeper 的 Watcher 机制分为三个过程:

文章目录 一、kafka介绍 1. kafka基本认识 1.1 kafka 4个核心API 2. 各版本变化说明 2.1 不同 Kafka 版本之间服务器和客户端的适配性 二、kafka入门 1. kafka基本术语概念 2. kafka消息设计 2.1 消息压缩 三、kafka connect 1. Kafka Connect的应用 2. Kafka Connect 组件的启动脚本 四、 Kafka Streams 1. 什么是流式计算 2. 关键概念 五、kafka环境搭建 六、kafka基本使用 1. kafka常用命令 2. 命令使用问题总结 1）报错：Error while fetching metadata with correlation id 2）消费消息报错zookeeper is not a recognized option 六、关于Kafka Consumer 1. push 还是 pull 2. Kafka重复消费原因 2.1 kafka重复消费解决方案 2.2 具体案例 七、关于Kafka 拦截器 1. 生产者拦截器 2. 消费者拦截器 八、常见问题整理 1. 消息丢失问题 2. kafka如何建立tcp连接 2.1 生产者代码是什么时候创建 TCP 连接的？ 2.2 生产者何时关闭 TCP 连接？ 2.3 消费者代码是什么时候创建 TCP 连接的？ 2

helm镜像库配置 helm repo add stable http://mirror.azure.cn/kubernetes/charts helm repo add incubator http://mirror.azure.cn/kubernetes/charts-incubator helm repo list NAME URL stable http://mirror.azure.cn/kubernetes/charts local http://127.0.0.1:8879/charts incubator http://mirror.azure.cn/kubernetes/charts-incubator 创建Kafka和Zookeeper的Local PV 创建Kafka的Local PV 这里的部署环境是本地的测试环境，存储选择Local Persistence Volumes。首先，在k8s集群上创建本地存储的StorageClass local-storage.yaml ： apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode:

zookeeper： zookeeper是基于paxos的简化版zab，我觉得确实很难理解?，以前看了好多遍《从paxos到zookeper》才感觉似懂非懂了，然而过了几个月发现又一脸蒙蔽了，在这里在整理一下（仅表示我自己的理解） ZAB协议中存在着三种状态，每个节点都属于以下三种中的一种： 1. Looking ：系统刚启动时或者Leader崩溃后正处于选举状态 2. Following ：Follower节点所处的状态，Follower与Leader处于数据同步阶段； 3. Leading ：Leader所处状态，当前集群中有一个Leader为主进程； 在开始时，所有的节点都是looking状态并且每个节点都希望自己能成为leader节点，所有每个节点都会向集群中发送一个提案内容是选取自己作为leader节点，提案编号是ZXID (ZAB协议中使用ZXID作为事务编号，ZXID为64位数字，低32位为一个递增的计数器，每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1，高32位为Leader周期epoch编号，当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch，将低32位从0开始生成新的ZXID；ZAB使用epoch来区分不同的Leader周期)

一、什么是ZooKeeper？ ZooKeeper（动物园管理员），顾名思义，是用来管理Hadoop（大象）、Hive（蜜蜂）、Pig（小猪）的管理员，同时Apache HBase、Apache Solr、LinkedIn Sensei等众多项目中都采用了ZooKeeper。 ZooKeeper是一个集中式服务，用于维护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都以某种形式被分布式应用进程使用。每次它们被实现时，都有大量的工作用于修复不可避免的bug和竞选条件。由于实现这类服务的困难，应用进程最初通常跳过它们，这使得它们在存在更改时变得脆弱，并且难以管理。即使正确完成，这些服务的不同实现也会在部署应用进程时导致管理复杂性。 二、Zookeeper集群 Kafka使用Zookeeper来存储集群元数据以及消费者元数据。Zookeeper集群被称为群组。Zookeeper使用的是一致性协议，所以建议每个群组里应该包含奇数个节点（比如3个、5个等），因为只有当群组里的大多数节点（也就是法定人数）处于可用状态，Zookeeper才能处理外部的请求。也就是说，如果3个节点的集群，允许1个节点失效。如果5个节点的集群，允许2个节点失效。 三、Docker方式配置ZooKeeper myid文档：标识要写到快照目录下面myid文档里 采用Docker镜像

ubbo管理控制台安装及集成zookeeper集群部署 dubbo管理控制台开源部分主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。 1、下载dubbo 地址： http://code.alibabatech.com/mvn/releases/com/alibaba/dubbo-admin/2.4.1/dubbo-admin-2.4.1.war 本人将tomcat安装在/opt/目录下，先删除tomcat/webapps下自带的ROOT文件夹，将下载的war包解压到webapps/ROOT，命令如下： [plain] view plaincopy unzip dubbo-admin-2.4.1.war -d /opt/apache-tomcat-6.0.37/webapps/ROOT 配置: (或将dubbo.properties放在当前用户目录下) [plain] view plaincopy vim webapps/ROOT/WEB-INF/dubbo.properties 配置信息如下： dubbo.registry.address= zookeeper://127.0.0.1:2181 dubbo.admin.root.password=root dubbo.admin.guest.password=guest

DUBBO原理、应用与面经总结 SPI 你是否了解SPI，讲一讲什么是SPI，为什么要使用SPI? SPI具体约定： 当服务的提供者，提供了服务接口的一种实现之后，在jar包的 META-INF/services/ 目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包 META-INF/services/ 里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入（ 从使用层面来说，就是运行时，动态给接口添加实现类 ）。 基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定（不需要在代码里写死）。 这样做的好处： java设计出SPI目的是为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。这样程序运行的时候，该机制就会为某个接口寻找服务的实现，有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。例如，JDBC驱动，可以加载MySQL、Oracle、或者SQL Server等，目前有不少框架用它来做服务的扩张发现。 回答这个问题可以延伸一下和API的对比，API是将方法封装起来给调用者使用的，SPI是给扩展者使用的。 Dubbo的SPI和JDK的SPI有区别吗？有的话，究竟有什么区别？ Dubbo 的扩展点加载是基于JDK 标准的