关于java:电商系统中ID是如何生成的

分布式 ID，咱们可能都听过分布式系统，分布式，分布式 ID 可能比拟少，因为业务，方向以及系统维护的方面登程，当初的互联网中的我的项目，少数都须要一个全局且惟一，有增量趋势的 标识。目前用的可能是 MySQL 的自增主键，UUID，工夫戳等，然而对于日益增长的音讯零碎，点评，领取等具体操作，都须要一个稳固，全局惟一，且有显著自增趋势的 ID 作为惟一标识。

## 一个分布式全局 ID 的硬性要求

其中信息安全，可能有的小伙伴不太理解，你每次申请获取的 ID（查问操作），这个如果是递增，咱们就能直观的判断出有信息，多少人，这是第多少个等，这属于敏感信息泄露的领域，平安还是很重要的；

规定咱们确定之后，咱们就要求生成这个 ID 零碎的要求，
之前是对于生成 单个一个 ID 的要求，

## 对 ID 系统生成的可用性要求

因为是存在于分布式系统的，那也就是咱们比拟相熟的，

高可用：发动一个获取分布式 ID 的申请时，必须保障服务器在 99.999% 的时候给我创立胜利

低提早：获取分布式 ID, 服务器响应疾速，不能有高提早，会有误差

高并发：一秒钟能够获取 10 万左右的 ID, 而且要胜利，服务器要扛得住

### 情景再现：

面试中，对于面试者做过的我的项目，面试官个别会采纳聊集群，QPS 等状况验证，我的项目的真实性，其中分布式 ID 就属于具体实现了，个别会问：

你们我的项目是，散布式微服务，集群化部署，电商的这个零碎中对于订单，领取等 全局 ID 是如何生成的？

雪花算法 snowFlake；

## 当初零碎罕用的 ID 生成形式：

数据库自增，UUID，工夫戳；Redis 集群

### (1) 数据库自增（mysql 自增）

其中数据库自增，对于单体零碎，后盾零碎用的比拟多，因为并发小，应用人数也少，适宜于小零碎，QPS 个别几十到一百左右的，

毛病：

 对于数据敏感的场景不宜应用，且支撑不了分布式场景，自增之后还是会还原为原来的数值

### (2) UUID

UUID 用的是比拟广泛的一个 ID, 因为全局惟一，然而它存在很多的问题

UUID 的毛病：

无序，且无奈预测生成程序，无奈无效的出现递增趋势

存储，字段很长，消耗数据库资源，对于特点环境存在一些问题，

长处：只剩下全局惟一了

###（3）工夫戳
个别能够应用工夫戳加具体的业务 ID 来规定，然而用的也比拟少

（4）基于 Redis 集群生成策略

因为 Redis 个性是基于单线程，所以用它生成 ID 操作是原子性的，
集群化能够实现，

通过设施集群的增长步长，起始值，就能够

比方 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,…

尽管能够实现，然而配置 Redis 集群后，要实现数据失落怎么办，key 的生效工夫等等，
不是不能做，是杀鸡焉用牛刀，对的；

而后就到了咱们明天的主题：

(5)Twitter 开源的 snowflake;

Snowflake（雪花）是一项服务，用于为 Twitter 内的对象（推文，间接音讯，用户，汇合，列表等）生成惟一的 ID。这些 IDs 是惟一的 64 位无符号整数，它们 基于工夫，而不是程序的。残缺的 ID 由工夫戳，工作机器编号和序列号组成。当在 API 中应用 JSON 数据格式时，请务必始终应用 id_str 字段而不是 id，这一点很重要。这是因为解决 JSON 的 Javascript 和其余语言计算大整数的形式造成的。如果你遇到 id 和 id_str 仿佛不匹配的状况，这是因为你的环境曾经解析了 id 整数，并在解决的过程中仔细分析了这个数字。

Twitter 的分布式雪花算法 SnowFlake, 经测试 snowflake 每秒可能产生 26 万 个自增可排序的 ID1、twitter 的 SnowFlake 生成 ID 可能依照工夫有序生成 2、SnowFlake 算法生成 id 的后果是一个 64bit 大小的整数，为一个 Long 型（转换成字符串后长度最多 19).3、分布式系统内不会产生 ID 碰撞（由 datacenter 和 workerld 作辨别）并且效率较高。

分布式系统中，有一些须要应用全局惟一 ID 的场景，生成 ID 的根本要求

1. 在分布式的环境下必须全局且惟一。

比照
2. 个别都须要枯燥递增，因为个别惟一 ID 都会存到数据库，而 Intodb 的个性就是将内容存储在主键索引树上的叶子节点，而且是从左往右，递增的，所以思考到数据库性能，个别生成的 id 也最好是枯燥递增。为了避免 ID 抵触能够应用 36 位的 UUID, 然而 UUID 有一些毛病，首先他绝对比拟长，另外 UUID- 般是无序的

snowflake 是中能够用 69 年是否成立？

雪花算法能够高度惟一和可用性工夫长：
作比拟，41 位的 1 二进制数字，对于十进制来说，是多少呢；
十进制的数字是：2199023255551
https://tool.lu/hexconvert/ 进制转换的工具箱

我做了个 demo 来证实:

其中次要设置的是 10 位的工作过程位；-

个别分为数据中心和机器位

生成 snowFlake 的 ID

咱们以 springboot 的我的项目来构建这个 snowFlake 的 ID 生成，

依赖：

 <!-- hutool 对于 sonwFlake 的应用     -->
        <dependency>
            <groupId>cn.hutool</groupId>
            <artifactId>hutool-captcha</artifactId>
            <version>5.6.0</version>
        </dependency>

这里咱们示意的是 Java 代码库中，hutool 的类库，调用曾经封装好的 IdUtil 就好

package com.generate;

import cn.hutool.core.lang.Snowflake;
import cn.hutool.core.net.NetUtil;
import cn.hutool.core.util.IdUtil;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;


/**
 * 生成全局 ID
 * 雪花算法 Tiwwer
 */

@Component
@Slf4j
public class SnowFlakeUtil {

    // 次要配置工作位十位，其中 5 位是机器位（节点或者是具体哪台机器），5 位数数据中心

    private Long workerID = 0L;

    private Long datecenter = 1L;

    private Snowflake snowflake = IdUtil.createSnowflake(workerID, datecenter);

    @PostConstruct
    private void init() {

        try {
            // 以后机器的 IP
            workerID = NetUtil.ipv4ToLong(NetUtil.getLocalhostStr());
            log.info("以后机器的 workerID{}", workerID);
        } catch (Exception e) {log.warn("获取机器 ID 失败", e);
            workerID = Long.valueOf(NetUtil.getLocalhost().hashCode());
            log.info("以后机器 workID", workerID);
        }


    }

    // 简略版本
    public synchronized Long createSnowFlakeID() {
        // 生成的 ID 加锁 synchronized
        return snowflake.nextId();}

    // 全局版本的
    public synchronized long showFlakeID(long workId, long datacenterID) {Snowflake snowflake = IdUtil.createSnowflake(workerID, datecenter);
        return snowflake.nextId();}


    public static void main(String[] args) {System.out.println(new SnowFlakeUtil().createSnowFlakeID());
//        1401136955063926784
    }


}

这里是简略的一个版本，与实在我的项目中有差别，差别次要是体现在参数配置中，

尽管雪花算法能够生成，惟一且自增的 ID , 然而它也存在问题，是对于工夫戳的；

总结：

长处：

​ 1. 不依赖与第三方零碎（MySQL，Redis 等），稳定性，生成 ID 的性能十分高

​ 2. 毫秒数在高位，自增序列在低位，整个 ID 都是有趋势递增的；

毛病：

依赖于机器时钟，也就是对表工夫，如果机器回拨，会导致反复 ID 生成；

这种状况个别会产生在分布式环境中，每台机器上的时钟不可能齐全同步，有时候会呈现不是全局递增的状况

然而对于中小公司，此毛病能够疏忽，个别会要求趋势递增，并不会严格要求递增；

snowFlake 的优化

对于时钟回拨的状况，国内的大厂也修复了这个雪花算法的问题，比方

百度开源的 Uid Generator

Leaf– 美团点评分布式生成 ID

两者都是在雪花算法的根底上，优化和改良；

实用于

对于一般公司，200 人高低的，体制次要对于研发人员，都能够应用 snowFlake, 配置具体 ID 生成，规定其中位数的默认值，

尤其是对于时钟回拨的，（工夫始终在走），重点在配置，抉择，解决异样，就能够实现

寄语

今日的分享就到这里了，学海无涯难行洲，唯有保持方可成；
我是卢卡，咱们下期见