分布式场景下的ID生成解决方案

攻城狮Bilbo 09-02 873

前言：

眼前朋友们对“mysql生成uuid”大约比较着重，我们都需要了解一些“mysql生成uuid”的相关资讯。那么小编也在网络上网罗了一些有关“mysql生成uuid””的相关资讯，希望各位老铁们能喜欢，姐妹们一起来了解一下吧！

在服务设计中，经常遇到的一个问题就是如何生成一个全局唯一的ID，例如订单号，流水号等。对于ID的要求主要有以下几点：

全局唯一，不会存在冲突；快速生成，能够满足高并发场景下的需求；能够满足分布式场景下的业务需求；ID生成服务能够方便的扩容缩容。最好基本有序；能够附加一些业务信息，例如时间，系统标识等；能够应对测试环境的一些特殊需求，如跳日，日期回拨等。

我们简单分析下常见的实现方式：

UUID

最熟悉的应该是UUID，UUID 是通用唯一识别码（Universally Unique Identifier）的缩写。按照UUID规范，UUID的实现方式一共有四种：

基于时间戳的UUID。这个UUID是基于时间戳，随机数和当前机器mac地址计算得到的，可以保证全球范围内的唯一性。但是，使用mac地址为带来安全问题。

DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。

基于名字的UUID（MD5），通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了：相同名字空间中不同名字生成的UUID的唯一性；不同名字空间中的UUID的唯一性；相同名字空间中相同名字的UUID重复生成是相同的。

根据随机数，或者伪随机数生成UUID。这个是存在重复概率的，虽然概率很小，但是还是存在的。

基于名字的UUID（SHA1），这个与第三种类似。

以java为例，常用的java.util.UUID这个类支持第三、四两种UUID的生成方法：

java.util.UUID中UUID的实现

如源码所示，分别是随机UUID和基于名字的UUID。

UUID是优点在于使用相对简单，每个服务自己生成。

缺点我认为主要有几个：

生成的ID是随机的，不能从字面上看出一些附加信息。索引效率比较低；不满足基本有序；存储占用空间大，这个在目前看来不是主要问题。数据库自增主键

数据库提供了一种自增主键的方式来生成ID，这种方式的主要优点是生成简单，ID是严格有序的。

方式比较简单，这里不再赘述。

可能存在问题的地方我认为主要有几点：

在分库分表场景下不太合适。第一个问题是存在多库的场景下可能存在ID冲突的问题，虽然可以通过设定步长解决，但是不利于数据库扩展；数据库自增ID存在一个上限，mysql默认的应该是Int，默认长度是32位。大概是几十亿，这个上限应该很容易达到。数据库压力大。每次生成ID都需要读写数据库，数据库压力较大，容易成为瓶颈。基于redis实现

Redis 的 INCR 命令支持 “INCR AND GET” 原子操作。利用这个特性，我们可以在 Redis 中存序列号，让分布式环境中多个取号服务在 Redis 中通过 INCR 命令来实现取号；同时 Redis 是单进程单线程架构，不会因为多个取号方的 INCR 命令导致取号重复。因此，基于 Redis 的 INCR 命令实现序列号的生成基本能满足全局唯一与单调递增的特性，并且性能还不错。

但是不足的地方是不能够附加一些业务信息，例如时间，业务系统信息等。

基于ZOOKEEPER实现

下图是一个经典的基于zk实现的ID生成器的解决方案，参考了网友的实现：

基于Zookeeper的ID生成方案

这个方案的缺点也很明显，无法附加业务信息，且只能产生32位的ID。

SnowFlake

SnowFlake是Twitter开源的一个全局ID生成算法，长度为64位，在java中刚好是一个long型。

SnowFlake中各个bit位的含义如下图（图片来自于网络）所示：

SnowFlake

主要分为四段：

第一位是0，暂时未使用；

接下来是41位，表示与1970-01-01 00:00:00:000的毫秒时间数差，也可以指定时间，够用69年；