- 目录
- 概 述
- 小结
- 参考资料和推荐阅读
目录 概 述LD is tigger forever,CG are not brothers forever, throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI, Keep progress,make a better result.
Survive during the day and develop at night。
分布式系统定义及面临的问题
Zookeeper 最为主要的使用场景,是作为分布式系统的分布式协同服务。
我们将分布式系统定义为:分布式系统是同事跨越多个物理主机,独立运行的多个软件所组成的系统。类比一下,分布式系统就是一群人干活,人多力量大,每个服务器的算力是有限的,但是通过分布式系统,由n个服务器组成起来的集群,算力可以试无限扩张的。
优点显而易见,人多干活快,并且互为备份,但是缺点也很明显。我们可以想象一下,以一个小研发团队开发软件为例,假设我们有一个5人的项目组,要开始一个系统的开发,项目组将面临如下问题:
图中列举的就是项目组将要面临的问题,这些问题在我们日常工作中也是天天发生,并没感觉有多么复制,因为我们人类的大脑是个超级计算机,能够灵活应对这些问题,而且现实中信息的交换不依赖网络,不会因网络延迟或者中断,出现信息不对等,而且现实中对以上问题的处理其实并不严谨,从而也引发了很多问题。想一下,项目中是不是出现过沟通不畅造成任务分配有歧义?是否由于人员离职造成任务进行不下去,甚至要联系离职人员协助?是不是出现过任务分配不合理?类似这种问题,肯定会发生在项目中,在显示世界里,我们可以人为去协调,即使出错了,还可以人工去补错。但是在计算机的世界,一切要保证严谨,以上问题要做到尽可能不要发生。因此分布式系统必须采用合理的方式解决以上的问题。
实际上要想解决这些问题并没有那么复杂,我们仅需要做一件事就可以了—— 让信息在项目组成员中同步。如果能做到信息同步,那么每个人在干什么,大家都是清楚的,做到什么程度也是清晰的,无论谁离职也不会产生问题,分配的工作,能够及时清晰的同步给每个组员,确保每个组员收到的任务分配没有冲突。
分布式系统的协调工作就是通过某种方式,让每个节点的信息能够同步和共享。这依赖与服务进程之间的通信。通信方式有两种:
通过网络进行信息共享
这就像现实中,开发leader在会上把任务传达下去,组员通过听leader命令或者看leader的邮件知道自己要干什么。当任务分配有变化时,leader会单独告诉组员,或者再次召开会议。信息通过人与人之间的直接沟通完成传递。
通过共享存储
这就好比开发leader按照约定的时间和路径,把任务分配表放到了svn上,组员每天去svn上拉取最新的任务分配表,然后干活。其中svn就是共享存储。更好一点的做法是:当svn文件版本更新时,触发邮件通知,每个组员再去拉取最新的任务分配表。这样做会更好,组员都能第一时间得到消息,从而让自己手中的任务分配表永远是最新的。这种方式依赖于中央存储。整个过程如下所示:
Zookeeper 如何解决分布式系统面临的问题
Zookeeper 对分布式系统的协调,使用是第二种方式,共享存储。其实共享存储,分布式应用也需要和存储进行网络通信。
实际上,通过Zookeeper 实现分布式协同的原理,和项目组通过SVN同步工作任务的例子是一样的。Zookeeper 就像是SVN,存储了任务的分配、完成情况等共享信息。每个分布式应用的节点就是组员,订阅这些共享信息。当主节点对某个从节点的分工信息作出改变时,相关订阅的从节点得到zookeeper的通知,取得自己最新的任务分配。完成工作后,把完成情况存储到 zookeeper,主节点订阅了该任务的完成情况信息,所以将得到zookeeper的完工通知。
Slave 节点想要获取 zookeeper 的更新通知,需事先在关心的数据节点上设置观察点
大多数分布式系统中出现的问题,都源于信息的共享除了问题。如果各个节点间信息不能及时共享合同部,那么就会在协作过程中产生各种问题。zookeeper解决协同问题的关键,就是在于保证分布式系统信息的一致性。
zookeeper 的基本概念
zookeeper 是一个开源的分布式协调服务,其设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一些简单的接口提供给用户使用。zookeeper 是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现诸如 数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁和分布式队列 等功能。
基本概念
① 集群角色
通常在分布式系统中,构成一个集群的每一台机器都有自己的角色,最典型的集群就是 Master / Slave 模式(主从模式),此情况下把所有能够处理写 *** 作的机器成为 Master 机器,把所有通过异步复制方式获取最新数据,并提供读服务的机器称为 Slave 机器
而在zookeeper 中,它没有沿用传统的 Master/Slave 概念,而是引入了 Leader、Follower、Observer 三种角色。
zookeeper 集群中的所有机器通过 Leader 选举来选定一台被称为 Leader 的机器,Leader 服务器为客户端提供读和写服务。除Leader 外,其他机器包括 Follower 和 Observer也能提读服务,Follower 和 Observer 唯一的区别是 Observer 不参与 Leader 选举过程,不参与写 *** 作的过半写成功策略,因此 Observer 可以在不影响写性能的情况下提升集群的性能。
② 会话(Session)
Session 指客户端会话,一个客户端连接是指客户端和服务端之间的一个 TCP 长连接,zookeeper 对外的服务端口默认为 2181,。客户端启动的时候,首先会与服务器建立一个 TCP 连接,从第一次连接建立开始,客户端会话的生命周期也开始了,通过这个连接,客户端能够心跳检查与服务器保持有效的会话,也能够向 zookeeper 服务器发送请求并接受响应,同时还能通过该连接接受来自服务器的 Watch 时间通知。
③ 数据节点(Znode)
在谈到分布式的时候,我们通常说的 “节点” 是指组成集群的每一台机器。然而在zookeeper中,“节点” 分为两类,第一类同样是指构成集群的机器,我们称之为机器节点;第二类则是指数据模型中的数据单元,我们称之为数据节点—— ZNode。zookeeper将所有数据存储在内存中,数据模型是一棵树(ZNode Tree),由斜杠(/)进行分割的路径,就是一个 ZNode,例如 /app/path1 。每个 ZNode 上都会保存自己的数据内容,同时还会保存一系列属性信息。
④ 版本
上面我们提到,zookeeper 的每个ZNode 上都会存储数据,对于每个ZNode,zookeeper都会为其维护一个叫做 stat 的数据结构,Stat 记录了这个ZNode的三个数据版本,分别是 version(当前ZNode的版本)、cversion(当前ZNode子节点的版本)、aversion(当前ZNode的ACL版本)
⑤ Watcher(事件监听器)
Watcher(事件监听器),是zookeeper中一个很重要的特性,zookeeper 允许用户在指定节点上注册一些 Watcher,并且在一些特定时间触发的时候,zookeeper 服务端会将事件通知到感兴趣的客户端,该机制是 zooke
1.链接: 参考资料.
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)