zookeeper集群

Zookeeper 基础 由 xpproen 创建，youj 最后一次修改 2016-12-27 在深入了解ZooKeeper的运作之前，让我们来看看ZooKeeper的基本概念。我们将在本章中讨论以下主题： 1、Architecture（架构） 2、Hierarchical namespace（层次命名空间） 3、Session（会话） 4、Watches（监视） ZooKeeper的架构 看看下面的图表。它描述了ZooKeeper的“客户端-服务器架构”。 作为ZooKeeper架构的一部分的每个组件在下表中进行了说明。 部分 描述 Client（客户端） 客户端，我们的分布式应用集群中的一个节点，从服务器访问信息。对于特定的时间间隔，每个客户端向服务器发送消息以使服务器知道客户端是活跃的。 类似地，当客户端连接时，服务器发送确认码。如果连接的服务器没有响应，客户端会自动将消息重定向到另一个服务器。 Server（服务器） 服务器，我们的ZooKeeper总体中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。 Ensemble ZooKeeper服务器组。形成ensemble所需的最小节点数为3。 Leader 服务器节点，如果任何连接的节点失败，则执行自动恢复。Leader在服务启动时被选举。 Follower 跟随leader指令的服务器节点。

认识Zookeeper zookeeper是什么 分布式数据的一致性解决方案. Zookeeper 能做什么 数据发布和订阅(配置中心，config,disconf,diamond,appollo) 负载均衡 dubbo利用zookeeper的机制实现负载均衡。 命名服务 master选举 分布式锁 分布式队列 Zookeeper特征 顺序一致性 : 从同一个客户端发起事务请求，最终会严格按照顺序被应用zookeeper中。 原子性 : 所有的事务请求处理的结果在整个集群中的所有机器上的应用情况都是一致的。 可靠性 ：一旦服务器成功应用某个事务，并且对客户端做出响应，那么这个数据在整个集群中一定是同并且保留下来 实时性 : 一旦一个事务被成功应用，客户端就能够立即从服务端读取到事务变更后的最新的数据状态(近实时) 如何安装Zookeeper 一、 https://archive.apache.org/dist/zookeeper / 选择需要下载zk版本 windows安装 必须先安装jdk https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_systemReq 查看zk和jdk兼容性 把下载好的zk.xxx.gz包解压到本地 找到conf/zoo_sample.cfg文件复制改为zoo.cfg 编辑zoo

ookeeper与Eureka区别 CPA理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。 Consistency(一致性), 数据一致更新，所有数据变动都是同步的 Availability(可用性), 好的响应性能 Partition tolerance(分区容忍性) 可靠性 1、“C”是指一致性，即当一个Process（过程）修改了某个数据后，其他Process读取这是数据是，得到的是更新后的数据，但并不是所有系统都 可以做到这一点。例如，在一些并非严格要求一致性的系统中，后来的Process得到的数据可能还是修改之前的数据，或者需要等待一定时间后才能得到修改 之后的数据，这被成为“弱一致性”，最经典的应用就是DNS系统。当用户修改了DNS配置后，往往不会马上在全网更新，必定会有一个延迟，这个延迟被称为 “不一致窗口”，它的长度取决于系统的负载、冗余的个数等因素。但对于某些系统而言，一旦写入，后面读取的一定是修改后的数据，如银行账户信息，这被称为 “强一致性”。 2、“A”是指可用性。即系统总是能够为用户提供连续的服务能力。当用户发出请求是，系统能给出响应（成功或者失败），而且是立即给出响应

1，Eureka 闭源了，但是我们可以通过zookeeper实现注册中心的功能。 zookeeper 是一个分布式协调工具，可以实现服务的注册和发现，配置中心，注册中心，消息中间件的功能 2，工具准备 windows 版本的zookeeper-3.3.6,以及客户端查看工具ZooInspector 3，打开zookeeper 服务 4，配置需要注册到zookeeper 上的服务,maven 依赖 member 服务： ###订单服务的端口号 server: port: 8000 ###服务别名----服务注册到注册中心名称 spring: application: name: zk-member cloud: zookeeper: connect-string: 127.0.0.1:2181 order服务： ###订单服务的端口号 server: port: 8001 ###服务别名----服务注册到注册中心名称 spring: application: name: zk-order cloud: zookeeper: connect-string: 127.0.0.1:2181 启动类上加上注解：@SpringBootApplication 代表如果注册中心不是Eureka 的，比如consul,zookeepr 或者其他，可以用这个去注册，（springboot2.0

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

为什么要有Zookeeper？ 电视里经常会有一些狗血的设定，队长和副队长一起出去执行任务，执行完任务后副队长回来报到了，但是队长可能因为天气原因导致航班延期了，暂时回不来，这个时候副队长左等右等还等不到队长回来，而且副队长担心队长如果出事了，下面的队员没有人约束，大家可能就会松懈下来，副队长等了一个星期后，自己当队长了。 结果过了两个星期后，队长回来了，这个时候就产生了连个队长，这个时候组员就麻烦了，他们 不知道听谁 的，假设 也有可能写一份报告时，都给两位 队长。 这里面如果还有一个支援保障小队，发现队长还没回来啊，那么这个支援保障小队就去查队长是不是遇到什么事了，结果一查，队长没出事，平安大吉，那么支援保障小队就告诉副队长，你不用担心了，他没事，我们会告知委员会，委员会会选举出一个队长，选到你了会正式通知你的。 什么是Zookeeper？ Zookeeper是一个Apache下的开源分布式协调框架，就是为分布式应用提供协调服务的。 Zookeeper从设计模式的角度来理解，是一个基于观察者模式设计的分布式服务管理框架，负责存储和管理都关心的数据(状态)，然后接受观察者的注册，一旦这些数据的状态发生了变化，Zookeeper就通知已经在Zookeeper上注册的那些观察者这做出相应的反应，从而实现集群中类似Master/Slave管理模式。 特点 1

最近在研究分布式系统的一些理论概念，例如关于分布式系统一致性的讨论，看了一些文章我有一些不解。大多数对分布式系统一致性的划分是将其分为三类：强一致性，顺序一致性以及弱一致性。强一致性（Strict Consistency）也称为：原子一致性（Atomic Consistency）、线性一致性（Linearizable Consistency）。 在谈到Zookeeper的一致性是哪种级别的一致性问题，以及CAP原则中的C是哪一种一致性级别时有些疑惑。 下面是大多数文章中提到的一致性级别 1. 一致性（Consistency） 一致性（Consistency）是指多副本（Replications）问题中的数据一致性。可以分为强一致性、顺序一致性与弱一致性。 1.1 强一致性（Strict Consistency） 也称为： 原子一致性（Atomic Consistency） 线性一致性（Linearizable Consistency） 强一致性有两个要求： 任何一次读都能读到某个数据的最近一次写的数据。 系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。 简言之，在任意时刻，所有节点中的数据都是一样的。 例如，对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。 1.2 顺序一致性（Sequential Consistency） the result

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介：郑志彬，毕业于华南理工大学计算机科学与技术（双语班）。先后从事过电子商务、开放平台、移动浏览器、推荐广告和大数据、人工智能等相关开发和架构。目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务。擅长各种业务形态的业务架构、平台化以及各种业务解决方案。 博客地址： http://arganzheng.life 。 背景 最近要把原来做的那套集中式日志监控系统进行迁移，原来的实现方案是: Log Agent => Log Server => ElasticSearch => Kibana，其中Log Agent和Log Server之间走的是Thrift RPC，自己实现了一个简单的负载均衡(WRB)。 原来的方案其实运行的挺好的，异步化Agent对应用性能基本没有影响。支持我们这个每天几千万PV的应用一点压力都没有。不过有个缺点就是如果错误日志暴增，Log Server这块处理不过来，会导致消息丢失。当然我们量级没有达到这个程度，而且也是可以通过引入队列缓冲一下处理。不过现在综合考虑，其实直接使用消息队列会更简单。PRC，负载均衡，负载缓冲都内建实现了。另一种方式是直接读取日志，类似于logstash或者flume的方式

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介：郑志彬，毕业于华南理工大学计算机科学与技术（双语班）。先后从事过电子商务、开放平台、移动浏览器、推荐广告和大数据、人工智能等相关开发和架构。目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务。擅长各种业务形态的业务架构、平台化以及各种业务解决方案。 博客地址： http://arganzheng.life 。 背景 最近要把原来做的那套集中式日志监控系统进行迁移，原来的实现方案是: Log Agent => Log Server => ElasticSearch => Kibana，其中Log Agent和Log Server之间走的是Thrift RPC，自己实现了一个简单的负载均衡(WRB)。 原来的方案其实运行的挺好的，异步化Agent对应用性能基本没有影响。支持我们这个每天几千万PV的应用一点压力都没有。不过有个缺点就是如果错误日志暴增，Log Server这块处理不过来，会导致消息丢失。当然我们量级没有达到这个程度，而且也是可以通过引入队列缓冲一下处理。不过现在综合考虑，其实直接使用消息队列会更简单。PRC，负载均衡，负载缓冲都内建实现了。另一种方式是直接读取日志，类似于logstash或者flume的方式

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