Zookeeper应用场景(二) 命名服务

命名服务

分布式系统中⽐较常⻅的⼀类场景，也是分布式系统最基本的公共服务之⼀。在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等——这些我们都可以统称它们为名字（Name），其中较为常⻅的就是⼀些分布式服务框架（如RPC、RMI）中的服务地址列表，通过使⽤命名服务，客户端应⽤能够根据指定名字来获取资源的实体、服务地址和提供者的信息等。

ZooKeeper 提供的命名服务功能能够帮助应⽤系统通过⼀个资源引⽤的⽅式来实现对资源的定位与使⽤。另外，⼴义上命名服务的资源定位都不是真正意义的实体资源——在分布式环境中，上层应⽤仅仅需要⼀个全局唯⼀的名字，类似于数据库中的唯⼀主键。

所以接下来。看看如何使⽤ZooKeeper来实现⼀套分布式全局唯⼀ID的分配机制

⼀说起全局唯⼀ ID，相信⼤家都会联想到 UUID。没错，UUID 是通⽤唯⼀识别码（UniversallyUnique Identififier）的简称，是⼀种在分布式系统中⼴泛使⽤的⽤于唯⼀标识元素的标准 确实，UUID是⼀个⾮常不错的全局唯⼀ID⽣成⽅式，能够⾮常简便地保证分布式环境中的唯⼀性。⼀个标准的UUID 是⼀个包含 32 位字符和 4 个短线的字符串，例如“e70f1357-f260-46ffff-a32d-53a086c57ade”。UUID的优势⾃然不必多说，我们重点来看看它的缺陷。

⻓度过⻓：UUID 最⼤的问题就在于⽣成的字符串过⻓。显然，和数据库中的 INT 类型相⽐，存储⼀个UUID需要花费更多的空间。
含义不明：开发⼈员从字⾯上基本看不出任何其表达的含义，这将会⼤⼤影响问题排查和开发调试的效率。

所以接下来，我们结合⼀个分布式任务调度系统来看看如何使⽤ZooKeepe来实现这类全局唯⼀ID的⽣成。 之前我们已经提到，通过调⽤ZooKeeper节点创建的API接⼝可以创建⼀个顺序节点，并且在API返回值中会返回这个节点的完整名字。利⽤这个特性，我们就可以借助ZooKeeper来⽣成全局唯⼀的ID了，如下图：

全局唯⼀ID⽣成的ZooKeeper节点示意图

对于⼀个任务列表的主键，使⽤ZooKeeper⽣成唯⼀ID的基本步骤：

1. 所有客户端都会根据⾃⼰的任务类型，在指定类型的任务下⾯通过调⽤create（）接⼝来创建⼀个顺序节点，例如创建“job-”节点。
2. 节点创建完毕后，create()接⼝会返回⼀个完整的节点名，例如“job-0000000003”。
3. 客户端拿到这个返回值后，拼接上 type 类型，例如“type2-job-0000000003”，这就可以作为⼀个全局唯⼀的ID了。

在ZooKeeper中，每⼀个数据节点都能够维护⼀份⼦节点的顺序顺列，当客户端对其创建⼀个顺序⼦节点的时ZooKeeper 会⾃动以后缀的形式在其⼦节点上添加⼀个序号，在这个场景中就是利⽤了ZooKeeper的这个特性。