血的教訓，一次訂單號重復的事故我差點被開除

作者：鴨血粉絲Tang 2021-12-28 06:55:09

開發前端

系統出現了兩個一模一樣的訂單號，訂單的內容卻不是一樣的，而且事情發生的不止一次，被老板發現之后，當月績效被扣光!

[[442441]]

本文轉載自微信公眾號「Java極客技術」，作者鴨血粉絲Tang。轉載本文請聯系Java極客技術公眾號。

一、介紹

曾經有個項目，我們線上出了一次事故，這個事故的表象大體是這樣的：

系統出現了兩個一模一樣的訂單號，訂單的內容卻不是一樣的，而且事情發生的不止一次，被老板發現之后，當月績效被扣光!

事后經過排查，產生這個問題，總結主要有兩個原因：

數據庫訂單表里面，對訂單編號沒有設置唯一鍵約束
生成訂單編號的時候，采用了隨機數，導致有部分單號發生了重復

針對這個問題也做了一些研究，有一些收獲想分享給大家!

本文主要以討論電商的訂單編碼規則為案例，其他類型的服務編號設計思路其實也是相似的。

不廢話，直接干貨!

訂單命名的幾種規則總結：

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

二、方案實踐

上面提到了訂單編號生成的規則，那要實現這樣的規則，該如何實現會比較好呢?

下面總結幾種常見的處理方式，我們一一分析!

2.1、方案一：UUID

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

總的來說，UUID 碼由以下三部分組成：

當前日期和時間
時鐘序列
全局唯一的 IEEE 機器識別碼(如果有網卡從網卡獲得，沒有網卡則通過其他方式獲得)

UUID 的標準形式包含 32 個 16 進制數字，以連字號分為五段，示例：00000191-adc6-4314-8799-5c3d737aa7de。

以java為例，通過以下方式即可生成：

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

這種方案，雖然實現簡單、方便;但是數據庫查詢效率非常差，而且內容長，在實際的項目場景開發中，一般用于于記錄用戶的手機設備ID等硬件信息!

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

2.2、方案二：數據庫自增

所謂數據庫自增，意思是在數據庫中給某個列設置為自增列，并且給該列設置一個初始值，代碼層面無需任何特殊處理，以 Mysql 的用戶表 ID 列為例，可以通過如下方式在創建表的時候生產。

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;

這種通過數據庫自增方式實現唯一值，在單體服務下是沒有問題，但是在大流量分布式服務環境下，并發性能很低。

以后數量大的時候，需要對 mysql 進行分庫分表，此時訂單號會重復，因此不推薦采用!

2.3、方案三：雪花算法

Snowflake(中文簡稱：雪花算法) 是 Twitter 內部的一個 ID 生算法，可以通過一些簡單的規則保證在大規模分布式情況下生成唯一的 ID 號碼。其內部結構如下：

可以很清晰的看出，Snowflake 由 4個部分組成：

第一部分：bit 值，為未使用的符號位
第二部分：由 41 位的時間戳(毫秒)構成，它的取值是當前時間相對于某一時間的偏移
第三部分：表示工作機器 id，由服務節點 id 和數據中心 id 組合而成
第四部分：表示每個工作機器每毫秒生成的序列號 ID，同一毫秒內最多可生成生產 4095 個 ID。

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

SnowFlake 算法可以保證：

所有生成的 id 按時間趨勢遞增
整個分布式系統內不會產生重復id(因為有服務節點 id 和數據中心 id 來做區分)

需要注意的是：

在分布式環境中，5 個 bit 位的 datacenter 和 worker 表示最多能部署 31 個數據中心，每個數據中心最多可部署 31 臺節點。
41 位的二進制長度最多能表示2^41 -1毫秒即 69 年，所以雪花算法最多能正常使用 69 年，為了能最大限度的使用該算法，在使用的時候，應該為其指定一個開始時間，不然會發生重復!

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

2.4、方案三：分布式組件

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

實現邏輯如下：

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

這種方式生成的自增長序列號，非常的快，可以很好的滿足大流量環境下的編號要求唯一的特性!

剩下的主要工作就是我們如何去設計一個訂單號規則!

在設計規則之前，我們先來看看互聯網幾個大廠的訂單號格式。

京東商城訂單號格式：157444499

蘇寧易購訂單號格式：2000839647

凡客誠品訂單號格式：213052230059

銀泰網訂單號格式：10030522161715

小米訂單號格式：1111218032345170

我們先來分析一下凡客誠品和銀泰網的訂單號生成規則。

凡客誠品和銀泰網訂單號都含有 0522，這是因為這 2 張訂單都是2013年5月22號下的訂單。

基本猜測一下，凡客的訂單規則是：業務編碼+年的后2位+月+日+訂單數;泰網的訂單號規則：年的第三位數+業務編碼+年的后1位+月+日+訂單數;而京東商城和蘇寧易購的訂單號看不出規則。

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

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

總結起來，小米的訂單規則是：業務編碼+年的后 2 位+月+日+秒+訂單數，固定長度為16，這種訂單號規則可以保證 100 年不會重復!

同樣的，借鑒小米的訂單號規則，我們也可以生成同樣的訂單號，實現過程如下：

//獲取當前時間 
Date currentTime  = new Date(); 
//格式化當前時間為【年的后2位+月+日】 
String originDateStr = new SimpleDateFormat("yyMMdd").format(currentTime ); 
//計算當前時間走過的秒 
Date startTime =  new SimpleDateFormat("yyyyMMdd").parse(new SimpleDateFormat("yyyyMMdd").format(originDate)); 
long differSecond = (currentTime.getTime() - startTime.getTime()) / 1000; 
//獲取【年的后2位+月+日+秒】，秒的長度不足補充0 
String yyMMddSecond = originDateStr +  StringUtils.leftPad(String.valueOf(differSecond), 5, '0'); 
 
//獲取【業務編碼】 + 【年的后2位+月+日+秒】，作為自增key； 
String prefixOrder = sourceType + "" + yyMMddSecond; 
//通過key，采用redis自增函數，實現單秒自增；不同的key，從0開始自增，同時設置60秒過期 
Long incrId = redisUtils.saveINCR(prefixComplaint, 60); 
//生成訂單編號 
String orderNo = prefixOrder + StringUtils.leftPad(String.valueOf(incrId), 4, '0');

此訂單編號可以保證大流量環境下全局唯一、生成速度非常的快、支持高并發環境，同時還支持按時間排序!

三、總結

通過上面的示例演示，我們可用做一個詳細的總結!

綜上所述，在大流量的環境下，我們可以通過 redis 的incr函數實現序列號自增的特性，同時搭配訂單的設計規則，從而保證高并發的環境下，訂單唯一性!

四、參考

1、如何正確設計一個訂單號???

2、并發下的唯一訂單號生成規則

責任編輯：武曉燕來源： Java極客技術

事故訂單號績效

血的教訓 ，一次訂單號重復的事故我差點被開除