关于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 来规定，然而用的也比拟少

因为 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 的生效工夫等等，
不是不能做，是杀鸡焉用牛刀，对的；

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

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 位的工作过程位；-

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

咱们以 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 生成；

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

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

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

百度开源的 Uid Generator

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

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

实用于

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

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

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

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

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

(5)Twitter 开源的 snowflake;

生成 snowFlake 的 ID

总结：

长处：

毛病：

snowFlake 的优化

寄语