mysql snowflake_一篇文章彻底搞懂snowflake算法及百度美团的最佳实践

写在前面的话

一提到分布式ID自动生成方案，大家肯定都非常熟悉，并且立即能说出自家拿手的几种方案，确实，ID作为系统数据的重要标识，重要性不言而喻，而各种方案也是历经多代优化，请允许我用这个视角对分布式ID自动生成方案进行分类：

实现方式

完全依赖数据源方式

ID的生成规则，读取控制完全由数据源控制，常见的如数据库的自增长ID，序列号等，或Redis的INCR/INCRBY原子操作产生顺序号等。

半依赖数据源方式

ID的生成规则，有部分生成因子需要由数据源(或配置信息)控制，如snowflake算法。

不依赖数据源方式

ID的生成规则完全由机器信息独立计算，不依赖任何配置信息和数据记录，如常见的UUID，GUID等

实践方案

实践方案适用于以上提及的三种实现方式，可作为这三种实现方式的一种补充，旨在提升系统吞吐量，但原有实现方式的局限性依然存在。

实时获取方案

顾名思义，每次要获取ID时，实时生成。

简单快捷，ID都是连续不间断的，但吞吐量可能不是最高。

预生成方案

预先生成一批ID放在数据池里，可简单自增长生成，也可以设置步长，分批生成，需要将这些预先生成的数据，放在存储容器里(JVM内存，Redis，数据库表均可)。

可以较大幅度地提升吞吐量，但需要开辟临时存储空间，断电宕机后可能会丢失已有ID，ID可能有间断。

方案简介

以下对目前流行的分布式ID方案做简单介绍

数据库自增长ID

属于完全依赖数据源的方式，所有的ID存储在数据库里，是最常用的ID生成办法，在单体应用时期得到了最广泛的使用，建立数据表时利用数据库自带的auto_increment作主键，或是使用序列完成其他场景的一些自增长ID的需求。

优点：非常简单，有序递增，方便分页和排序。

缺点：分库分表后，同一数据表的自增ID容易重复，无法直接使用(可以设置步长，但局限性很明显)；性能吞吐量整个较低，如果设计一个单独的数据库来实现 分布式应用的数据唯一性，即使使用预生成方案，也会因为事务锁的问题，高并发场景容易出现单点瓶颈。

适用场景：单数据库实例的表ID(包含主从同步场景)，部分按天计数的流水号等；分库分表场景、全系统唯一性ID场景不适用。

Redis生成ID

也属于完全依赖数据源的方式，通过Redis的INCR/INCRBY自增原子操作命令，能保证生成的ID肯定是唯一有序的，本质上实现方式与数据库一致。

优点：整体吞吐量比数据库要高。

缺点：Redis实例或集群宕机后，找回最新的ID值有点困难。

适用场景：比较适合计数场景，如用户访问量，订单流水号(日期+流水号)等。

UUID、GUID生成ID

UUID：按照OSF制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。由以下几部分的组合：当前日期和时间(UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同)，时钟序列，全局唯一的IEEE机器识别号(如果有网卡，从网卡获得，没有网卡以其他方式获得)

GUID：微软对UUID这个标准的实现。UUID还有其它各种实现，不止GUID一种，不一一列举了。

这两种属于不依赖数据源方式，真正的全球唯一性ID

优点：不依赖任何数据源，自行计算，没有网络ID，速度超快，并且全球唯一。

缺点：没有顺序性，并且比较长(128bit)，作为数据库主键、索引会导致索引效率下降，空间占用较多。

适用场景：只要对存储空间没有苛刻要求的都能够适用，比如各种链路追踪、日志存储等。

4、snowflake算法(雪花算法)生成ID

属于半依赖数据源方式，原理是使用Long类型(64位)，按照一定的规则进行填充：时间(毫秒级)+集群ID+机器ID+序列号，每部分占用的位数可以根据实际需要分配，其中集群ID和机器ID这两部分，在实际应用场景中要依赖外部参数配置或数据库记录。

优点：高性能、低延迟、去中心化、按时间有序

缺点：要求机器时钟同步(到秒级即可)

适用场景：分布式应用环境的数据主键

雪花ID算法听起来是不是特别适用分布式架构场景？照目前来看是的，接下来我们重点讲解它的原理和最佳实践。

snowflake算法实现原理

snowflake算法来源于Twitter，使用scala语言实现，利用Thrift框架实现RPC接口调用，最初的项目起因是数据库从mysql迁移到Cassandra，Cassandra没有现成可用 的ID生成机制，就催生了这个项目，现有的github源码有兴趣可以去看看。

snowflake算法的特性是有序、唯一，并且要求高性能，低延迟(每台机器每秒至少生成10k条数据，并且响应时间在2ms以内)，要在分布式环境(多集群，跨机房)下使用，因此snowflake算法得到的ID是分段组成的：

与指定日期的时间差(毫秒级)，41位，够用69年

集群ID + 机器ID， 10位，最多支持1024台机器

序列，12位，每台机器每毫秒内最多产生4096个序列号

如图所示：

1bit：符号位，固定是0，表示全部ID都是正整数

41bit：毫秒数时间差，从指定的日期算起，够用69年，我们知道用Long类型表示的时间戳是从1970-01-01 00:00:00开始算起的，咱们这里的时间戳可以指定日期，如2019-10-23 00:00:00