zookeeper分布式锁

初始需求 元数据的存储（小数据） 分布式、高可用 读多写少、高性能读 有序访问 设计 单机层面 节点数据结构的选取 树结构，每个节点是一个ZNode 数据保存在内存中 优点：高效读写 为什么ZK不擅长存储大的数据？ 单机高效写磁盘 高效写磁盘的两种方式： 顺序写磁盘 预分配磁盘空间 ZK每次写磁盘，先申请固定大小的磁盘空间，之后再写磁盘，大大提升写入性能。 顺序写数据 每次写入操作，ZooKeeper会附加一个数字标签，表明ZooKeeper中的事务顺序 高可用、宕机可恢复 快照+事务日志 什么时候记录事务日志？ 如何快照？新起线程，不影响主流程 分布式层面 顺序写数据 一主多从结构，只有一台master服务器对外提供写服务，每次写记录ZXID事务Id。原子写，保证mei yo 如何保证数据强一致 写的策略，半数以上机器写成功后返回。 写数据流程，非Leader节点会把请求转发给leader，写成功后leader再通知该节点。 ZAB协议：初始阶段/宕机恢复（原子广播） 如何提高读的性能 follower节点，observer节点都可以对外提供读数据能力 怎么保证读取的强一致？ 客户端在调用前，可以先申请连接的主机同步leader数据，调用sync()方法 。 水平扩容 ZK做的不好的地方。 ZooKeeper 在水平扩容扩容方面做得并不十分完美，需要进行整个集群的重启

ZooKeeper 概述 Zookeeper 是一个分布式协调服务的开源框架。 主要用来解决分布式集群中 应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。 ZooKeeper 本质上是一个分布式的小文件存储系统。 提供基于类似于文件系 统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维 护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达 到基于数据的集群管理。 诸如： 统一命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。 2.1、zookeeper的架构图 Leader: Zookeeper 集群工作的核心 事务请求（写操作） 的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。 对于 create， setData， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。 Follower: 处理客户端非事务（读操作） 请求， 转发事务请求给 Leader； 参与集群 Leader 选举投票 2n-1台可以做集群投票。 此外，针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。 Observer: 观察者角色，观察

1. Zookeeper 概念简介： Zookeeper 是一个分布式 协调服务；就是为用户的分布式应用程序提供协调服务 A、zookeeper 是为别的分布式程序服务的 B、Zookeeper本身就是一个分布式程序 （只要有半数以上节点存活， zk 就能正常服务） C、Zookeeper 所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务…… D、 虽然说可以提供各种服务，但是 zookeeper 在底层其实只提供了两个功能： 管理 ( 存储，读取 ) 用户程序提交的数据； 并为用户程序提供数据节点监听服务； Zookeeper 集群的角色： Leader 和 follower （ Observer ） 只要集群中有半数以上节点存活，集群就能提供服务 zookeeper 集群机制 半数机制：集群中半数以上机器存活，集群可用。 zookeeper 适合装在 奇数台机器上！！！ 安装 1.虚拟机准备 安装到 3 台虚拟机上 安装好JDK 2. 解压 su – hadoop （切换到 hadoop 用户） tar -zxvf zookeeper-3.4.5.tar.gz（解压） 3. 修改环境变量 1 、 su – root( 切换用户到 root) 2 、 vi /etc/profile( 修改文件 ) 3 、添加内容： export

Zookeeper 是一个典型的 分布式数据一致性 的解决方案，是谷歌 Chubby 的开源实现，在分布式系统中有非常广泛的应用。 分布式应用程序可以基于它来实现 数据发布/订阅、分布式协调/通知、集群管理、Master 选举、命名服务、分布式锁和分布式队列 等功能。 在诸如 HDFS、Yarn、HBase、Kafka、Flink 等著名分布式系统中都使用 Zookeeper 来实现各自的 分布式协调机制 。 在大数据系统中， Zookeeper 是必不可少的组件 ，所有大数据平台上必定运行着一组 Zookeeper 服务器集群。 对于大部分业务开发人员来说，Zookeeper 是属于幕后默默干活奉献的角色，在开发过程中接触的往往都是基于 Zookeeper 的上层系统，这使得很多开发人员对 Zookeeper 处于一种 知道它很重要，但是对它缺不熟悉 的状态。 虽然在大部分工作中，开发人员并不需要完全了解 Zookeeper 是如何实现的，但是保持对这个重要组件的了解与探索能够在一定程度上 提升对现有分布式系统实现的理解 。 本文将会从 Zookeeper 的 基本概念 开始介绍，随后使用客户端API模拟了一个简单的 Master-Slaves 集群 中主从节点的行为，并在之后讨论到其 内部实现的机制与服务端相关的参数配置 ，为分布式系统应用揭开最后一层神秘的面纱。

参考地址： https://www.cnblogs.com/ultranms/p/9585191.html 在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。 配置管理 在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更

=======开篇吐槽：最近一段时间刚好碰上中秋国庆双节，而且工作任务繁重，基本很难保证有时间来写文章了======= 《可伸缩服务架构 框架与中间件》与《分布式服务架构 原理、设计与实战》是要配套捆绑着看，这营销手段，服。 这书主要介绍了在分布式系统中常规用到的一些框架组件，比如分布式ID、消息队列、缓存、RPC框架、ES等。书中大部分内容的作用更多的是整体介绍、知识点扩展、初步入门，书中贴的源代码其中很难让人认真一行一行去阅读学习。想要更深入的学习，需要在平时工作多积累丰富的项目经验，或者多看看开源项目，从而去总结和提取。 每一章介绍一个组件，摘抄一些自己觉得有用的内容，归纳整理，然后加以理解。（主要还是强迫自己形成总结成文的习惯，看的书很多，都总是很容易忘记，效果甚微） 第1章 如何设计一款永不重复的高性能分布式发号器 1. 为什么不直接采用UUID？ 虽然UUID能够保证唯一性，但无法满足业务系统需要的很多其他特性，比如时间粗略有序性、可反解和可制造性（说人话，就是分布式ID需要体现根据时间递增的特点，并且从ID串中能解析出一定的业务含义），同时UUID比较长，占空间大，性能较差。 2. 那基于数据库来实现呢？ 即通过调整自增字段或者数据库sequence的步长来确保跨数据库的ID的唯一性，但这种方案强依赖于数据库。 实现方案，可见我：重构 - 分布式ID设计方案 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客户端。 1234 <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId></dependency> 建立zookeeper连接，打开zkclient后，如果重复会使用

转： http://baike.baidu.com/link?url=HwhPVuqqWelWIr0TeSBGPZ5SjoaYb5_Givp9-rJN-PYbSTMlwpECSKvjzLBzUE7hn9VvmhDoKb5NNCPw1pCsTa Hadoop 是一个由Apache基金会所开发的 分布式系统 基础架构。 用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 [1] Hadoop实现了一个 分布式文件系统 （Hadoop Distributed File System），简称HDFS。HDFS有高 容错性 的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问 应用程序 的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。 Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。 [2] 中文名 海杜普 外文名 Hadoop 类 别 电脑程序 全 称 Hadoop Distributed File System 目录 1 起源 ▪ 项目起源 ▪

1、基本思想：zookeeper的应用场景均可从其节点类型和watcher机制进行考虑。 2、应用场景： a、统一命名服务：主要使用顺序节点进行。 b、集群管理：临时节点+wather机制 c、分布式日志收集： d、master选举： 5、分布式锁：使用临时节点+监听机制 6、分布式屏障：使用临时节点+监听机制 来源： https://www.cnblogs.com/guoyu1/p/11992274.html

转载自 https://www.cnblogs.com/luotianshuai/p/5206662.html Kafka初识 1、Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ 2、Kafka的定义 What is Kafka：它是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。 3、Kafka和其他主流分布式消息系统的对比 定义解释： 1、Java 和 scala都是运行在JVM上的语言。 2、erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言，所以RabbitMQ天生就有很高的并发性能，但是 有RabbitMQ严格按照AMQP进行实现，受到了很多限制。kafka的设计目标是高吞吐量，所以kafka自己设计了一套高性能但是不通用的协议