在软件R&D项目中，经常会遇到系统主键的唯一性问题，尤其是在时下火热的微服务架构中。分布式ID具有唯一性、高可用性和有序增长的特点，其生成策略也比较复杂。

目前，生成ID的方法多种多样，适用的需求、场景和性能也各不相同。选择适合自己需求的解决方案非常重要。下面，我们将总结分布式系统中主键的生成策略，并列出其适用场景、优缺点等。，从而为后续的学习和工作提供参考。

1.JDK带来的UUID

编程语言开发工具包都有生成主键的策略。以java语言的UUID为例(图1)。它具有世界上独一无二的特性，可以用作分布式系统ID。核心思想是通过结合服务器的网卡、本地时间和计数来生成UUID。

优点是生成简单、性能好、全球唯一，在数据迁移、系统合并或者数据库变更的情况下都可以应对。缺点就是生成的ID一般使用字符串存储，可读性性较差。在数据库中占有空间较大并且查询的效率比较低，在各微服务场景下，耗费的网络资源也响应增多。

图1

2.数据库自增量ID

基于数据库的Auto_increment ID完全可以用作分布式ID。具体原理:创建一个单独的实例来生成ID，并使用一个数据表来存储当前的最大ID(图2)。

当我们需要一个ID时，我们在表中插入一条记录返回主键ID，但是当访问次数急剧增加时，数据库本身就是系统的瓶颈。用它来实现分布式服务有风险，不推荐！

优点是数据库生成的ID绝对有序，高可用实现方式简单；缺点是需要独立部署数据库实例，成本高，数据库压力大，性能有限（可通过DB集群设置不同步长改善，即部署N台数据库实例，每台设置成不同的初始值，自增步长为机器的台数，如图3所示，可实现多个ID实例自增），但这种方法可能会导致数据的安全性问题。

图2

图3

3.段落模式

一次按需批量生成多个id。每次生成都需要访问数据库，将数据库修改为最大ID值，并将当前值和最大值记录在内存中。一般可以用redis来实现，如图4所示。

优点是避免了每次生成ID都要访问数据库并带来压力，提高性能；缺点是属于本地生成策略，存在单点故障，服务重启造成ID不连续。

图4

4.Redis世代

Redis服务器也可以生成全局ID，这主要依赖于Redis是单线程的，所以也可以用来生成全局唯一ID，如图5所示。Redis的原子操作INCR和INCRBY被用来实现它。

优点是不依赖于数据库，灵活方便，性能高。数字ID天然排序，对分页或者需要排序的结果很有帮助。使用Redis集群也可以防止单点故障的问题；缺点是依赖第三方组件Redis，增加系统复杂度。需要编码和配置的工作量比较大。

图5

5.雪花算法

雪花是twitter开源的分布式ID生成算法。其核心思想是一个长ID: 41 bit作为毫秒数，10 bit作为机器号(10 bit的长度最多可以支持1024个节点的部署)，12 bit作为毫秒内的序列号(12 bit的计数序列号可以支持每个节点每毫秒生成4096个ID序列号)，如图6所示。

优点是简单高效，生成速度快。时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增。灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求。不需要其他依赖，使用方便。缺点是强依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成。在分布式环境上，每个服务器的时钟不可能完全同步，有时会出现不是全局递增的情况，不同机器配置不同worker id麻烦。

图6

6.百度UidGenerator

UIDGenerator是用Java实现的唯一id生成器，基于雪花算法。UidGenerator在应用项目中作为一个组件工作(图7)，支持自定义的workerId数字和初始化策略，因此适用于docker等虚拟化环境中的自动重启和漂移等实例。

优点是全局唯一，高可用、高性能解决了始终回拨的问题；缺点是内置WorkerID分配器, 依赖数据库，启动阶段通过DB进行分配; 如自定义实现, 则DB非必选依赖。

图7

7.美团叶子

美团的叶子分布式ID生成组件(图8)基于雪花算法，做了两个优化方案:叶子分段数据库方案(相比之前的方案，每次都需要读取数据库，使用代理服务器批量获取，优化了双缓存)和叶子雪花方案(主要处理时钟回调问题)。时钟回拨的情况下，该号码将被拒绝并报警)。

优点是全局唯一，高可用、高性能用zookeeper解决了各个服务器时钟回拨的问题，弱依赖zookeeper；缺点是依赖第三方组件，如zookeeper。

图8

8.zookeeper生成一个唯一的ID

Zookeeper主要通过其节点的信息生成序列号，可以生成32位或64位的数据版本号。客户端可以使用这个版本号作为唯一的序列号。

优点是实现原理较为简单，容易实现；缺点是需要依赖zookeeper，并且是多步调用API，如果在竞争较大的情况下，需要考虑使用分布式锁。因此，性能在高并发的分布式环境下，也不甚理想。

一般来说，目前的实现方案主要分为两种:

第一，有中心(比如数据库，包括mysql，redis等。)，其中约束可以用来实现聚类(初始步长)。

二是无中心，确保无冲突(如UUID等。)通过生成足够多的分散数据。

集中式方案的优点是ID数据长度相对较小，数据可以实现自增长趋势。缺点是容易出现并发瓶颈，集群需要实现约定，横向扩展困难。分散式方案的优点是实现简单，没有中心节点造成的性能瓶颈，可扩展性高(可扩展性的限制往往集中在数据的离散问题上)；缺点是数据长度长，无法实现数据的自增长。