zookeeper集群

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的 CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中， Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。 针对分布式锁的实现，目前比较常用的有以下几种方案： 基于数据库实现分布式锁 基于缓存（ redis，memcached，tair）实现分布式锁 基于Zookeeper实现分布式锁 在分析这几种实现方案之前我们先来想一下，我们需要的分布式锁应该是怎么样的？（这里以方法锁为例，资源锁同理） 可以保证在分布式部署的应用集群中

在分布式系统领域有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个） eureka : 　 cap ：实现了AP 　 服务注册 ：客户端和服务端在eureka中注册，采用心跳机制，在出现网络故障时，大批量注册的服务，会被检测到不可用，此时eureka注册的服务节点会处于“自我保护模式”，同时eureka会保存这些节点的注册信息，当网络恢复后，服务节点会退出“自我保护模式”，Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。 　 客户端缓存 ：当eureka所有节点都不能正常使用时，客户端也可以通过缓存的服务注册信息，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息。 　 架构设计 ：Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能，Eureka提供了一个web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供了Restful-API接口，方便第三方程序集成Eureka的功能。 zookeeper

1.ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。 Zookeeper保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理 。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。 Zookeeper提供了文件系统和通知机制。Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是

1 Hadoop HA架构详解 1.1 HDFS HA背景 HDFS集群中NameNode 存在单点故障（SPOF）。对于只有一个NameNode的集群，如果NameNode机器出现意外情况，将导致整个集群无法使用，直到NameNode 重新启动。 影响HDFS集群不可用主要包括以下两种情况：一是NameNode机器宕机，将导致集群不可用，重启NameNode之后才可使用；二是计划内的NameNode节点软件或硬件升级，导致集群在短时间内不可用。 为了解决上述问题，Hadoop给出了HDFS的高可用HA方案：HDFS通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。 1.2 HDFS HA架构 一个典型的HA集群，NameNode会被配置在两台独立的机器上，在任何时间上，一个NameNode处于活动状态，而另一个NameNode处于备份状态，活动状态的NameNode会响应集群中所有的客户端，备份状态的NameNode只是作为一个副本，保证在必要的时候提供一个快速的转移。 为了让Standby Node与Active Node保持同步

部署参考 https://yq.aliyun.com/articles/662422 https://www.baidu.com/link?url=4-82ARHt_56IJ34QcMhx9zmRvZPviwtaZrRLM-SI1m3BIFDD_2gzyasBaVTPmst2&wd=&eqid=f116d2da000ca2d4000000065da2ef60 排错参考 https://blog.csdn.net/lll0101/article/details/95448420 配置 java 环境 # 下载相应的 jdk 软件包，然后解压安装，我这里包名称为： jdk-8u91-linux-x64.tar.gz tar -xzf jdk-8u91-linux-x64.tar.gz ; mkdir -p /usr/java/ ; mv jdk1.8.0_25/ /usr/java/jdk1.8 # 然后配置环境变量，这样可以任何地方引用 jdk ，如下配置： #vi /etc/profile 最后面加入以下语句： export JAVA_HOME=/usr/java/jdk1.8 export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre

自从接触Docker，便对它产生了浓厚兴趣，平时需要的开发环境也尝试使用Docker来搭建，相比较虚拟机确实方便了不少，这里主要记录一下平时在开发中使用Docker搭建过得开发环境。这里所有使用docker创建的应用都放在了dockerapps目录下。 版本：3.5 1.1 单节点部署 在dockerapps下创建zookeeper目录。此目录包含data目录用来持久化zookeeper应用数据，包含一个zoo.cfg配置文件用来配置zookeeper应用，包含一个start.sh用来启动单节点的zk。目录结构如下所示： 1234 zookeeper/├── data├── start.sh└── zoo.cfg 1.1.1 创建持久化数据目录data 在zookeeper目录下创建zk的数据持久化目录 1 mkdir data 1.1.2 创建zoo.cfg 配置文件 在zookeeper目录下创建zk的配置文件zoo.cfg，内容如下： 123 clientPort=2181dataDir=/datadataLogDir=/data/log 1.1.3 创建启动脚本start.sh 在zookeeper目录先创建zk的启动脚本start.sh，内容如下： 123 docker stop zookeeperdocker rm zookeeperdocker run -itd -p

一、安装多节点ZooKeeper集群 下面就是在本机一台机器上安装3个节点的ZooKeeper集群，在多台机器上安装的方法和一台机器上是一样的，就是配置文件有微小的调整。 1.下载ZooKeeper包 https://www-us.apache.org/dist/zookeeper/stable/ 下载带bin的tar.gz文件，目前是apache-zookeeper-3.5.6-bin.tar.gz 解压 tar -zxvf apache-zookeeper-3.5.6-bin.tar.gz 把解压文件移动到/usr/local sudo mv apache-zookeeper-3.5.6-bin /usr/local/ 2.创建配置文件 在ZooKeeper的conf目录下创建3个配置文件zoo1.cfg,zoo2.cfg,zoo3.cfg,如果是在多台服务器上安装ZooKeeper集群可以取相同的配置文件名字。 zoo1.cfg tickTime=2000 dataDir=/home/xl/zookeeper/data_logs/zookeeper1 clientPort=2181 initLimit=5 syncLimint=2 server.1=localhost:2888:3888 server.2=localhost:2889:3889 serve.3

Kafka 基本概述 什么是 Kafka Kafka 是一个分布式流式平台，它有三个关键能力 订阅发布记录流，它类似于企业中的 消息队列 或 企业消息传递系统 以容错的方式存储记录流 实时记录流 Kafka 的应用 作为消息系统 作为存储系统 作为流处理器 Kafka 可以建立流数据管道，可靠性的在系统或应用之间获取数据。 建立流式应用传输和响应数据。 Kafka 作为消息系统 Kafka 作为消息系统，它有三个基本组件 Producer : 发布消息的客户端 Broker：一个从生产者接受并存储消息的客户端 Consumer : 消费者从 Broker 中读取消息 在大型系统中，会需要和很多子系统做交互，也需要消息传递，在诸如此类系统中，你会找到源系统（消息发送方）和 目的系统（消息接收方）。为了在这样的消息系统中传输数据，你需要有合适的数据管道 这种数据的交互看起来就很混乱，如果我们使用消息传递系统，那么系统就会变得更加简单和整洁 Kafka 运行在一个或多个数据中心的服务器上作为集群运行 Kafka 集群存储消息记录的目录被称为 topics 每一条消息记录包含三个要素： 键（key）、值（value）、时间戳（Timestamp） 核心 API Kafka 有四个核心API，它们分别是 Producer API，它允许应用程序向一个或多个 topics 上发送消息记录

主机的IP地址： 主机IP地址 zookeeper kafka 10.19.85.149 myid=1 broker.id=1 10.19.15.103 myid=2 broker.id=2 10.19.189.221 myid=3 broker.id=3 配置文件： # cat zoo.cfg tickTime=2000 initLimit=10 syncLimit=5 dataDir=/data/zookeeper/data dataLogDir=/data/zookeeper/log clientPort=2181 server.1=10.19.85.149:2888:3888 server.2=10.19.15.103:2888:3888 server.3=10.19.189.221:2888:3888 #maxClientCnxns=60 #autopurge.snapRetainCount=3 #autopurge.purgeInterval=1 注释：2888表示zookeeper程序监听端口，3888表示zookeeper选举通信端口。 按照上述指定： echo 1 > /data/zookeeper/data/myid echo 2 > /data/zookeeper/data/myid echo 3 > /data/zookeeper/data/myid

ZooKeeper概述 　　ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比 如 分布式同步，配置管理，集群管理，命名管理，队列管理 。它被设计为易于编程，使用文 件系统目录树作为数据模型。服务端跑在 java 上，提供 java 和 C 的客户端 API 众所周知，协调服务非常容易出错，但是却很难恢复正常，例如，协调服务很容易处于 竞态以至于出现死锁。我们设计 ZooKeeper 的目的是为了减轻分布式应用程序所承担的协 调任务 ZooKeeper 是集群的管理者，监视着集群中各节点的状态，根据节点提交的反馈进行下 一步合理的操作。最终，将简单易用的接口和功能稳定，性能高效的系统提供给用户。 　　前面提到了那么多的服务，比如分布式锁、配置维护、组服务等，那它们是如何实现的呢，我相信这才是大家关心的东西。ZooKeeper在实现这些服务时，首先它设计一种新的 数据结构——Znode ，然后在该数据结构的基础上定义了一些 原语 ，也就是一些关于该数据结构的一些操作。有了这些数据结构和原语还不够，因为我们的ZooKeeper是工作在一个分布式的环境下，我们的服务是通过消息以网络的形式发送给我们的分布式应用程序，所以还需要一个 通知机制 —