wordpress网站加载过慢,潘家园网站建设,如何上传到自己的网站,wordpress菜单栏竖排zookeeper可谓是目前使用最广泛的分布式组件了。其功能和职责单一#xff0c;但却非常重要。
在现今这个年代#xff0c;介绍zookeeper的书和文章可谓多如牛毛#xff0c;本人不才#xff0c;试图通过自己的理解来介绍zookeeper#xff0c;希望通过一个初学者的视角来学习…zookeeper可谓是目前使用最广泛的分布式组件了。其功能和职责单一但却非常重要。
在现今这个年代介绍zookeeper的书和文章可谓多如牛毛本人不才试图通过自己的理解来介绍zookeeper希望通过一个初学者的视角来学习zookeeper以期让人更加深入和平稳的理解zookeeper。其中参考了不少教程和书相关书目列在文末也感谢这些作者。
学习新的框架先让我们搞清楚他是什么这是它的内涵然后再介绍它能做什么这是它的外延内涵和外延共同来定义框架本身会对框架有较为深刻的理解在应用层面上知道如何用。其次再搞清楚zookeeper相关的理论基础其目的是知道zookeeper是如何被发明的是否能够借鉴以便今后自己能够用到其他地方。最后搞清楚zookeeper中一些设计的原理和细节目的也是搞清来龙去脉学会“术”从而应用到别的地方。当然了加深的理解同样能够帮助认识zookeeper本身在使用时才知道为什么这样用。
首先
zookeeper到底是什么
zookeeper实际上是yahoo开发的用于分布式中一致性处理的框架。最初其作为研发hadoop时的副产品。由于分布式系统中一致性处理较为困难其他的分布式系统没有必要 费劲重复造轮子故随后的分布式系统中大量应用了zookeeper以至于zookeeper成为了各种分布式系统的基础组件其地位之重要可想而知。著名的hadoopkafkadubbo 都是基于zookeeper而构建。
要想理解zookeeper到底是做啥的那首先得理解清楚什么是一致性。
所谓的一致性实际上就是围绕着“看见”来的。谁能看见能否看见什么时候看见举个例子淘宝后台卖家在后台上架一件大促的商品通过服务器A提交到主数据库假设刚提交后立马就有用户去通过应用服务器B去从数据库查询该商品就会出现一个现象卖家已经更新成功了然而买家却看不到而经过一段时间后主数据库的数据同步到了从数据库买家就能查到了。
假设卖家更新成功之后买家立马就能看到卖家的更新则称为强一致性
如果卖家更新成功后买家不能看到卖家更新的内容则称为弱一致性
而卖家更新成功后买家经过一段时间最终能看到卖家的更新则称为最终一致性。
更多的一致性例子可以参考文献2里面列举了10种一致性的例子如果要给一致性下个定义可以是分布式系统中状态或数据保持同步和一致。特别需要注意一致性跟事务的区别可以记得学习数据库时特别强调ACID故而满足ACID的数据库能够做事务其中C即是一致性因此事务是一致性的一种特例比起一致性更难达成。 如何保证在分布式环境下数据的最终一致这个就是zookeeper需要解决的问题。对于这些问题有哪些挑战zookeeper又是如何解决这些挑战的下一篇文章将会主要涉及这个主题。
一些常见的解决一致性问题的方式 查询重试补偿。对于分布式应用中不确定的情况先使用查询接口查询到当前状态如果当前状态不一致则采用补偿接口对状态进行重试推进或者回滚接口对业务做回滚。典型的场景如银行跟支付宝之间的交互。支付宝发送一个转账请求到银行如一直未收到响应则可以通过银行的查询接口查询该笔交易的状态如该笔交易对方未收到则采取补偿的模式进行推送。 定时任务推送。对于上面的情况有可能一次推送搞不定于是需要2次3次推送。不要怀疑支付宝内最初掉单率很高全靠后续不断的定时任务推送增加成功率。 TCC。try-confirm-cancel。实际上是两阶段协议第二阶段的可以实现提交操作或是逆操作。
zookeeper到底能做什么
在业界的实际应用是什么了解这些应用会对zookeeper能够做的事有更直观的认识。
hadoop
鼻祖级应用ResourceManager在整个hadoop中算是单点为了实现其高可用分为主备ResourceManagerzookeeper在其中管理整个ResourceManager。
可以想象主备ResourceManager最初是主RM提供服务如果一切安好则zookeeper无用武之地。然而总归会出现主RM提供不了服务的情况。于是会出现主备切换的情况而zookeeper正是为主备切换保驾护航。
先来推理一下主备切换会出现什么问题。传统的主备切换可以让主备之间维持心跳连接一旦备机发现主机心跳检测不到了则自己切换为主机原来的主机等待救援。这种方式有两个问题一是由于网络抖动负载过大等问题备机检测不到心跳并不能说明主机一定挂了有可能一定时间后主机或网络恢复这时候主机并不知道备机已经切换为主机2台主机互相争用可能造成脑裂二是如果一些数据集中在主机上面则备机切换时由于同步延时势必会损失掉一部分的数据。
如何解决这些问题早期的方式提供了不少解决方案比如备机一旦切换为主机则通过电源控制直接切断主机电源简单粗暴但是此刻备机已经是单点如果主机是因为量撑不住而挂那备机有可能会重蹈覆辙最终导致整个服务不可用。
zookeeper又是如何解决这个问题的呢 zookeeper作为第三方集群参与到主备节点中去当主备启动时会在zookeeper上竞争创建一个临时锁节点争用成功者则充当主机其余备机 所有备机会监听该临时锁节点一旦主机与zookeeper间session失效则临时节点被删除 一旦临时节点被删除备机开始重新申请创建临时锁节点重新争用为主机; 用zookeeper如何解决脑裂实际上主机争用到节点后通过对根节点做一个ACL权限控制则其他抢占的机器由于无法更新临时锁节点只有放弃成为备机。
zookeeper使用了非常简单又现成的方式来解决的这个问题比起其他方案方便不少这也是为啥zookeeper流行的原因。说白了就是把复杂操作封装化精简化
dubbo
作为业界知名的分布式soa框架dubbo的主要的服务注册发现功能便是由zookeeper来提供的。
对于一个服务框架注册中心是其核心中的核心虽然暂时挂掉并不会导致整个服务出问题但是一旦挂掉整体风险就很高。考虑一般情况注册中心就是单台机器的时候其实现很容易所有机器起来都去注册服务给它并且所有调用方都跟它保持长连接一旦服务有变即通过长连接来通知到调用方。但是当服务集群规模扩大时这事情就不简单了单机保持连接数有限而且容易故障。
作为一个稳定的服务化框架dubbo可以选择并推荐zookeeper作为注册中心。其底层将zookeeper常用的客户端zkclient和curator封装成为ZookeeperClient。 当服务提供者服务启动时向zookeeper注册一个节点 服务消费者则订阅其父节点的变化诸如启动停止都能够通过节点创建删除得知异常情况比如被调用方掉线也可以通过临时节点session 断开自动删除得知 服务消费方同时也会将自己订阅的服务以节点创建的方式放到zookeeper 于是可以得到映射关系诸如谁提供了服务谁订阅了谁提供的服务基于这层关系再做监控就能轻易得知整个系统情况。
zookeeper的基本数据模型
一句话类似linux文件系统的节点模型 其节点有如下有趣而又重要的特性 同一时刻多台机器创建同一个节点只有一个会争抢成功。利用这个特性可以做分布式锁。 临时节点的生命周期与会话一致会话关闭则临时节点删除。这个特性经常用来做心跳动态监控负载等动作 顺序节点保证节点名全局唯一。这个特性可以用来生成分布式环境下的全局自增长id
通过zookeeper提供的原语服务可以对zookeeper能做的事情有个精确和直观的认识
zookeeper提供的原语服务 创建节点。 删除节点 更新节点 获取节点信息 权限控制 事件监听
实际上就是对节点的增删查改加上权限控制与事件监听但是通过对这些原语的组合以及不同场景的使用可以实现很多用法。参考文献5 数据发布订阅。即注册中心见上面dubbo用法。主要通过对节点管理做到发布以及事件监听做到订阅 负载均衡。见上面kafka用法 命名服务。zookeeper的节点结构天然支持命名服务即把信息集中存储并以树状管理方便统一查阅 分布式协调通知。协调通知实际上与发布订阅类似由于引入的第三方的zookeeper实际上对很多种协调通知做了解耦比如参考文献4中提到的消息推送心跳检测等 集群管理与master选举。通过上面的第二点特性可以轻易得知集群机器存活状况从而轻松管理集群通过上面第一点特性可以做出master争抢。 分布式锁。实际上就是第一点特性的应用。 分布式队列。实际上就是第三点特性的应用。 分布式的并发等待。类似于多线程的join问题主任务的执行依赖于其他子任务全部执行完毕在单机多线程里可以用join但是分布式环境下如何实现呢。利用zookeeper可以创建一个主任务节点旗下子任务一旦执行完毕则在主任务节点下挂一个子任务节点等节点数量足够则认为主任务可以开始执行。
可以发现所有的原语就是zookeeper的基础而其他的用法总结无非是将原语放到不同场景下的归类罢了。
相信到这里你对zookeeper应该有个初步的了解和大致的印象了。
