分布式高并发场景id 订单号生成策略总结

落日映苍穹つ 2023-06-03 04:57 11阅读 0赞

大概总结一下，待更新

分布式高并发场景下id要求：1 全局唯一  2 趋势递增 3 效率高（生成，使用，索引）4 控制并发

常用策略一：uuid

UUID是java.util下的一个类，使用非常简单。

public static void main(String[] args) {            
        System.out.println(UUID.randomUUID());     
    }

运行了一次结果如下，29915e2e-ec4c-4f15-ad6c-db18d52db695，返回了一个长度为36的字符串，实际toString方法另外加了4个横线方便阅读，实际长度是32个字符。通过阅读源码，uuid构造函数传入类一个长度16的byte数组，uuid长度是128bit。

优点：使用简单，不依赖其他组件，不影响数据库拓展。

缺点：数据库索引效率低，无意义，占空间大，集群环境可能会重复。

策略二：数据库自增

这个很好理解，数据库设置id为int，自增。

优点：无需编码，索引友好，性能还行

缺点：。。。

策略三：sonwflake

twitter开源的分布式id生成算法，返回long类型id。[https://github.com/twitter-archive/snowflake][https_github.com_twitter-archive_snowflake]

id由以下内容组成：

*  时间-41位（毫秒级精度（带有自定义历元）使我们拥有69年的时间）
 *  配置的机器ID-10位-最多可提供1024台机器
 *  序列号-12位-每台计算机每4096翻转一次（具有保护功能，避免在同一毫秒内翻转）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2lsb3ZlY3I3_size_16_color_FFFFFF_t_70][]

64bit，8字节，如图。(转换成字符串后长度最多19)

第一位高位不用固定是0，后41位是时间戳，毫秒级；然后10位是节点id，最多支持部署1024个节点，包括5位datacenterId和5位workerId；最后12位是序列号，递增的数字。

。。。。

优点：

缺点：依赖机器时间，时间回拨可能导致id重复。

策略四 redis 自增

利用incr(key) 对key的值进行递增，并返回增长数值，如果key不存在，则则创建并赋值为0。

redis单线程原子性。

可以看一下常用app订单号之类的值，基本都是用年月日+xxxx+自增数值这种格式，

优点：性能优，不会重复，方便根据业务拓展

缺点：引入第三方依赖，网络开销，redis做高可用。

[https_github.com_twitter-archive_snowflake]: https://github.com/twitter-archive/snowflake
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2lsb3ZlY3I3_size_16_color_FFFFFF_t_70]: /images/20230601/455f79ac8326424e9a5a42f252198998.png