❖ 原理

Snowflake 雪花算法，由Twitter提出并开源，可在分布式环境下用于生成ID的算法。该算法生成的是一个64位的ID。在同一个进程中，它首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认为是总体有序的，这就保证了对索引字段的插入的高效性。例如 MySQL 的 Innodb 存储引擎的主键。

使用雪花算法生成的主键，二进制表示形式包含 4 部分，从高位到低位分表为：1bit 符号位、41bit 时间戳位、10bit 工作进程位以及 12bit 序列号位。

• 符号位（1bit）

  预留的符号位，恒为零。

• 时间戳位（41bit）

  41 位的时间戳可以容纳的毫秒数是 2 的 41 次幂，一年所使用的毫秒数是：365 * 24 * 60 * 60 * 1000。通过计算可知：Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L); 结果约等于 69.73 年。Apache ShardingSphere 的雪花算法的时间纪元从 2016 年 11 月 1 日零点开 始，可以使用到 2086 年，相信能满足绝大部分系统的要求。

• 工作进程位（10bit）

  该标志在 Java 进程内是的，如果是分布式应用部署应保证每个工作进程的 id 是不同的。该值默认为0，可通过属性设置。

• 序列号位（12bit）

  该序列是用来在同一个毫秒内生成不同的 ID。如果在这个毫秒内生成的数量超过 4096 (2 的 12 次幂)，那么生成器会等待到下个毫秒继续生成。

使用SnowFlake的优点是其空间占用更小，且具备一定有序性，这对于类似MySQL数据库是比较友好的。

因为其生成策略需参考当前时间，当服务器时钟回拨会导致产生重复序列，因此默认分布式主键生成器提供了一个大容忍的时钟回拨毫秒数。如果时钟回拨的时间超过大容忍的毫秒数阈值，则程序报错；如果在可容忍的范围内，默认分布式主键生成器会等待时钟同步到后一次主键生成的时间后再继续工作。大容忍的时钟回拨毫秒数的默认值为 0，可通过属性设置。

❖ 数据库案例-ShardingSphere

原生数据库产品，大多没有支持SnowFlake，但可通过外部方式引用进来。例如在开源项目 Apache ShardingSphere 中可通过规则的配置，在其分片表中使用 SnowFlake作为主键生成器。参考如下配置

CREATE SHARDING TABLE RULE t_order(

RESOURCES(ds_3307,ds_3308),

SHARDING_COLUMN=order_id,TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=4)),

KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME= Snowflake,PROPERTIES("worker-id"=123)))

);

CREATE TABLE t_order (

order_id varchar(50) NOT NULL,

user_id int NOT NULL,

status varchar(50) DEFAULT NULL,

PRIMARY KEY (order_id)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;