ID 选择，你做对了吗？

ID 是标识符（identifier）的前缀，它代表一个可以唯一识别一个对象或者物体的名称。在软件系统中，ID 用于对一组信息进行标识，它是信息系统里最底层、最基础的概念，从系统诞生到消亡，都与 ID 息息相关。

但我们经常会发现，在很多系统的早期，都会采用自增的 Mysql Int ID，笔者可以认为这是对 ID 未做过深入思考的选择，而到后期时，才发现 ID 变更已经几乎不可能实现。由于信息系统相互引用无处不在，如果 ID 选择不当，带来的负面影响往往非常深远。还有一些常见的坑，比如聚合层服务要聚合不同底层服务 ID 时，才发现它们类型不同；资源被黑客遍历攻击，才发现早期 ID 使用的是自增的 Int 类型 ; Int64 传递至 JavaScript 发现错误等等。

笔者调查了一些 ID 选择的情况，如下表，各有不同。那么 ID 该怎么选呢，如类型、长度等属性，还有其他属性要考量的么？ID 的选择，并非技术复杂度问题，更多是对 ID 属性的认知程度，以及统一规范问题。本文会重点对 ID 的属性进行分析。

我们列出 5 个属性来分析，并按事物的性质与事物之间关系的角度将 ID 属性分为两类：

• 自身属性：类型、长度

• 领域属性：唯一性、稀疏度、递增性

唯一性是 ID 的本质属性，ID 一定能帮助我们在其领域内识别唯一对象，否则就不是标识符。

唯一性的实现需要各种生成策略。目前，业界已经有多种解决方案。

对于 Int 类型，最简单的生成策略可以依赖数据库中间件，如依赖 Mysql 的自增 ID，但依赖数据库中间件的缺点也很明显，不支持水平分片架构，且对数据库有依赖，每种数据库可能实现不同，一旦数据库切换时涉及到代码的修改，则不利于扩展。而且依赖数据库的自增 ID 也会有安全问题，容易被遍历。更加有效成熟的解决方案，是依赖集中式发号器，被广泛使用的发号器有通常被使用的雪花算法及其变种，网传实际测试每秒最多生成 26w 个 id，可以有效的生成全局的 ID。

String 类型 ID 的生成方式已经被标准化，主要依赖 SDK 生成。如 UUID 被开放软件基金会（OSF）标准化，各种语言均提供按标准实现的 SDK，它由时间戳、网卡、时钟序列等构成标准，确保了在分布式环境下，单机高速生成，支持 100ns 级并发；MongoDB 的主键是 STRING 类型，其标准为：ObjectId = epoch 时间 + 机器标识 + 进程号 PID + 计数器，依赖不同语言的驱动来生成。

我们经常会听到一种说法，ID 应该是无意义的。这里的无意义，有人阐述为 ID 中不应该包含任何的具体场景信息，避免 ID 在可标识数量上降低而唯一性受到挑战。对此说法，笔者不能认同，因为在分布式 ID 生成的策略里，包含具体场景是必须的，我们通常会利用时间场景和机器场景来保证分布式场景下 ID 各种属性的要求。比如上文 UUID 嵌入网卡、时间等具体的场景信息。下图经典的 Snowflake 算法，也嵌入 41 位时间戳和 5 位数据中心的场景信息，用来保证唯一性和递增趋势：

笔者认为 ID 的无意义是指 ID 不应当包含具体的业务信息，从而避免因业务的发展，出现对 ID 的唯一性挑战，如避免使用邮箱做 ID、或用户账号内包含用户生日等。一个领域的 ID 在其他领域被引用时，会具有外部引用的业务意义，也要避免。如下面案例，用户会员表直接使用用户 ID 做其数据库主键 ID，当新需求希望一个用户，需要同时拥有多个类型的会员时，就扩展艰难了。

UserID     // 主键, 账号 ID, 全局唯一Membership // 该账号的会员类型

类型选择无外乎：字符类型、整形。这两种类型的本质，都是支撑人类思维能力所形成的标准。

整数是人类计数体系的标准，它不但天然具有符合自然公理的完整运算规则，而且有来自 CPU、操作系统、编译器、甚至中间件等各个层级的直接支持，如当代的 CPU 一般具有 64 位宽的整数型寄存器。Mysql 提供可以自增的整形主键，Redis 提供整数对象池来节省存储资源。这些支持，使整数存储上更加节省资源，运算上更加高效，其运算时间复杂度通常为 O(1)。

字符是有人类语言体系的标准，天生为了标识而存在。字符不具有天然的计算规则，其常见的比较策略是逐一比较，算法时间复杂度为 O(n)。字符的实现方式，依赖不同的编码标准及操作系统的实现，有 ASCII、Unicode、UTF-8 等。字符可以标识更大范围，理论上是无限空间。

对比

整形类型的优点在于充分利用底层基础设施的性能优化措施，使得其支持系统或中间件达到最佳状态，带来这一优势的是计算机体系的支撑，自然也会有它的约束。字符类型的优点在于标识空间的巨大，当然这一优势，是以存储空间和计算性能为代价的。具体对比如下：

从运算属性来看，整形天然具有运算属性的优势，整形的对比时间复杂度为 O(1)。字符类型不具备天然的运算属性，其比较通常要自行定义排序规则。如 MySQL 和 Oracle 数据库中，字符串类型比较规则是按照相同位置的字符的 ASCII 码值的大小进行排序的，时间复杂度为 O(N)。

从标识空间来看，Int64 必然受到最大 64 位的限制，空间虽然非常巨大，但依旧是有限的。字符类型可以标识的空间是无限的，也容易嵌入业务信息。那么字符表示更广范围的基础是什么？当然是占用了更多的二进制存储空间。笔者也很期待，像从 16 位、32 位，到发展到今天的 64 位一样，未来会出现 128 位的整形，那时候 Int 的空间也足够大了，可以和 UUID 直接转换。

从约束度来看，Int 类型是标准最为严格的，可发挥空间小，位数也都受到较为严格的约束，属于强约束 ID， 难以嵌入业务信息。String 类型，容易被扩展或违反约束，这一条，对 Int 既是劣势，也是优势。

选择

随着计算机 CPU 和存储的快速发展，存储和计算复杂度，都不再成为影响的关键因素时，String 和 Int 类型作为 ID，各自的优势变得并非十分明显，所以，互联网上也开始经常出现争论：究竟使用哪种类型更好。笔者建议：

• 统一最为重要，参考存留的系统，如果大量的使用 Int，建议相关联的系统仍保持使用 Int，如果大量使用 String、建议使用 String。

• 参考中间件的基础特性。如选择的 ID 是否可以使 Mysql、MongoDB 等中间件是否可以达到最佳状态。如果大量基础设施是 Mysql，则递增的 int 类型作为 ID 更合适；如果都是 MongoDB，则可以使用其自动生成的字符类型 ID 。

• 分布式海量数据的 ID，可以采用字符类型，字符类型分布式 ID 生成更加简单，如服务链路的日志追踪。需要埋入较多业务数据的，应当使用字符类型，如阿里 SPM 埋点

一条更通用的建议是：首先，优先考虑统一，要尽量避免一个关联系统内，Int 和 String 类型共存的情况。其次，优先考虑使用 Int 类型，Int 类型的约束更为严格，被中间件的支撑度和可迁移性更好，而且 Int 类型对海量数据支撑能力通常也是足够的，如雪花算法及各种改进，每秒可以生成几十万个 ID，满足绝大多数分布式场景。

在存储已经不是瓶颈的今天，采用 Int 类型时，建议强制使用 Int64，笔者经历过两次公司级别将用户 Id 由 Int32 改造为 Int64 的过程。

采用 String 类型时，建议制定约束规范，有以下长度可以借鉴：UUID 通常是 36 位，MongoDB 的 ObjectID 是 24 位、Yuotube 的视频 ID 是 11 位。

这里存在一个常见的坑：JavaScript 语言对 Int64 支持度仍然不够，其使用 53 位以上的 Int64 类型会有精度损失。因为 JavaScript 语言内置数值类型依赖 IEEE 754 规范的双精度浮点数，IEEE 754 规范字节分配如下图。最大的安全整数是 52 位 fraction bit 刚好用到的情况，即：$$2^{53} - 1 = 9007199254740991$$。

JavaScript 提供了解决方案 BigInt 来解决，但预计需要到 2025 年，浏览器更新覆盖率才能全面使用。

https://caniuse.com/bigint?fileGuid=t3TV9DvWCJxTpgjy

出于数据库中间件索引和连续存储的要求，ID 的递增趋势是非常有必要的。递增的实现并不复杂，ID 标准生成方案已经完全可以做到支撑递增且高性能。递增趋势有两种，如下：

• 非严格递增，要求整体上后生成的 ID 大于之前生成 ID。由于多数 RDBMS 使用 B-tree 的数据结构来存储索引数据，索引页的数据是按逻辑大小连续存储的，如果使用非自增主键，MySQL 不得不为了将新纪录插到合适位置而移动数据，频繁的移动会大大降低数据库的性能。分布式 ID 生成算法通常会将 ID 内嵌入一定的时间戳，来实现递增趋势，如雪花算法、MongoDB 的主键。

• 严格递增，要求保证下一个 ID 一定大于上一个 ID，例如事务版本号、IM 增量消息、排序等特殊需求，需要严格递增的逻辑来确保业务正确。严格递增的这一约束，通常只能单机集中式实现。

增加 ID 之间的稀疏度，可以提高恶意遍历、碰撞攻击的成本。稀疏度越高则效果越好。例如 YouTube 使用 11 位字符来作为视频编码标识，11 位字符有超过 73 亿种可能的组合，目前在 YouTube 上有 5 到 100 亿个视频，这意味着，如果依赖随机输入 11 个字符组成 URL 的方式获得视频，平均每尝试七百万次才可以访问到资源。

分布式 ID 生成策略所生产的 ID 稀疏度通常足够，参见上文的 snowflake 示例图，理论上单机每毫秒理论最多生成 2^12 个 ID，再加上机器位，则每秒可生成的 ID 数目理论上为 40 亿。对大部分信息资源而言，每秒生成的 ID 散落在 40 亿的 ID 空间内，稀疏度是够用的。例如我司的 PGC 内容生产而言，其稀疏度通常在 100 亿以上。

ID 稀疏度能大大降低未公开的资源，被猜测到的行为，再去寻找漏洞进行单点突破的行为。比如还未上架的课程已经被黑客公开了，会是件非常被动的事情。而且，如果数据的总量对外是机密的，ID 的稀疏度，还可以避免被黑客猜到数据总量。

但 ID 稀疏度不能解决已公开资源被遍历问题，已公开的资源很容易通过爬虫收集 ID。完全公开的资源，通常是没必要考虑进行安全限制的，比如上文表格中看到微博的用户，美团的商品仍采用连续的 Int，因为其不需要保密。保密级别高的资源，仅靠稀疏度来确保权限远远不够，需要配合的措施有很多，如关键接口对指定 Token 限制访问频率等、APP 使用防混淆配合签名加解密等。

Mysql 自增 ID 的稀疏度是 1，作为需要防止遍历的资源 ID 不是合适的。但笔者也见过一些公司做了另外一个极端：一定要把所有的 ID（如雪花算法生成的稀疏度在 100 亿以上）转换成 String 类型的加密 ID 对 Web 端输出，这种做法都是想当然的决策，除了徒增复杂度外并无太多价值。

对微服务体系来说，当各种不同服务的 ID 需要聚合时，引入域标识是有必要的，因为我们也需要对不同的 ID 去不同的微服务引用资源。

ID 域的主要作用是标识这个 ID 属于哪个业务领域，对应哪个微服务。ID 引入域，就像编程里语言引入 namespacing 一样，那是否需要引入多个层级的域概念呢？未尝不可。但是层级越多，复杂度越高，通常建议只引如一个域层级，标识 ID 属于不同业务领域即可。当 ID 传递至聚合层业务时，域标识和 ID 一并进行被传递或存储，但不允许存在 ID 到对应服务的反查服务。

AType  // 域标识，属于业务分类概念，对应于微服务划分ID     // 该商品类型下 ID

除了本质属性外，其他几种 ID 属性都有可能变更：类型、长度、稀疏度、递增性。不同属性的变更成本代价不一样。

类型变更通常最为困难，因为 Int 和 String 类型的本质不同，其支持系统如数据库的实现方式差别巨大，除变更代码外，历史数据处理都困难重重。由于 ID 的引用无处不在，变更类型，所需的关联系统的改造也非常困难，甚至不可能，比如改变 ID 类型，会影响用户的购买记录、历史记录、收藏记录，甚至大数据团队的日常报表等系统的存储。

稀疏度、递增性的变更，只需要变更 ID 生成方式即可。如我们很容易可以将 ID 生成方式，由 Mysql 的自增，变更为使用发号器来生成，来增加稀疏度。但历史数据的处理仍会比较困难。

长度的变更相对容易，如 Int32 变更为 Int64，不会涉及业务逻辑变化，也无需处理历史数据。前文也提到，笔者经历过两次公司级 int32 至 int64 的变更，推动的都很顺利。有些人也在担心 snowflake 41 位时间戳可以使用 69 年，但笔者认为，到时候 128 位的整形也应该普及了， ID 再次进行一次长度的变更即可。

整个系统初始便选定合适的 ID 生成策略，使得各种属性，稀疏度、长度、生成方式，类型等满足要求自然最好。如果未选好，而且也无法变更。该怎么办呢？兼容。兼容一定会存在关联 ID 的转换，大的原则是但要尽可能的减少双 ID 的扩散范围。参考如下两个方案：

• 将对应关系存储下来。如将数字 ID 进行加盐 Hash（或生成对应 UUID）生成合适的 String ID，直接关联存储在数据库内，但要尽可能的减少双 ID 的扩散范围。

• 使用规则或者对称加密算法进行可逆转换，不做存储。Int 可以较为容易利用规则或算法转换为 String 类型，反之不能，因为毕竟巨大的 String 空间是无法依赖算法被压缩入较小 Int 空间。本方案一定要注意，避免新 ID 被相关系统存入数据库，包括客户端的数据库，以免导致无法变更算法。

实践中，虽不理想，但也各有场景需求。

如下图，当聚合层服务聚合不同的资源 ID 时，有的底层服务用 Int，有的资源用 String，可以使用方案一，聚合服务将 ID 转换保留在自己服务体内，对外输出仍使用原有类型，避免了双 ID 的扩散。笔者反对源服务提供两种类型 ID 的做法，这样会造成双 ID 扩散和引用关系复杂，带来的一系列难以维护的问题。

如下图，底层服务和聚合层服务都已经存储大量连续（不安全） ID，后期安全问题暴露，可以采用方案二。该做法首先要止损，将 ID 生成方式由原来的自增，改为发号器；再采用 SDK 对 ID 进行加密对外输出，以减少被遍历风险。但从下图可以看到，各 SDK 采用相同秘钥，破坏了系统之间的边界，而且秘钥变更也有引发故障的风险，属于“瘸子里挑将军”。如果读者有更合适的实践，比如接口适配等，欢迎留言探讨。

ID 的选择，往往不经意却影响深远。它并非是技术复杂度问题，更多是对 ID 属性的认知程度，以及架构的约束规范问题。特别是采用微服务体系时，各服务独立设计，ID 选择更容易失控。

本文从类型、长度、唯一性、稀疏度、递增性的角度对 ID 进行全面分析，并提出一些通用的约束。文中也提出了一个粗略的选择建议：业务生产类，建议使用 Int64 类型，采用发号器生成，并维护递增趋势。分布式海量数据且领域较窄的，可以采用标准的 UUID 等 String 类型 ID。

兼容的大原则是减少双 ID 的扩散，文中所列的实践，您可能也会遇到过，并有自己心得，欢迎留言探讨，更欢迎留言您遇到的其他场景及解决方案。

奇正，曾在 Adobe 、百度任高级工程师，现任某互联网公司技术总监，致力于业务架构、项目管理等方向。

点个在看少个 bug 👇