qq素材网站源码,瑞丽网站建设,seo搜索引擎优化岗位要求,网站导航做多大3 命名服务
命名服务(NameService)也是分布式系统中比较常见的一类场景#xff0c;在《Java网络高级编程》一书中提到#xff0c;命名服务是分布式系统最基本的公共服务之一。在分布式系统中#xff0c;被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等一这…3 命名服务
命名服务(NameService)也是分布式系统中比较常见的一类场景在《Java网络高级编程》一书中提到命名服务是分布式系统最基本的公共服务之一。在分布式系统中被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等一这些我们都可以统称它们为名字(Name)其中较为常见的就是一些分布式服务框架(如RPC、RMI)中的服务地址列表通过使用命名服务客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息等。 Java语言中的JNDI便是一种典型的命名服务。JNDI是Java命名与目录接口(Java Naming and Directory Interface)的缩写是J2EE体系中重要的规范之一标准的J2EE容器都提供了对JNDI规范的实现。因此在实际开发中开发人员常常使用应用服务器自带的JNDI实现来完成数据源的配置与管理一使用JNDI方式后开发人员可以完全不需要关心与数据库相关的任何信息包括数据库类型、JDBC驱动类型以及数据库账户等。 ZooKeeper提供的命名服务功能与JNDI技术有相似的地方都能够帮助应用系统通过一个资源引用的方式来实现对资源的定位与使用。另外广义上命名服务的资源定位都不是真正意义的实体资源一在分布式环境中上层应用仅仅需要一个全局唯一的名字类似于数据库中的唯一主键。 下面我们来看看如何使用ZooKeeper来实现一套分布式全局唯一ID的分配机制。 所谓ID就是一个能够唯一标识某个对象的标识符。在我们熟悉的关系型数据库中各个表都需要一个主键来唯一标识每条数据库记录这个主键就是这样的唯一ID。在过去的单库单表型系统中通常可以使用数据库字段自带的auto_increment属性来自动为每条数据库记录生成一个唯一的ID数据库会保证生成的这个ID在全局唯一。但是随着数据库数据规模的不断增大分库分表随之出现而auto_increment 属性仅能针对单一表中的记录自动生成ID因此在这种情况下就无法再依靠数据库的auto_increment 属性来唯一标识一条记录了。于是我们必须寻求一种能够在分布式环境下生成全局唯一ID的方法。 说起全局唯一ID相信读者都会联想到UUID。没错UUID是通用唯一识别码(Universally Unique Identifier) 的简称是一种在分布式系统中广泛使用的用于唯一标识元素的标准最典型的实现是GUID (Globally Unique ldentifier全局唯一标识符)主流ORM框架Hibernate有对UUID的直接支持。 确实UUID是一个非常不错的全局唯一ID生成方式能够非常简便地保证分布式环境中的唯一性。一个标准的UUID 是一个包含32位字符和4个短线的字符串例如“e70f1357-f260-46ff-a32d-53a086c57ade”。UUID的优势自然不必多说我们重点来看看
它的缺陷。
(1)长度过长
UUID最大的问题就在于生成的字符串过长。显然和数据库中的INT类型相比存储一个UUID需要花费更多的空间。
(2)含义不明
上面我们已经看到一个典型的UUID是类似于“e70f1357- f260-46fF- a32d-53a086c57ade的一个字符串。根据这个字符串开发人员从字面上基本看不出任何其表达的含义这将会大大影响问题排查和开发调试的效率。 接下来我们结合一个分布式任务调度系统来看看如何使用ZooKeeper来实现这类全局唯一ID的生成。 通过调用ZooKeeper节点创建的API接口可以创建一个顺序节点并且在API返回值中会返回这个节点的完整名字。利用这个特性我们就可以借助ZooKeeper来生成全局唯一的ID了如下图所示。 结合上图我们来讲解对于一个任务列表的主键使用ZooKeeper生成唯一ID 的基本步骤。
(1)所有客户端都会根据自己的任务类型在指定类型的任务下面通过调用create()接口来创建一个顺序节点例如创建“job-”节点。
(2)节点创建完毕后create()接口会返回一个完整的节点名,例如“job-000000003。
(3)客户端拿到这个返回值后拼接上type类型例如“type2-job 000000003” 这就可以作为一个全局唯一的ID了。 在ZooKeeper中每一个数据节点都能够维护--份子节点的顺序顺列当客户端对其创建一个顺序子节点的时候ZooKeeper会自动以后缀的形式在其子节点上添加一个序号在这个场景中就是利用了ZooKeeper的这个特性。 4 分布式协调/通知
分布式协调/通知服务是分布式系统中不可缺少的一个环节是将不同的分布式组件有机结合起来的关键所在。对于一个在多台机器上部署运行的应用而言通常需要一个协调者(Coordinator)来控制整个系统的运行流程例如分布式事务的处理、机器间的互相协调等。同时引入这样一个协调者便于将分布式协调的职责从应用中分离出来从而可以大大减少系统之间的耦合性而且能够显著提高系统的可扩展性。 ZooKeeper中特有的Watcher注册与异步通知机制能够很好地实现分布式环境下不同机器甚至是不同系统之间的协调与通知从而实现对数据变更的实时处理。基于ZooKeeper实现分布式协调与通知功能通常的做法是不同的客户端都对ZooKeeper上同一个数据节点进行Watcher注册监听数据节点的变化(包括数据节点本身及其子节点)如果数据节点发生变化那么所有订阅的客户端都能够接收到相应的Watcher通知并做出相应的处理。 MySQL数据复制总线Mysql_Replicator
MySQL数据复制总线(以下简称“复制总线”)是一个实时数据复制框架用于在不同的MySQL数据库实例之间进行异步数据复制和数据变化通知。整个系统是一个由MySQL数据库集群、消息队列系统、任务管理监控平台以及ZooKeeper 集群等组件共同构成的一个包含数据生产者、复制管道和数据消费者等部分的数据总线系统下图所示是该系统的整体结构图。 在该系统中ZooKeeper主要负责进行一系列的分布式协调工作在具体的实现上根据功能将数据复制组件划分为三个核心子模块Core、 Server 和Monitor每个模块分别为一个单独的进程通过ZooKeeper进行数据交换。
Core实现了数据复制的核心逻辑其将数据复制封装成管道并抽象出生产者和消费者两个概念其中生产者通常是MySQL数据库的Binlog日志。
Server负责启动和停止复制任务。
Monitor负责监控任务的运行状态如果在数据复制期间发生异常或出现故障会进行告警。
三个子模块之间的关系如下图所示。 每个模块作为独立的进程运行在服务端运行时的数据和配置信息均保存在ZooKeeper上Web控制台通过ZooKeeper上的数据获取到后台进程的数据同时发布控制信息。 任务注册
Core进程在启动的时候首先会向/mysql_replicator/tasks节点(以下简称“任务列表节点”)注册任务。例如对于一个“复制热门商品”的任务Task 所在机器在启动的时候会首先在任务列表节点上创建一个子节点例如/mysql_replicator/tasks/copy_hot_item(以下简称“任务节点)。如果在注册过程中发现该子节点已经存在说明已经有其他Task机器注册了该任务因此自己不需要再创建该节点了。 任务热备份
为了应对复制任务故障或者复制任务所在主机故障复制组件采用“热备份”的容灾方式即将同一个复制任务部署在不同的主机上我们称这样的机器为“任务机器”主、备任务机器通过ZooKeeper互相检测运行健康状况。 为了实现上述热备方案无论在第一步中是否创建了任务节点每台任务机器都需要在/mysql_replicator/tasks/copy_hot_item/instances节点上将自己的主机名注册上去。注意这里注册的节点类型很特殊是一个临时的顺序节点。在注册完这个子节点后通常一个完整的节点名如下: /mysql_replicator/tasks/copy_hot_item/intsances/[Hostname]-I其中最后的序列号就是临时顺序节点的精华所在。 在完成该子节点的创建后每台任务机器都可以获取到自己创建的节点的完成节点名以及所有子节点的列表然后通过对比判断自己是否是所有子节点中序号最小的。如果自己是序号最小的子节点那么就将自己的运行状态设置为RUNNING其余的任务机器则将自己设置为STANDBY我们将这样的热备份策略称为“小序号优先”策略。 热备切换
完成运行状态的标识后任务的客户端机器就能够正常工作了其中标记为RUNNING的客户端机器进行正常的数据复制而标记为STANDBY的客户端机器则进入待命状态。这里所谓待命状态就是说一旦标记为RUNNING的机器出现故障停止了任务执行那么就需要在所有标记为STANDBY的客户端机器中再次按照“小序号优先”策略来选出RUNNING机器来执行具体的做法就是标记为STANDBY的机器都需要在/mysql_replicator/tasks/copy_hot item/instances节点上注册一个“子节点列表变更”的Watcher监听用来订阅所有任务执行机器的变化情况——一旦RUNNING机器宕机与ZooKeeper断开连接后对应的节点就会消失于是其他机器也就接收到了这个变更通知从而开始新一轮的RUNNING选举。 记录执行状态
既然使用了热备份那么RUNNING任务机器就需要将运行时的上下文状态保留给STANDBY任务机器。在这个场景中最主要的上下文状态就是数据复制过程中的一些进度信息例如Binlog日志的消费位点因此需要将这些信息保存到ZooKeeper上以便共享。在Mysql_Replicator的设计中选择了/mysq_replicator/tasks/copy_hot_item/lastCommit作为Binlog日志消费位点的存储节点RUNNING任务机器会定时向这个节点写人当前的Binlog日志消费位点。 控制台协调
在Mysql_Replicator中Server主要的工作就是进行任务的控制通过ZooKeeper来对不同的任务进行控制与协调。Server会将每个复制任务对应生产者的元数据即库名、表名、用户名与密码等数据库信息以及消费者的相关信息以配置的形式写入任务节点/mysql_replicator/tasks/copy_hot_item中去以便该任务的所有任务机器都能够共享该复制任务的配置。 冷备切换
到目前为止我们已经基本了解了Mysql_Replicator的工作原理现在再回过头来看上面提到的热备份。在该热备份方案中针对一个任务都会至少分配两台任务机器来进行热备份但是在一定规模的大型互联网公司中往往有许多MySQL实例需要进行数据复制每个数据库实例都会对应一个复制任务如果每个任务都进行双机热备份的话那么显然需要消耗太多的机器。 和热备份中比较大的区别在于Core进程被配置了所属Group(组)。举个例子来说假如一个Core进程被标记了group1那么在Core进程启动后会到对应的ZooKeepergroup1节点下面获取所有的Task列表假如找到了任务“copy_hot_item”之后就会遍历这个Task列表的instances 节点但凡还没有子节点的则会创建一个临时的顺序节点: /mysql_replicator/task-groups/group1/copy_hot_item/instances/[Hostname]-1——当然在这个过程中其他Core进程也会在这个instances节点下创建类似的子节点。和热备份中的“小序号优先”策略一样顺序小的Core进程将自己标记为RUNNING不同之处在于其他Core进程则会自动将自己创建的子节点删除然后继续遍历下一个Task节点一我们将这样的过程称为“冷备份扫描”。就这样所有Core进程在一个扫描周期内不断地对相应的Group下面的Task进行冷备份扫描。整个过程可以通过如下图所示的流程图来表示。 冷热备份对比
从上面的讲解中我们基本对热备份和冷备份两种运行方式都有了一定的了解现在再来对比下这两种运行方式。在热备份方案中针对一个任务使用了两台机器进行热备份借助ZooKeeper的Watcher通知机制和临时顺序节点的特性能够非常实时地进行互相协调但缺陷就是机器资源消耗比较大。而在冷备份方案中采用了扫描机制虽然降低了任务协调的实时性但是节省了机器资源。 一种通用的分布式系统机器间通信方式
在绝大部分的分布式系统中系统机器间的通信无外乎心跳检测、工作进度汇报和系统调度这三种类型。接下来我们将围绕这三种类型的机器通信来讲解如何基于ZooKeeper去实现一种分布式系统间的通信方式。 心跳检测
机器间的心跳检测机制是指在分布式环境中不同机器之间需要检测到彼此是否在正常运行例如A机器需要知道B机器是否正常运行。在传统的开发中我们通常是通过主机之间是否可以相互PING通来判断更复杂一点的话则会通过在机器之间建立长连接通过TCP连接固有的心跳检测机制来实现上层机器的心跳检测这些确实都是一些非常常见的心跳检测方法。 下面来看看如何使用ZooKeeper来实现分布式机器间的心跳检测。基于ZooKeeper的临时节点特性可以让不同的机器都在ZooKeeper的一个指定节点下创建临时子节点不同的机器之间可以根据这个临时节点来判断对应的客户端机器是否存活。通过这种方式检测系统和被检测系统之间并不需要直接相关联而是通过ZooKeeper上的某个节点进行关联大大减少了系统耦合。 工作进度汇报
在一个常见的任务分发系统中通常任务被分发到不同的机器上执行后需要实时地将自己的任务执行进度汇报给分发系统。这个时候就可以通过ZooKeeper来实现。在ZooKeeper上选择一个节点每个任务客户端都在这个节点下面创建临时子节点这样便可以实现两个功能
通过判断临时节点是否存在来确定任务机器是否存活
各个任务机器会实时地将自己的任务执行进度写到这个临时节点上去以便中心系
统能够实时地获取到任务的执行进度。 系统调度
使用ZooKeeper能够实现另--种系统调度模式一个分布式系统由控制台和一些客户端系统两部分组成控制台的职责就是需要将--些指令信息发送给所有的客户端以控制它们进行相应的业务逻辑。后台管理人员在控制台上做的一些操作实际上就是修改了ZooKeeper上某些节点的数据而ZooKeeper进一步把这些数据变更以事件通知的形式发送给了对应的订阅客户端。 总之使用ZooKeeper来实现分布式系统机器间的通信不仅能省去大量底层网络通信和协议设计上重复的工作更为重要的一点是大大降低了系统之间的耦合能够非常方便地实现异构系统之间的灵活通信。
