- 浏览: 626461 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (819)
- java开发 (110)
- 数据库 (56)
- javascript (30)
- 生活、哲理 (17)
- jquery (36)
- 杂谈 (15)
- linux (62)
- spring (52)
- kafka (11)
- http协议 (22)
- 架构 (18)
- ZooKeeper (18)
- eclipse (13)
- ngork (2)
- dubbo框架 (6)
- Mybatis (9)
- 缓存 (28)
- maven (20)
- MongoDB (3)
- 设计模式 (3)
- shiro (10)
- taokeeper (1)
- 锁和多线程 (3)
- Tomcat7集群 (12)
- Nginx (34)
- nodejs (1)
- MDC (1)
- Netty (7)
- solr (15)
- JSON (8)
- rabbitmq (32)
- disconf (7)
- PowerDesigne (0)
- Spring Boot (31)
- 日志系统 (6)
- erlang (2)
- Swagger (3)
- 测试工具 (3)
- docker (17)
- ELK (2)
- TCC分布式事务 (2)
- marathon (12)
- phpMyAdmin (12)
- git (3)
- Atomix (1)
- Calico (1)
- Lua (7)
- 泛解析 (2)
- OpenResty (2)
- spring mvc (19)
- 前端 (3)
- spring cloud (15)
- Netflix (1)
- zipkin (3)
- JVM 内存模型 (5)
- websocket (1)
- Eureka (4)
- apollo (2)
- idea (2)
- go (1)
- 业务 (0)
- idea开发工具 (1)
最新评论
-
sichunli_030:
对于频繁调用的话,建议采用连接池机制
配置TOMCAT及httpClient的keepalive以高效利用长连接 -
11想念99不见:
你好,我看不太懂。假如我的项目中会频繁调用rest接口,是要用 ...
配置TOMCAT及httpClient的keepalive以高效利用长连接
ZooKeeper内部有一个in-memory DB,表示为一个树形结构。每个树节点称为Znode(相关的代码在DataTree.java和DataNode.java中)
客户端可以连接到zookeeper集群中的任意一台。
对于读请求,直接返回本地znode数据。写操作则转换为一个事务,并转发到集群的Leader处理。Zookeeper提交事务保证写操作(更新)对于zookeeper集群所有机器都是一致的。
ZooKeeper中提交事务的协议并不是Paxos,而是由二阶段提交协议改编的ZAB协议。
Zab可以满足以下特性
Reliable delivery:如果消息m被一个server递交(commit)了,那么m也将最终被所有server递交。
Total order:如果server在递交b之前递交了a,那么所有递交了a、b的server也会在递交b之前递交a。
Casual order:对于两个递交了的消息a、b,如果a因果关系优先于(causally precedes)b,那么a将在b之前递交。
第三条的因果优先指的是同一个发送者发送的两个消息a先于b发送,或者上一个leader发送的消息a先于当前leader发送的消息。
Zab协议中Server有两个模式:broadcast模式、recovery模式(Leader宕机或follower不构成quorum)
Leader在开始broadcast之前,必须有一个同步更新过的follower的quorum(多数派)。
Server在Leader服务期间恢复在线时,将进入recovery模式,与Leader进行同步。
Broadcast模式使用二阶段提交,但是简化了协议,不需要abort。follower要么ack,要么抛弃Leader,因为zookeeper保证了每次只有一个Leader。另外也不需要等待所有Server的ACK,只需要一个quorum应答就可以了。
Follower收到proposal后,写到磁盘(尽可能批处理),返回ACK。
Leader收到大多数ACK后,广播COMMIT消息,自己也deliver该消息。
Follower收到COMMIT之后,deliver该消息。
然而,这个简化的二阶段提交不能处理Leader失效的情况,所以增加了recovery模式。切换Leader时,需要解决下面两个问题。
Never forget delivered messages
Leader在COMMIT投递到任何一台follower之前宕机,只有它自己commit了。新Leader必须保证这个事务也必须commit。
Let go of messages that are skipped
Leader产生某个proposal,但是在宕机之前,没有follower看到这个proposal。该server恢复时,必须丢弃这个proposal。
新Leader在propose新消息之前,必须保证事务日志中的所有消息都proposed并且committed。
为了保证follower看到有proposal,以及递交的消息,Leader向follower发送follower没有见过的PROPOSAL,以及最后提交的消息的编号之前的COMMIT。
因为Proposal是保存在follower的事务日志中,并且顺序有保证,因此COMMIT的顺序也是确定的。解决的第一个问题。
上个没有把proposal发送出去的Leader重启后,新Leader将告诉它截断事务日志,一直截断到follower的epoch对应的最后一个commit位置。
关于ZAB的详细证明可以参考Zab - High-performance broadcast for primary-backup systems
参考:http://blog.csdn.net/m_vptr/article/details/9325405
客户端可以连接到zookeeper集群中的任意一台。
对于读请求,直接返回本地znode数据。写操作则转换为一个事务,并转发到集群的Leader处理。Zookeeper提交事务保证写操作(更新)对于zookeeper集群所有机器都是一致的。
ZooKeeper中提交事务的协议并不是Paxos,而是由二阶段提交协议改编的ZAB协议。
Zab可以满足以下特性
Reliable delivery:如果消息m被一个server递交(commit)了,那么m也将最终被所有server递交。
Total order:如果server在递交b之前递交了a,那么所有递交了a、b的server也会在递交b之前递交a。
Casual order:对于两个递交了的消息a、b,如果a因果关系优先于(causally precedes)b,那么a将在b之前递交。
第三条的因果优先指的是同一个发送者发送的两个消息a先于b发送,或者上一个leader发送的消息a先于当前leader发送的消息。
Zab协议中Server有两个模式:broadcast模式、recovery模式(Leader宕机或follower不构成quorum)
Leader在开始broadcast之前,必须有一个同步更新过的follower的quorum(多数派)。
Server在Leader服务期间恢复在线时,将进入recovery模式,与Leader进行同步。
Broadcast模式使用二阶段提交,但是简化了协议,不需要abort。follower要么ack,要么抛弃Leader,因为zookeeper保证了每次只有一个Leader。另外也不需要等待所有Server的ACK,只需要一个quorum应答就可以了。
Follower收到proposal后,写到磁盘(尽可能批处理),返回ACK。
Leader收到大多数ACK后,广播COMMIT消息,自己也deliver该消息。
Follower收到COMMIT之后,deliver该消息。
然而,这个简化的二阶段提交不能处理Leader失效的情况,所以增加了recovery模式。切换Leader时,需要解决下面两个问题。
Never forget delivered messages
Leader在COMMIT投递到任何一台follower之前宕机,只有它自己commit了。新Leader必须保证这个事务也必须commit。
Let go of messages that are skipped
Leader产生某个proposal,但是在宕机之前,没有follower看到这个proposal。该server恢复时,必须丢弃这个proposal。
新Leader在propose新消息之前,必须保证事务日志中的所有消息都proposed并且committed。
为了保证follower看到有proposal,以及递交的消息,Leader向follower发送follower没有见过的PROPOSAL,以及最后提交的消息的编号之前的COMMIT。
因为Proposal是保存在follower的事务日志中,并且顺序有保证,因此COMMIT的顺序也是确定的。解决的第一个问题。
上个没有把proposal发送出去的Leader重启后,新Leader将告诉它截断事务日志,一直截断到follower的epoch对应的最后一个commit位置。
关于ZAB的详细证明可以参考Zab - High-performance broadcast for primary-backup systems
参考:http://blog.csdn.net/m_vptr/article/details/9325405
发表评论
-
Zookeeper的四字命令
2017-05-18 20:39 548http://www.cnblogs.com/wuxl360/ ... -
Zookeeper开源客户端框架Curator简介
2016-10-25 08:43 495ZooKeeper原生的API支持通过注册Watcher来进行 ... -
Curator Framework的基本使用方法
2016-10-21 15:17 1042Curator Framework提供了简化使用zookeep ... -
ZooKeeper学习总结
2016-09-30 15:18 401参考:http://www.tuicool.com/artic ... -
推荐一个zookeeper信息查看工具
2016-08-31 16:01 1689zookeeper信息查看工具 下载地址:https://i ... -
Paxos算法细节详解(一)--通过现实世界描述算法
2016-08-24 16:29 535http://www.cnblogs.com/endsock/ ... -
ZooKeeper学习总结 第一篇:ZooKeeper快速入门
2016-08-22 16:23 421http://www.cnblogs.com/leocook/ ... -
zookeeper原理(转)
2016-08-22 14:02 378ZooKeeper是一个分布式的 ... -
zookeeper客户端curator使用手记
2016-08-09 15:10 456http://www.tuicool.com/articles ... -
Zookeeper的一致性协议:Zab
2016-08-01 09:21 647Zookeeper使用了一种称为Zab(Zookeeper A ... -
Zookeeper基本原理与应用场景
2016-07-28 18:51 305http://blog.csdn.net/yunpiao123 ... -
一步一步理解Paxos算法
2016-07-21 14:34 600背景 Paxos算法是Lamport ... -
Paxos算法简述
2016-07-21 14:10 365Paxos算法是分布式中一个著名的一致性算法。它的假设前提是, ... -
Zookeeper-Zookeeper leader选举
2016-07-20 09:05 524在上一篇文章中我们大 ... -
部署与管理ZooKeeper(转)
2016-07-19 09:17 366http://www.cnblogs.com/ggjuchen ... -
ZooKeeper原理及使用
2016-08-02 08:27 401ZooKeeper是Hadoop Ecosystem中非常重要 ... -
ZooKeeper Java API
2016-05-22 10:05 878ZooKeeper提供了Java和C的binding. 本文关 ...
相关推荐
在本课程中,我们将深入探讨Zookeeper的ZAB协议实现,并通过源码分析来理解其启动流程、快照与事务日志的存储结构。Zookeeper是一款分布式协调服务,广泛应用于分布式系统中,如Hadoop、HBase等。本节主要关注...
通过阅读源码,我们可以深入了解ZooKeeper如何处理并发、如何进行数据同步、如何实现Watcher机制,以及如何保证分布式一致性。这对于我们优化ZooKeeper性能、解决实际问题或开发类似服务具有极高的价值。 在...
Zookeeper是一个分布式的,开放源码的协调服务,它提供了一种简单有效的原语集,使得分布式应用能够处理命名服务、配置管理、集群同步等问题。ZAB协议是Zookeeper在数据一致性方面的重要保障,它确保了在分布式环境...
ZooKeeper是一个分布式的,开放源码的分布式应用程序...通过阅读和理解这个注释版的ZooKeeper源码,开发者能够深入了解其实现细节,更好地利用它来解决分布式环境中的问题,同时也为开发更高级别的分布式服务提供基础。
《Zookeeper源码分析》 Zookeeper是一款分布式协调服务,广泛应用于分布式系统中,提供诸如命名服务、配置管理、集群同步、领导者选举等核心功能。本文将深入剖析Zookeeper的工作原理,以及其内部实现的FastLeader...
本文将围绕“Zookeeper源码”这一主题,深度探讨Zookeeper的核心设计与实现原理。 一、Zookeeper架构 Zookeeper采用Paxos算法的变种ZAB(Zookeeper Atomic Broadcast)协议来保证分布式一致性。Zookeeper集群由多...
《Zookeeper源码剖析:深入理解Leader选举机制》是一篇深度探讨Zookeeper分布式协调系统核心机制的文章。在Zookeeper中,Leader选举是整个系统稳定运行的关键,它保证了集群的一致性和高可用性。本文将从以下几个...
《深入解析Zookeeper源码:Java视角下的分布式协调机制》 在分布式系统中,Zookeeper以其高可用性、强一致性以及简洁的API成为了许多大型企业的首选协调服务。本篇文章将基于Java源码,深入剖析Zookeeper的核心机制...
《深入解析ZooKeeper源码》 ZooKeeper是一款分布式协调服务,由雅虎创建并开源,现为Apache基金会顶级项目。它为分布式应用提供一致性服务,如命名服务、配置管理、集群同步、分布式锁等。本文将深入探讨ZooKeeper...
该项目名为“ZooKeeper源码Eclipse工程项目”,意味着它是专门为Eclipse IDE准备的,可以直接导入进行阅读和学习,无需通过ANT等构建工具编译。这使得开发者可以更便捷地在IDE环境中查看、调试和理解代码。 ...
`pyzab` 是一个基于 Python 的开源项目,它实现了 Apache ZooKeeper 的核心协议——原子广播(ZAB)协议。ZAB 协议是分布式协调服务 ZooKeeper 的基础,确保了高可用性和数据一致性。在深入探讨 `pyzab` 之前,我们...
1. **一致性模型**:Zookeeper采用ZAB(Zookeeper Atomic Broadcast)协议,确保在分布式环境中数据的一致性。这种强一致性模型使得多个节点上的数据保持同步,为分布式服务提供可靠的数据支持。 2. **原子操作**:...
Watcher特性总结:一次性、客户端串行执行、轻量。 ZooKeeper的面试题涵盖了分布式协调服务的基本概念、ZooKeeper的文件系统、ZAB协议、数据节点类型和Watcher机制等知识点,为开发者和架构师提供了系统的知识架构...
本书从分布式一致性的理论出发,向读者简要介绍几种典型的分布式一致性协议,以及解决分布式一致性问题的思路,其中重点讲解了Paxos和ZAB协议。同时,本书深入介绍了分布式一致性问题的工业解决方案——ZooKeeper,...
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,它是集群的管理者,监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终将简单易用的接口和性能高效、功能稳定的系统提供给用户。...
每个Server都保存整个数据树的一个副本,并通过Paxos或ZAB(Zookeeper原子广播协议)协议进行数据同步,以确保数据一致性。通常,为了高可用性,Zookeeper集群会配置奇数个Server节点。 **Zookeeper的部署模式:** ...
在源码中,你可以看到ZOOKEEPER如何实现选举过程,如何处理客户端请求,以及如何通过ZAB协议进行数据同步。通过对这些源码的学习,可以深入理解分布式一致性背后的设计思想和实现细节,这对于开发和维护分布式系统至...
- ZAB(Zookeeper Atomic Broadcast)协议是Zookeeper的原子广播协议,它包含了选举算法。基本思路是通过比较每个节点的选举优先级(通常是服务器ID)和提议的事务ID来确定领导者。 - 当多数节点同意一个节点为...
《深入解析Zookeeper源码》 Zookeeper是一个分布式协调服务,广泛应用于分布式系统中,如Hadoop、HBase、Kafka等。它提供了一种可靠的方式来管理分布式环境中的配置信息、命名服务、集群状态同步以及分布式锁等功能...