目录

• 1. 问题
• 2.ID生成规则部分硬性要求
• 3.ID号生成系统的可用性要求
• 4.一般通用方案
• • 4.1UUID
  • 4. 数据库自增主键
• 5. 基于Redis生成全局id策略
• 6. snowflake
• • 6.1 概述
  • 6.2 结构
  • 6.3 源码
  • 6.4 工程落地经验
  • • 6.4.1 糊涂工具包
    • 6.4.2 springboot整合雪花算法
    • 1.POM
    • 2.核心代码IdGeneratorSnowflake
    • • 1. 业务类
      • 2. Controller
      • 3. util类
      • 4. 启动类
      • 4.YML
      • 5. 测试
  • 6.5 优缺点
• 7. 其他补充

1. 问题

为什么需要分布式全局唯一ID以及分布式ID的业务需求？
在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。

如在美团点评的今日、支付、餐饮、酒店；
猫眼电影等产品的系统数据中日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息

特别一点的如订单、骑手、优惠券也需要有唯一ID做标识。
此时一个能够生成全局唯一ID的系统是非常重要的。

2.ID生成规则部分硬性要求

即软件要求

1. 全局唯一
   不能出现重复的ID号，既然是唯一标识，这是基本的要求
2. 趋势递增
   在MySQL的InnoDB引擎中使用的是聚集索引，由于多数的RDBMS使用Btree的数据结构来存储索引数据，在主键的选择上我们应该尽量使用有序的主键保证写入性能
3. 单调递增
   保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求
4. 信息安全
   如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定的URL即可
   如果是订单号就更危险了，竞争对手可以知道我们一条的单量
   所以在一些应用场景下，需要ID无规则不规则，让竞争对手不好猜。
5. 含时间戳
   快速了解ID的生成时间

3.ID号生成系统的可用性要求

即硬件要求

高可用
发一个获取分布式ID的请求，服务器就要保证99.999%的情况下给我创建一个唯一的分布式ID
低延迟
发一个请获取分布式ID的请求，服务器要快，极速
高QPS
假如并发一口气10万个创建分布式ID请求同时过来，服务器要顶得住并且成功创建10万个分布式ID

4.一般通用方案

4.1UUID

是什么
UUID（Universally Unique Identifier）的标准式包含32个16进制数字，以连字号分为五段，形式为a-b-c-d-e的36个字符
例子： de999f9a-baed-47c4-b06f-aaf3ac81a363

性能非常高，本地生成，没有网络消耗

如果只是考虑唯一性是可以的，但是它入数据库性能差

为什么无序的UUID会导致入库性能差？

1. 无序，无法预测他的生成顺序，不能生产递增有序的数字
   首先分布式id一般都会作为主键，但是安装mysql官方推荐主键要尽量越短越好，UUID每一个都很长，所以不推荐
2. 主键，ID作为主键时在特定的环境会存在一些问题
   比如做DB主键的场景下，UUID就i非常不适用MySQL官方有明确的建议，主键尽量越短越好36个字符长度的UUID不符合要求
3. 索引，B+树索引的分裂
   既然分布式id是主键，然后主键包含索引的，mysql的索引是通过b+树来实现的，每一次UUID数据的插入，为了查询的优化，都会对索引底层的b+树进行修改，因为UUID数据是无序的，所以每一次UUID数据的插入都会对主键底层的b+树进行很大的修改，这一点很不好。插入完全无序，不但会导致一些中间节点产生分裂，也会白白创造出很多不饱和的节点，这样大大降低了数据库插入的性能。

4. 数据库自增主键

单机
在分布式里面，数据库自增ID的机制主要原理是：数据库自增ID和mysql数据库的replace into实现的。

这里的replace into和insert功能类似
不同点在于：replace into首先尝试插入数据库列表中，如果发现表中已经有此行数据（根据主键或唯一索引判断）则先删除，再插入，否则直接插入新数据。

REPLACE INTO的含义是插入一条记录，如果表中唯一索引的值遇到冲突，则替换老数据

CREATE TABLE t_test(id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,stub CHAR(1) NOT NULL DEFAULT '',UNIQUE KEY stub(stub)
)SELECT * FROM t_test;REPLACE INTO t_test(stub) VALUES('b');
SELECT LAST_INSERT_ID();

第一次执行REPLACE INTO

第二次执行REPLACE INTO


uuid：只有唯一性，趋势递增

mysql：唯一性，递增

集群分布式
数据库的自增ID机制适合作分布式ID吗？不适合

1. 系统的水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做？
   假设现在只有一台机器，发号为1，2，3，4，5（步长是1），这个时候需要扩容机器一台。可以这样做：把第二台机器的初始值设置的比第一台机器超过很多，貌似还好，现在想象一下如果我们线上有100台机器，这个时候需要扩容该怎么做？简直是噩梦，所以系统水平扩展方案复杂难以实现。
2. 数据库压力还是很大，每次获取ID都要读写一次数据库，非常影响性能，不符合分布式ID里面的低延迟和高QPS的规则（在高并发下，如果都去数据库获取id，那是非常影响性能的）

5. 基于Redis生成全局id策略

1. 因为Redis是单线程的天生保证原子性，可以使用原子操作INCR和INCRBY来实现
2. 集群分布式

注意：在Redis集群情况下，同样和MySQL一样需要设置不同的增长步长，同时key一定要设置有效期

可以使用Redis集群来获取更高的吞吐量。
假如一个集群中有5台Redis，可以初始化每台Redis的值分别是1，2，3，4，5，然后步长都是5。

各个Redis的生成ID为：
A.1,6,11,16,21
B.2,7,12,17,22
C.3,8,13,18,23
D.4,9,14,19,24
E.5,10,15,20,25

6. snowflake

Twitter的分布式自增ID算法snowflake（雪花算法）

6.1 概述

twitter的snowflake解决了这种需求，最初Twitter把存储系统从MySQL迁移到Cassandra（由Facebook开发一套分布式NoSQL数据库系统）因为Cassandra没有顺序ID生成机制，所以开发了这样一套全局唯一ID生成服务

Twitter的分布式雪花算法SnowFlake，经测试snowflake每秒能够产生26万个自增可排序的ID

1. twitter的SnowFlake生成能够按照时间有序生成
2. SnowFlake算法生成id的结果是一个64bit大小的正数，为一个Long型（转换成字符串后的长度最后19）.
3. 分布式系统内不会产生ID碰撞（由datacenter和workerId作区分）并且效率高。

分布式系统中，有一些需要使用全局唯一ID的场景，生成ID的基本要求

1. 在分布式环境下必须全局且唯一。
2. 一般都需要单调递增，因为一般唯一ID都会存到数据库，而Innodb的特性就是将内存存储在主键索引树上的叶子节点，而且是从左往右，递增的，所以考虑到数据库性能，一般生成的id也最好是单调递增。为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，就是相对较长，另外UUID一般是无序的。
3. 可能还会需要无规则，因为如果使用唯一ID作为订单号，为了不能让别人知道一天的订单量是多少，就需要用到这个规则。

6.2 结构

号段解析：
1bit.
不用，因为二进制中最高位是符号位，1表示负数，0表示正数。
生成的id一般都是用整数，所以最高位固定为0。

41bit——时间戳，用来记录时间戳，毫秒级。

• 41位可以表示2⁴¹-1个数字
• 如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0到2⁴¹-1，减1是因为可表示的数值范围是从0开始算的，而不是1
• 也就是说41位可以表示2⁴¹-1个毫秒的值，转化成单位年制是（2⁴¹-1）/（1000606024365）=69年

10bit——工作机器id，用来记录工作机器id

• 可以部署在2¹⁰=1024个节点，包括5位datacenterId和5位workerId
• 5位（bit）可以表示的最大整数时2⁵-1=31,即可用0，1，2，3，……31这32个数字，来表示不同的datecenterId或workerId

12bit——序列号，序列号用来记录同毫秒内产生的不同id

• 12位（bit）可以表示的最大正整数是2¹²-1=4095，即可以用0，1，2，3，……4095这4096个数字，用来表示同一机器、同一时间戳（毫秒）内产生的4096个ID序号

SnowFlake可以保证：
所有生成的id按时间趋势递增
整个分布式系统内不会产生重复id（因为datacenterId和workerId来做区分）

6.3 源码

/*** twitter的snowflake算法 -- java实现* * @author beyond* @date 2016/11/26*/
public class SnowFlake {/*** 起始的时间戳*/private final static long START_STMP = 1480166465631L;/*** 每一部分占用的位数*/private final static long SEQUENCE_BIT = 12; //序列号占用的位数private final static long MACHINE_BIT = 5;   //机器标识占用的位数private final static long DATACENTER_BIT = 5;//数据中心占用的位数/*** 每一部分的最大值*/private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);/*** 每一部分向左的位移*/private final static long MACHINE_LEFT = SEQUENCE_BIT;private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;private long datacenterId;  //数据中心private long machineId;     //机器标识private long sequence = 0L; //序列号private long lastStmp = -1L;//上一次时间戳public SnowFlake(long datacenterId, long machineId) {if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");}if (machineId > MAX_MACHINE_NUM || machineId < 0) {throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0");}this.datacenterId = datacenterId;this.machineId = machineId;}/*** 产生下一个ID** @return*/public synchronized long nextId() {long currStmp = getNewstmp();if (currStmp < lastStmp) {throw new RuntimeException("Clock moved backwards.  Refusing to generate id");}if (currStmp == lastStmp) {//相同毫秒内，序列号自增sequence = (sequence + 1) & MAX_SEQUENCE;//同一毫秒的序列数已经达到最大if (sequence == 0L) {currStmp = getNextMill();}} else {//不同毫秒内，序列号置为0sequence = 0L;}lastStmp = currStmp;return (currStmp - START_STMP) << TIMESTMP_LEFT //时间戳部分| datacenterId << DATACENTER_LEFT       //数据中心部分| machineId << MACHINE_LEFT             //机器标识部分| sequence;                             //序列号部分}private long getNextMill() {long mill = getNewstmp();while (mill <= lastStmp) {mill = getNewstmp();}return mill;}private long getNewstmp() {return System.currentTimeMillis();}public static void main(String[] args) {SnowFlake snowFlake = new SnowFlake(2, 3);for (int i = 0; i < (1 << 12); i++) {System.out.println(snowFlake.nextId());}}
}

6.4 工程落地经验

6.4.1 糊涂工具包

官网

6.4.2 springboot整合雪花算法

1.POM

cn.hutoolhutool-all5.8.11

2.核心代码IdGeneratorSnowflake

1. 业务类

package com.asule.hutusnowflake.service;/*** 简要描述** @Author: ASuLe* @Date: 2023/1/24 13:42* @Version: 1.0* @Description: 文件作用详细描述....*/
public interface OrderService {String getIDBySnowFlake();
}

package com.asule.hutusnowflake.service.impl;import com.asule.hutusnowflake.service.OrderService;
import com.asule.hutusnowflake.util.IdGeneratorSnowFlake;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;/*** 简要描述** @Author: ASuLe* @Date: 2023/1/24 13:44* @Version: 1.0* @Description: 文件作用详细描述....*/
@Service
public class OrderServiceImpl implements OrderService {@Autowiredprivate IdGeneratorSnowFlake idGenerator;@Overridepublic String getIDBySnowFlake() {ExecutorService threadPool = Executors.newFixedThreadPool(5);for (int i = 1; i <= 20; i++) {threadPool.submit(()->{System.out.println(idGenerator.snowflakeId());});}threadPool.shutdown();return "hello snowflake";}
}

2. Controller

package com.asule.hutusnowflake.controller;import com.asule.hutusnowflake.service.OrderService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;/*** 简要描述** @Author: ASuLe* @Date: 2023/1/24 13:42* @Version: 1.0* @Description: 文件作用详细描述....*/
@RestController
public class OrderController {@Autowiredprivate OrderService orderService;@RequestMapping("/snowflake")public String index(){return orderService.getIDBySnowFlake();}
}

3. util类

package com.asule.hutusnowflake.util;import cn.hutool.core.lang.Snowflake;
import cn.hutool.core.net.NetUtil;
import cn.hutool.core.util.IdUtil;
import jakarta.annotation.PostConstruct;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;/*** 简要描述** @Author: ASuLe* @Date: 2023/1/24 13:45* @Version: 1.0* @Description: 文件作用详细描述....*/
@Component
@Slf4j
public class IdGeneratorSnowFlake {private long workerId = 0;private long datacenterId = 1;private Snowflake snowflake = IdUtil.getSnowflake(workerId, datacenterId);//post构造完了开始执行，加载初始化工作@PostConstructpublic void init() {try {workerId = NetUtil.ipv4ToLong(NetUtil.getLocalhostStr());log.info("当前机器的workerId：{}" , workerId);} catch (Exception e) {e.printStackTrace();log.warn("当前机器的workerId失败" , workerId);workerId = NetUtil.getLocalhostStr().hashCode();}}public synchronized long snowflakeId(){return snowflake.nextId();}public synchronized long snowflakeId(long workerId,long datacenterId){Snowflake snowflake = IdUtil.getSnowflake(workerId,datacenterId);return snowflake.nextId();}public static void main(String[] args) {System.out.println(new IdGeneratorSnowFlake().snowflakeId());}
}

4. 启动类

package com.asule.hutusnowflake;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;@SpringBootApplication
public class HutuSnowFlakeApplication {public static void main(String[] args) {SpringApplication.run(HutuSnowFlakeApplication.class, args);}}

4.YML

server:port: 7777

5. 测试

6.5 优缺点

优点：

• 毫秒数在高位，自增序列在地位，整个ID都是趋势递增的。
• 不依赖数据库第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
• 可以根据自身业务特性分配bit位，非常灵活。

缺点：

• 依赖机器始终，如果机器时钟回拨，会导致重复ID生成
• 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，有时候会出现不是全局递增的情况
  （此缺点可以认为无所谓，一般分布式ID只要求趋势递增，不会严格要求递增，90%的需求都只要求趋势递增）

7. 其他补充

解决时钟回拨问题

• 百度开源的分布式唯一ID生成器UidGenerator
• Leaf美团点评分布式ID生成系统