1、为什么使用Zookeeper
Zookeeper是一个文件系统的数据结构
(1) Zookeeper是Googel的Chubby的一个开源实现,是Hadoop的分布式协调服务,它包好了一个简单的原语,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等。
(2) Zookeeper本身也允许单机模式,但是一台服务器很难表达出zookeeper的强大功能,所以真是生产环境下zookeeper一班都是3台以上的奇数量的存在,证实了zookeeper本身是一个分布式集群的存在。
(3) ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
(4)ZooKeeper代码版本中,提供了分布式独享锁、选举、队列的接口,代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本,选举只有Java版本
a. 大部分的分布式应用程序都需要一个主控、协调器或者控制器来物理分布的子进程(如资源,内存分配等)
b. 目前大部分应用开发私有的协调程序,缺乏一个通用性
c. 协调程序的反复编写浪费,难以形成通用、伸缩性好的协调器
d. ZooKeeper:提供通用的分布式锁服务,用以协调分布式应用
从目前来看有两个点好看
第一个就是:分布式事务
第二个就是:文件系统的数据结构(存储一些公共数据:如配置信息,不必要每个部署环境都配置一份)
第三个就是:做Service发现服务(ServiceDiscovery),在微服务来临的今天。Duubo 或者 Spring cloud,同一业务模块我一次可能就是部署十台服务器,那么我来一个请求,我如果自己去做请求,那么我该去请求哪一台?这样专业的事情就交给Zookeeper或者eureka这种发现服务去处理。文章最后我在网上看到有个朋友写的挺好的,加上了。
2、什么是分布式
小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,这两个厨师的关系是集群。为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系是分布式,一个配菜师也忙不过来了,又请了个配菜师,两个配菜师关系是集群。
3、分布式与集群有什么区别
集群是个物理形态,分布式是个工作方式
集群是:同一件业务服务,部署到多个物理端,这个是集群。
分布式:同一业务拆分成多个业务,比如:登录系统:
原来的主线是:登录—>安全检测—>日志—>个人信息—>个人权限信息
拆分为:登录接口、日志记录模块、安全检测模块、个人信息模块、个人权限模块
不必需要使用同步处理,异步处理即可,能够节省大量的运算时间。
后话:在拆分到不能拆分后,我们还是会有新的集群,比如讲,用户量上去后,我们会把登录接口再做集群,分散到多个不同物理机器,分布式、集群一般都是伴随着的。
4、分布式的CAP
一致性:Consistency
可用性:Availability
分区容错性:Partitiontolerance
一致性:数据修改后必须多地同步修改了
可用性:24小时全时段的服务不中断
分区容错性:就是有备份系统,如 一个master,多个backup
CA(放弃P) 将所有的数据放在一个库,满足一致性和可用性。代表:关系型数据库
CP(放弃A) 放弃可用性,来保持一致性。代表:zookeeper
AP(放弃C) 放弃一致性,适合不需要一致性的场合。代表:eureka
5、Zookeeper能解决发现服务问题
最近碰到有人问,使用dubbo时为什么要用zookeeper作为注册中心,zookeeper是如何起作用的?
我把我的理解说了一下。
先给他探讨性地说明了一些背景问题:
首先,为什么用dubbo?不就是因为dubbo能够帮我们解决分布式系统远程接口相互调用的问题吗?那在一个分布式系统中,大量的接口怎么实现相互调用呢,毕竟调用者和被调用者可能在2台不同的机器上。
当然,我们有很多办法来实现。最简单的,在配置文件中将所有要调用的接口的地址配置好,要用时通过web的方式调用即可。
但是,但是,,,很多分布式系统之间的调用不是一对多,或者多对一的,而是一个多对多的网状。即A可能调用B、C、D接口,B也可能调用A、C、D接口,以此类推。如果接口的数量是个位级的(个位级也就不用DUBBO了)还好办,如果是2位的甚至3位级的,那以后维护这些接口将会是一个灾难!为何呢?如果某一接口换了机器IP或者新增了一个将被调用很多的接口,那就是系统性的程序变更了,对一个生产系统来说风险挺大!
好,现在说正题:
如果将一个系统比作一个项目团队,则该系统内的相互接口调用,就类似于团队之间的沟通协作。比如,需求人员员要找开发人员确认需求,开发人员要找测试人员测试需求,测试人员要找需求人员验收需求等等。团队各种不同类型的人员可能来自不同部门。
如果是小团队,大家集中从在一个办公室,有什么事面对面直接沟通即可,这就类似于我们同一工程内接口的调用,直接new对象或通过spring配置的即可。
如果是一个大型团队,大家可能坐在不同办公室甚至不同城市,沟通就只能通过打电话或发邮件了(这里的电话系统或邮件系统就是DUBBO了)。想想看,如果没有一个统一的通讯录,每个人就要自己搞一个通讯本记录自己要沟通的人员的电话或邮件。这个通讯本可能千差万别,有人用纸,有人用笔记本,有人用电脑,有人用手机等等。。。(这里的通讯本记录方式就类似于我们对接口的记录方式,纸和笔记本就类似于直接记在程序中的,电脑和手机类似于记在配置文件中)。万一哪天某一个关键人物的联系方式变了,那大家有得忙了,用电脑和手机的还好,改改就好了。用了纸和和笔记本的,就只能换一张纸甚至换一个笔记本了。而且,让项目经理头疼的是,有些人可能没改或者改错,遇到关键问题时因找不到人发生不可预料事件(类比于我们生产事故)!
那像这种大型团队的沟通问题怎么解决呢?人家说这还不超级简单嘛,搞个统一的通讯录,专人管理,上面记录所有人的联系方式,如果某人联系方式有变动,通知专人修改通讯录即可,然后大家要联系某人时,通过人名查找通讯录不就行了嘛!
对!就是这么简单!zookeeper就是这个通讯录和管通讯录的人!
如果回到我们的系统中,接口名就是人名(不过在dubbo中这个人名不能重复),接口实现就是这个人,接口IP地址就是联系电话或邮件,电话系统或邮件系统就是dubbo!
这么一说,问我的人立即就明白了,zookeeper的作用是不是就很好理解了呵呵。
第五点引用:https://www.2cto.com/kf/201708/668587.html