血的教訓(xùn) ，一次訂單號(hào)重復(fù)的事故我差點(diǎn)被開(kāi)除
本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲Tang。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。
一、介紹
曾經(jīng)有個(gè)項(xiàng)目，我們線上出了一次事故，這個(gè)事故的表象大體是這樣的：
系統(tǒng)出現(xiàn)了兩個(gè)一模一樣的訂單號(hào)，訂單的內(nèi)容卻不是一樣的，而且事情發(fā)生的不止一次，被老板發(fā)現(xiàn)之后，當(dāng)月績(jī)效被扣光!
事后經(jīng)過(guò)排查，產(chǎn)生這個(gè)問(wèn)題，總結(jié)主要有兩個(gè)原因：
- 數(shù)據(jù)庫(kù)訂單表里面，對(duì)訂單編號(hào)沒(méi)有設(shè)置唯一鍵約束
- 生成訂單編號(hào)的時(shí)候，采用了隨機(jī)數(shù)，導(dǎo)致有部分單號(hào)發(fā)生了重復(fù)
針對(duì)這個(gè)問(wèn)題也做了一些研究，有一些收獲想分享給大家!
本文主要以討論電商的訂單編碼規(guī)則為案例，其他類型的服務(wù)編號(hào)設(shè)計(jì)思路其實(shí)也是相似的。
不廢話，直接干貨!
訂單命名的幾種規(guī)則總結(jié)：
- 不重復(fù)：這點(diǎn)我相信大家都懂，必須全局唯一
- 安全性：訂單號(hào)需要做到不容易被人為的猜測(cè)或者推測(cè)出來(lái)，例如訂單號(hào)就是流水號(hào)的話，那么別人就很容易從訂單號(hào)推測(cè)出公司的整體運(yùn)營(yíng)情況。
- 禁用隨機(jī)碼：很多人分析生成訂單號(hào)的時(shí)候，第一個(gè)念頭肯定是不重復(fù)唯一性，那么第二個(gè)念頭可能就是安全性，想要同時(shí)滿足前兩者，很容易想到使用隨機(jī)碼，隨機(jī)碼從一定程度來(lái)說(shuō)，更安全、不重復(fù)性更高，但是可讀性差，有概率會(huì)發(fā)生重復(fù)。
- 防止并發(fā)：針對(duì)系統(tǒng)的并發(fā)業(yè)務(wù)場(chǎng)景(如秒殺)，需要做到并發(fā)場(chǎng)景下，訂單編號(hào)生成快速、不重復(fù)等要求
- 控制位數(shù)：訂單號(hào)的位數(shù)盡量在 10 位 ～ 18 位之間。太短的情況下，如果交易量過(guò)大，很難做到防止重復(fù)，太長(zhǎng)可讀性差、意義也不大。
二、方案實(shí)踐
上面提到了訂單編號(hào)生成的規(guī)則，那要實(shí)現(xiàn)這樣的規(guī)則，該如何實(shí)現(xiàn)會(huì)比較好呢?
下面總結(jié)幾種常見(jiàn)的處理方式，我們一一分析!
2.1、方案一：UUID
UUID 是Universally Unique Indentifier的縮寫，翻譯為通用唯一識(shí)別碼，顧名思義 UUID 是一個(gè)用于記錄唯一標(biāo)識(shí)一條的數(shù)據(jù)，其按照開(kāi)放軟件基金會(huì)(OSF)指定的標(biāo)準(zhǔn)進(jìn)行計(jì)算，用到了以太網(wǎng)卡地址(MAC)、納秒級(jí)時(shí)間、芯片 ID 碼和許多可能的數(shù)字。
總的來(lái)說(shuō)，UUID 碼由以下三部分組成：
- 當(dāng)前日期和時(shí)間
- 時(shí)鐘序列
- 全局唯一的 IEEE 機(jī)器識(shí)別碼(如果有網(wǎng)卡從網(wǎng)卡獲得，沒(méi)有網(wǎng)卡則通過(guò)其他方式獲得)
UUID 的標(biāo)準(zhǔn)形式包含 32 個(gè) 16 進(jìn)制數(shù)字，以連字號(hào)分為五段，示例：00000191-adc6-4314-8799-5c3d737aa7de。
以java為例，通過(guò)以下方式即可生成：
- String uuid = UUID.randomUUID().toString();
這種方案，雖然實(shí)現(xiàn)簡(jiǎn)單、方便;但是數(shù)據(jù)庫(kù)查詢效率非常差，而且內(nèi)容長(zhǎng)，在實(shí)際的項(xiàng)目場(chǎng)景開(kāi)發(fā)中，一般用于于記錄用戶的手機(jī)設(shè)備ID等硬件信息!
因此不推薦采用 uuid 來(lái)生成訂單編號(hào)!
2.2、方案二：數(shù)據(jù)庫(kù)自增
所謂數(shù)據(jù)庫(kù)自增，意思是在數(shù)據(jù)庫(kù)中給某個(gè)列設(shè)置為自增列，并且給該列設(shè)置一個(gè)初始值，代碼層面無(wú)需任何特殊處理，以 Mysql 的用戶表 ID 列為例，可以通過(guò)如下方式在創(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;
這種通過(guò)數(shù)據(jù)庫(kù)自增方式實(shí)現(xiàn)唯一值，在單體服務(wù)下是沒(méi)有問(wèn)題，但是在大流量分布式服務(wù)環(huán)境下，并發(fā)性能很低。
以后數(shù)量大的時(shí)候，需要對(duì) mysql 進(jìn)行分庫(kù)分表，此時(shí)訂單號(hào)會(huì)重復(fù)，因此不推薦采用!
2.3、方案三：雪花算法
Snowflake(中文簡(jiǎn)稱：雪花算法) 是 Twitter 內(nèi)部的一個(gè) ID 生算法，可以通過(guò)一些簡(jiǎn)單的規(guī)則保證在大規(guī)模分布式情況下生成唯一的 ID 號(hào)碼。其內(nèi)部結(jié)構(gòu)如下：
可以很清晰的看出，Snowflake 由 4個(gè)部分組成：
- 第一部分：bit 值，為未使用的符號(hào)位
- 第二部分：由 41 位的時(shí)間戳(毫秒)構(gòu)成，它的取值是當(dāng)前時(shí)間相對(duì)于某一時(shí)間的偏移
- 第三部分：表示工作機(jī)器 id，由服務(wù)節(jié)點(diǎn) id 和數(shù)據(jù)中心 id 組合而成
- 第四部分：表示每個(gè)工作機(jī)器每毫秒生成的序列號(hào) ID，同一毫秒內(nèi)最多可生成生產(chǎn) 4095 個(gè) ID。
由于在 Java 中 64bit 的整數(shù)是 long 類型，因此在 Java 中 SnowFlake 算法生成的 id 就是 long 來(lái)存儲(chǔ)的。
SnowFlake 算法可以保證：
- 所有生成的 id 按時(shí)間趨勢(shì)遞增
- 整個(gè)分布式系統(tǒng)內(nèi)不會(huì)產(chǎn)生重復(fù)id(因?yàn)橛蟹?wù)節(jié)點(diǎn) id 和數(shù)據(jù)中心 id 來(lái)做區(qū)分)
需要注意的是：
- 在分布式環(huán)境中，5 個(gè) bit 位的 datacenter 和 worker 表示最多能部署 31 個(gè)數(shù)據(jù)中心，每個(gè)數(shù)據(jù)中心最多可部署 31 臺(tái)節(jié)點(diǎn)。
- 41 位的二進(jìn)制長(zhǎng)度最多能表示2^41 -1毫秒即 69 年，所以雪花算法最多能正常使用 69 年，為了能最大限度的使用該算法，在使用的時(shí)候，應(yīng)該為其指定一個(gè)開(kāi)始時(shí)間，不然會(huì)發(fā)生重復(fù)!
在高并發(fā)的環(huán)境下，Snowflake 算法可以生成全局唯一的訂單編號(hào)，但是他的長(zhǎng)度達(dá)到21位，因此不推薦采用，但是可以用它來(lái)生成主鍵 ID，是完全沒(méi)有問(wèn)題的!
2.4、方案三：分布式組件
要想在分布式環(huán)境下生成一個(gè)唯一的訂單編號(hào)，我們可以通過(guò)分布式組件的方式，來(lái)幫忙我們生成全局唯一的訂單號(hào)，例如我們可以采用 redis 分布式緩存組件中的incr命令，來(lái)幫我們生成一個(gè)全局自增長(zhǎng)的序列號(hào)!
實(shí)現(xiàn)邏輯如下：
- //基于某個(gè)key實(shí)現(xiàn)自增長(zhǎng)
- String res = jedis.get(key);
- if (StringUtils.isBlank(res)) {
- jedisClient.set(key, INIT_ID);//設(shè)置自增長(zhǎng)的初始值，INIT_ID 是初始值
- jedisClient.expire(key, seconds);//設(shè)置過(guò)期時(shí)間，seconds 是多少秒過(guò)期
- }
- long orderId = jedis.incr(key);//存在就生成+1的訂單號(hào)
這種方式生成的自增長(zhǎng)序列號(hào)，非常的快，可以很好的滿足大流量環(huán)境下的編號(hào)要求唯一的特性!
剩下的主要工作就是我們?nèi)绾稳ピO(shè)計(jì)一個(gè)訂單號(hào)規(guī)則!
在設(shè)計(jì)規(guī)則之前，我們先來(lái)看看互聯(lián)網(wǎng)幾個(gè)大廠的訂單號(hào)格式。
京東商城訂單號(hào)格式：157444499
蘇寧易購(gòu)訂單號(hào)格式：2000839647
凡客誠(chéng)品訂單號(hào)格式：213052230059
銀泰網(wǎng)訂單號(hào)格式：10030522161715
小米訂單號(hào)格式：1111218032345170
我們先來(lái)分析一下凡客誠(chéng)品和銀泰網(wǎng)的訂單號(hào)生成規(guī)則。
凡客誠(chéng)品和銀泰網(wǎng)訂單號(hào)都含有 0522，這是因?yàn)檫@ 2 張訂單都是2013年5月22號(hào)下的訂單。
基本猜測(cè)一下，凡客的訂單規(guī)則是：業(yè)務(wù)編碼+年的后2位+月+日+訂單數(shù);泰網(wǎng)的訂單號(hào)規(guī)則：年的第三位數(shù)+業(yè)務(wù)編碼+年的后1位+月+日+訂單數(shù);而京東商城和蘇寧易購(gòu)的訂單號(hào)看不出規(guī)則。
最后我們來(lái)分析一下小米訂單號(hào)1111218032345170，可以將其分解成四個(gè)部分1——111218—03234—5170。
- 第一部分，1 表示購(gòu)買，2 表示退貨。
- 第二部分，表示 2011 年 12 月 18 日下的單，前面兩位省掉了。
- 第三部分，時(shí)間戳對(duì)應(yīng)00:53:54，換算成秒是03234秒。
- 最后一部分，表示在同一秒內(nèi)下的第 5170 單，也就是說(shuō)，小米認(rèn)為，在一秒內(nèi)不會(huì)超過(guò)一萬(wàn)個(gè)訂單。
總結(jié)起來(lái)，小米的訂單規(guī)則是：業(yè)務(wù)編碼+年的后 2 位+月+日+秒+訂單數(shù)，固定長(zhǎng)度為16，這種訂單號(hào)規(guī)則可以保證 100 年不會(huì)重復(fù)!
同樣的，借鑒小米的訂單號(hào)規(guī)則，我們也可以生成同樣的訂單號(hào)，實(shí)現(xiàn)過(guò)程如下：
- //獲取當(dāng)前時(shí)間
- Date currentTime = new Date();
- //格式化當(dāng)前時(shí)間為【年的后2位+月+日】
- String originDateStr = new SimpleDateFormat("yyMMdd").format(currentTime );
- //計(jì)算當(dāng)前時(shí)間走過(guò)的秒
- Date startTime = new SimpleDateFormat("yyyyMMdd").parse(new SimpleDateFormat("yyyyMMdd").format(originDate));
- long differSecond = (currentTime.getTime() - startTime.getTime()) / 1000;
- //獲取【年的后2位+月+日+秒】，秒的長(zhǎng)度不足補(bǔ)充0
- String yyMMddSecond = originDateStr + StringUtils.leftPad(String.valueOf(differSecond), 5, '0');
- //獲取【業(yè)務(wù)編碼】 + 【年的后2位+月+日+秒】，作為自增key；
- String prefixOrder = sourceType + "" + yyMMddSecond;
- //通過(guò)key，采用redis自增函數(shù)，實(shí)現(xiàn)單秒自增；不同的key，從0開(kāi)始自增，同時(shí)設(shè)置60秒過(guò)期
- Long incrId = redisUtils.saveINCR(prefixComplaint, 60);
- //生成訂單編號(hào)
- String orderNo = prefixOrder + StringUtils.leftPad(String.valueOf(incrId), 4, '0');
此訂單編號(hào)可以保證大流量環(huán)境下全局唯一、生成速度非常的快、支持高并發(fā)環(huán)境，同時(shí)還支持按時(shí)間排序!
三、總結(jié)
通過(guò)上面的示例演示，我們可用做一個(gè)詳細(xì)的總結(jié)!
綜上所述，在大流量的環(huán)境下，我們可以通過(guò) redis 的incr函數(shù)實(shí)現(xiàn)序列號(hào)自增的特性，同時(shí)搭配訂單的設(shè)計(jì)規(guī)則，從而保證高并發(fā)的環(huán)境下，訂單唯一性!
四、參考
1、如何正確設(shè)計(jì)一個(gè)訂單號(hào)???
2、并發(fā)下的唯一訂單號(hào)生成規(guī)則
