業(yè)務(wù)系統(tǒng)訂單號,流水號生成規(guī)則

一、前言

在實(shí)際的軟件系統(tǒng)開發(fā)過程中,由于業(yè)務(wù)的需要,我們經(jīng)常需要生成業(yè)務(wù)單號,例如訂單號、快遞單號、入庫單號、投訴服務(wù)單號等等。

本文主要以討論電商的訂單編號規(guī)則為案例,其他類型的服務(wù)編號設(shè)計(jì)思路其實(shí)也是相似的。

設(shè)計(jì)業(yè)務(wù)系統(tǒng)訂單號,流水號注意事項(xiàng)

  • 唯一性:確保在分布式環(huán)境下ID不重復(fù)
  • 有序性:ID隨時(shí)間遞增,有利于數(shù)據(jù)庫索引性能
  • 可讀性:包含時(shí)間信息,便于人工識別
  • 擴(kuò)展性:支持業(yè)務(wù)前綴和類型區(qū)分
  • 性能:本地生成,無網(wǎng)絡(luò)開銷
  • 高并發(fā):考慮線程安全,避免阻塞

根據(jù)實(shí)際業(yè)務(wù)需求,可以調(diào)整各部分位數(shù)分配,例如增加機(jī)器ID位數(shù)或減少序列號位數(shù)。

訂單命名的幾種規(guī)則總結(jié)

  • 不重復(fù):這點(diǎn)我相信大家都懂,必須全局唯一
  • 安全性:訂單號需要做到不容易被人為的猜測或者推測出來,例如訂單號就是流水號的話,那么別人就很容易從訂單號推測出公司的整體運(yùn)營情況。
  • 禁用隨機(jī)碼:很多人分析生成訂單號的時(shí)候,第一個(gè)念頭肯定是不重復(fù)唯一性,那么第二個(gè)念頭可能就是安全性,想要同時(shí)滿足前兩者,很容易想到使用隨機(jī)碼,隨機(jī)碼從一定程度來說,更安全、不重復(fù)性更高,但是可讀性差,有概率會發(fā)生重復(fù)。
  • 防止并發(fā):針對系統(tǒng)的并發(fā)業(yè)務(wù)場景(如秒殺),需要做到并發(fā)場景下,訂單編號生成快速、不重復(fù)等要求
  • 控制位數(shù):訂單號的位數(shù)盡量在 10 位 ~ 18 位之間。太短的情況下,如果交易量過大,很難做到防止重復(fù),太長可讀性差、意義也不大。

二、方案實(shí)踐

2.1、方案一:UUID

UUID 是Universally Unique Indentifier的縮寫,翻譯為通用唯一識別碼,顧名思義 UUID 是一個(gè)用于記錄唯一標(biāo)識一條的數(shù)據(jù),其按照開放軟件基金會(OSF)指定的標(biāo)準(zhǔn)進(jìn)行計(jì)算,用到了以太網(wǎng)卡地址(MAC)、納秒級時(shí)間、芯片 ID 碼和許多可能的數(shù)字。

總的來說,UUID 碼由以下三部分組成:

  • 當(dāng)前日期和時(shí)間
  • 時(shí)鐘序列
  • 全局唯一的 IEEE 機(jī)器識別碼(如果有網(wǎng)卡從網(wǎng)卡獲得,沒有網(wǎng)卡則通過其他方式獲得)

UUID 的標(biāo)準(zhǔn)形式包含 32 個(gè) 16 進(jìn)制數(shù)字,以連字號分為五段,示例:00000191-adc6-4314-8799-5c3d737aa7de。

以java為例,通過以下方式即可生成:

String uuid = UUID.randomUUID().toString();

這種方案,雖然實(shí)現(xiàn)簡單、方便;但是數(shù)據(jù)庫查詢效率非常差,而且內(nèi)容長,在實(shí)際的項(xiàng)目場景開發(fā)中,一般用于于記錄用戶的手機(jī)設(shè)備ID等硬件信息!

因此不推薦采用 uuid 來生成訂單編號!

2.2、方案二:數(shù)據(jù)庫自增

所謂數(shù)據(jù)庫自增,意思是在數(shù)據(jù)庫中給某個(gè)列設(shè)置為自增列,并且給該列設(shè)置一個(gè)初始值,代碼層面無需任何特殊處理,以 Mysql 的用戶表 ID 列為例,可以通過如下方式在創(chuàng)建表的時(shí)候生產(chǎn)。

CREATE TABLE `tb_user` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

這種通過數(shù)據(jù)庫自增方式實(shí)現(xiàn)唯一值,在單體服務(wù)下是沒有問題,但是在大流量分布式服務(wù)環(huán)境下,并發(fā)性能很低。

以后數(shù)量大的時(shí)候,需要對 mysql 進(jìn)行分庫分表,此時(shí)訂單號會重復(fù),因此不推薦采用!

2.3、方案三:雪花算法

Snowflake(中文簡稱:雪花算法) 是 Twitter 內(nèi)部的一個(gè) ID 生算法,可以通過一些簡單的規(guī)則保證在大規(guī)模分布式情況下生成唯一的 ID 號碼。其內(nèi)部結(jié)構(gòu)如下:


image.png

可以很清晰的看出,Snowflake 由 4個(gè)部分組成:

  • 第一部分:bit 值,為未使用的符號位
  • 第二部分:由 41 位的時(shí)間戳(毫秒)構(gòu)成,它的取值是當(dāng)前時(shí)間相對于某一時(shí)間的偏移
  • 第三部分:表示工作機(jī)器 id,由服務(wù)節(jié)點(diǎn) id 和數(shù)據(jù)中心 id 組合而成
  • 第四部分:表示每個(gè)工作機(jī)器每毫秒生成的序列號 ID,同一毫秒內(nèi)最多可生成生產(chǎn) 4095 個(gè) ID。

由于在 Java 中 64bit 的整數(shù)是 long 類型,因此在 Java 中 SnowFlake 算法生成的 id 就是 long 來存儲的。

SnowFlake 算法可以保證

  • 1.所有生成的 id 按時(shí)間趨勢遞增
  • 2.整個(gè)分布式系統(tǒng)內(nèi)不會產(chǎn)生重復(fù)id(因?yàn)橛蟹?wù)節(jié)點(diǎn) id 和數(shù)據(jù)中心 id 來做區(qū)分)

需要注意的是
在分布式環(huán)境中,5 個(gè) bit 位的 datacenter 和 worker 表示最多能部署 31 個(gè)數(shù)據(jù)中心,每個(gè)數(shù)據(jù)中心最多可部署 31 臺節(jié)點(diǎn)。

  • 41 位的二進(jìn)制長度最多能表示2^41 -1毫秒即 69 年,所以雪花算法最多能正常使用 69 年,為了能最大限度的使用該算法,在使用的時(shí)候,應(yīng)該為其指定一個(gè)開始時(shí)間,不然會發(fā)生重復(fù)!
import java.time.Instant;
 
/**
 * 分布式ID生成器(基于雪花算法改進(jìn))
 */
public class DistributedIdGenerator {
    // 起始時(shí)間戳(2024-01-01)
    private final static long START_TIMESTAMP = 1704067200000L;
    
    // 機(jī)器ID所占位數(shù)
    private final static long WORKER_ID_BITS = 5L;
    
    // 數(shù)據(jù)中心ID所占位數(shù)
    private final static long DATACENTER_ID_BITS = 5L;
    
    // 序列號所占位數(shù)
    private final static long SEQUENCE_BITS = 12L;
    
    // 最大機(jī)器ID
    private final static long MAX_WORKER_ID = ~(-1L << WORKER_ID_BITS);
    
    // 最大數(shù)據(jù)中心ID
    private final static long MAX_DATACENTER_ID = ~(-1L << DATACENTER_ID_BITS);
    
    // 機(jī)器ID左移位數(shù)
    private final static long WORKER_ID_SHIFT = SEQUENCE_BITS;
    
    // 數(shù)據(jù)中心ID左移位數(shù)
    private final static long DATACENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;
    
    // 時(shí)間戳左移位數(shù)
    private final static long TIMESTAMP_LEFT_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATACENTER_ID_BITS;
    
    // 序列號掩碼
    private final static long SEQUENCE_MASK = ~(-1L << SEQUENCE_BITS);
    
    private final long workerId;
    private final long datacenterId;
    private long sequence = 0L;
    private long lastTimestamp = -1L;
    
    public DistributedIdGenerator(long workerId, long datacenterId) {
        if (workerId > MAX_WORKER_ID || workerId < 0) {
            throw new IllegalArgumentException("workerId不合法");
        }
        if (datacenterId > MAX_DATACENTER_ID || datacenterId < 0) {
            throw new IllegalArgumentException("datacenterId不合法");
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }
    
    public synchronized long nextId() {
        long timestamp = timeGen();
        
        if (timestamp < lastTimestamp) {
            throw new RuntimeException("時(shí)鐘回?fù)墚惓?);
        }
        
        if (timestamp == lastTimestamp) {
            sequence = (sequence + 1) & SEQUENCE_MASK;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }
        
        lastTimestamp = timestamp;
        
        return ((timestamp - START_TIMESTAMP) << TIMESTAMP_LEFT_SHIFT)
                | (datacenterId << DATACENTER_ID_SHIFT)
                | (workerId << WORKER_ID_SHIFT)
                | sequence;
    }
    
    private long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }
    
    private long timeGen() {
        return Instant.now().toEpochMilli();
    }
    
    /**
     * 將生成的ID轉(zhuǎn)換為訂單號
     */
    public static String convertToOrderNo(long id) {
        return "ORD" + id;
    }
}

使用

// 修改日期格式
private static final String DATE_FORMAT = "yyyyMMddHHmmss";
 
// 修改序列號長度
private static final int SERIAL_NUMBER_LENGTH = 4;
 
// 修改訂單前綴
private static final String ORDER_PREFIX = "ORD";

在高并發(fā)的環(huán)境下,Snowflake 算法可以生成全局唯一的訂單編號,但是他的長度達(dá)到21位,因此不推薦采用,但是可以用它來生成主鍵 ID,是完全沒有問題的!

2.4、方案四:分布式組件

要想在分布式環(huán)境下生成一個(gè)唯一的訂單編號,我們可以通過分布式組件的方式,來幫忙我們生成全局唯一的訂單號,例如我們可以采用 redis 分布式緩存組件中的incr命令,來幫我們生成一個(gè)全局自增長的序列號!

實(shí)現(xiàn)邏輯如下:

//基于某個(gè)key實(shí)現(xiàn)自增長
String res = jedis.get(key);
if (StringUtils.isBlank(res)) {
    jedisClient.set(key, INIT_ID);//設(shè)置自增長的初始值,INIT_ID 是初始值
    jedisClient.expire(key, seconds);//設(shè)置過期時(shí)間,seconds 是多少秒過期
}
long orderId = jedis.incr(key);//存在就生成+1的訂單號

這種方式生成的自增長序列號,非常的快,可以很好的滿足大流量環(huán)境下的編號要求唯一的特性!
剩下的主要工作就是我們?nèi)绾稳ピO(shè)計(jì)一個(gè)訂單號規(guī)則!
在設(shè)計(jì)規(guī)則之前,我們先來看看互聯(lián)網(wǎng)幾個(gè)大廠的訂單號格式。

  • 京東商城訂單號格式:157444499
  • 蘇寧易購訂單號格式:2000839647
  • 凡客誠品訂單號格式:213052230059
  • 銀泰網(wǎng)訂單號格式:10030522161715
  • 小米訂單號格式:1111218032345170

我們先來分析一下凡客誠品和銀泰網(wǎng)的訂單號生成規(guī)則。凡客誠品和銀泰網(wǎng)訂單號都含有 0522,這是因?yàn)檫@ 2 張訂單都是2013年5月22號下的訂單。

基本猜測一下,凡客的訂單規(guī)則是:業(yè)務(wù)編碼+年的后2位+月+日+訂單數(shù);泰網(wǎng)的訂單號規(guī)則:年的第三位數(shù)+業(yè)務(wù)編碼+年的后1位+月+日+訂單數(shù);而京東商城和蘇寧易購的訂單號看不出規(guī)則。

最后我們來分析一下小米訂單號1111218032345170,可以將其分解成四個(gè)部分1——111218—03234—5170。

  • 第一部分,1 表示購買,2 表示退貨。
  • 第二部分,表示 2011 年 12 月 18 日下的單,前面兩位省掉了。
  • 第三部分,時(shí)間戳對應(yīng)00:53:54,換算成秒是03234秒。
  • 最后一部分,表示在同一秒內(nèi)下的第 5170 單,也就是說,小米認(rèn)為,在一秒內(nèi)不會超過一萬個(gè)訂單。

總結(jié)起來,小米的訂單規(guī)則是:業(yè)務(wù)編碼+年的后 2 位+月+日+秒+訂單數(shù),固定長度為16,這種訂單號規(guī)則可以保證 100 年不會重復(fù)!

同樣的,借鑒小米的訂單號規(guī)則,我們也可以生成同樣的訂單號,實(shí)現(xiàn)過程如下:

import org.apache.commons.lang3.StringUtils;
import java.time.Duration;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;

public class OrderNoGeneratorUtil {

    private static final DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd");

    public static String generate() {
        //獲取當(dāng)前時(shí)間
        LocalDateTime currentTime = LocalDateTime.now();
        //格式化當(dāng)前時(shí)間為【年+月+日】
        String originDateStr = LocalDateTime.now().format(formatter);
        //計(jì)算當(dāng)前時(shí)間走過的秒
        Duration duration = Duration.between(LocalDate.now().atStartOfDay(), currentTime);
        // 獲取相差的秒數(shù)
        long differSecond = duration.getSeconds(); 
        //獲取【年+月+日+秒】,秒的長度不足補(bǔ)充0
        String yyMMddSecond = originDateStr +  StringUtils.leftPad(String.valueOf(differSecond), 5, '0');

        //獲取【業(yè)務(wù)編碼: 1:表示購買、2:表示退貨】 + 【年+月+日+秒】,作為自增key;
        String prefixOrder = "1" + yyMMddSecond;
        //通過key,采用redis自增函數(shù),實(shí)現(xiàn)單秒自增;不同的key,從0開始自增,同時(shí)設(shè)置60秒過期
        Long incrId = redisUtils.saveINCR(prefixComplaint, 60);
        //生成訂單編號
        return  prefixOrder + StringUtils.leftPad(String.valueOf(incrId), 4, '0');
    }
}

此訂單編號可以保證大流量環(huán)境下全局唯一、生成速度非常的快、支持高并發(fā)環(huán)境,同時(shí)還支持按時(shí)間排序!

三、總結(jié)

通過上面的示例演示,我們可用做一個(gè)詳細(xì)的總結(jié)!


image.png

綜上所述,在大流量的環(huán)境下,我們可以通過 redis 的incr函數(shù)實(shí)現(xiàn)序列號自增的特性,同時(shí)搭配訂單的設(shè)計(jì)規(guī)則,從而保證高并發(fā)的環(huán)境下,訂單唯一性!

參考:
https://www.zhihu.com/question/21128632/answer/2293633424

https://blog.csdn.net/dongjing991/article/details/147897247

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容