您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“MySQL訂單ID是怎么生成的”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
面試官: 小伙子,你低著頭笑什么吶。開始面試了,你知道訂單ID是怎么生成的嗎?
啥?訂單ID怎么生成?美女怎么不按套路出牌!HashMap實現(xiàn)原理,我已經(jīng)倒背如流,你不問。瞎問什么訂單ID。
我: 還能咋生成?用數(shù)據(jù)庫主鍵自增唄。
面試官: 這樣不行啊。數(shù)據(jù)庫主鍵順序自增,每天有多少訂單量被競爭對手看的一清二楚,商業(yè)機密都暴露了。
況且單機MySQL只能支持幾百量級的并發(fā),我們公司每天千萬訂單量,hold不住啊。
我: 嗯,那就用用數(shù)據(jù)庫集群,自增ID起始值按機器編號,步長等于機器數(shù)量。
比如有兩臺機器,第一臺機器生成的ID是1、3、5、7,第二臺機器生成的ID是2、4、6、8。性能不行就加機器,這并發(fā)量der一下就上去了。
面試官: 小伙子,你想得倒是挺好。你有沒有想過實現(xiàn)百萬級的并發(fā),大概就需要2000臺機器,你這還只是用來生成訂單ID,公司再有錢也經(jīng)不起這么造。
我: 既然MySQL的并發(fā)量不行,我們是不是可以提前從MySQL獲取一批自增ID,加載到本地內(nèi)存中,然后從內(nèi)存中并發(fā)取,這并發(fā)性能豈不是杠杠滴。
面試官: 你還挺上道,這種叫號段模式。并發(fā)量是上去了,但是自增ID還是不能作為訂單ID的。
我: 用Java自帶UUID怎么樣?
import java.util.UUID; /** * @author yideng * @apiNote UUID示例 */ public class UUIDTest { public static void main(String[] args) { String orderId = UUID.randomUUID().toString().replace("-", ""); System.out.println(orderId); } }
輸出結(jié)果:
58e93ecab9c64295b15f7f4661edcbc1
面試官: 也不行。32位字符串會占用更大的空間,無序的字符串作數(shù)據(jù)庫主鍵,每次插入數(shù)據(jù)庫的時候,MySQL為了維護B+樹結(jié)構(gòu),需要頻繁調(diào)整節(jié)點順序,影響性能。況且字符串太長,也沒有任何業(yè)務(wù)含義,pass。
小伙子,你可能是沒參與過電商系統(tǒng),我先跟說一下生成訂單ID要滿足哪些條件:
全局唯一:如果訂單ID重復(fù)了,肯定要完蛋。
高性能:要做到高并發(fā)、低延遲。生成訂單ID都成為瓶頸了,那還得了。
高可用:至少要做到4個9,別動不動就宕機了。
易用性:如果為了滿足上述要求,搞了幾百臺服務(wù)器,復(fù)雜且難以維護,也不行。
數(shù)值且有序遞增:數(shù)值占用的空間更小,有序遞增能保證插入MySQL的時候更高性能。
嵌入業(yè)務(wù)含義:如果訂單ID里面能嵌入業(yè)務(wù)含義,就能通過訂單ID知道是哪個業(yè)務(wù)線生成的,便于排查問題。
我擦,生成一個小小的訂單ID,搞出這么多規(guī)則,還能玩下去嗎?難道今天的面試要跪,怎么可能。一燈的文章我一直訂閱,這個還能難得住我,陪美女程序員玩玩還當(dāng)真了。
我: 我聽說圈內(nèi)有一種流傳已久的分布式、高性能、高可用的訂單ID生成算法—雪花算法,完全能滿足你的上述要求。雪花算法生成ID是Long類型,長度64位。
第 1 位: 符號位,暫時不用。
第 2~42 位: 共41位,時間戳,單位是毫秒,可以支撐大約69年
第 43~52 位: 共10位,機器ID,最多可容納1024臺機器
第 53~64 位: 共12位,序列號,是自增值,表示同一毫秒內(nèi)產(chǎn)生的ID,單臺機器每毫秒最多可生成4096個訂單ID
代碼實現(xiàn):
/** * @author 一燈架構(gòu) * @apiNote 雪花算法 **/ public class SnowFlake { /** * 起始時間戳,從2021-12-01開始生成 */ private final static long START_STAMP = 1638288000000L; /** * 序列號占用的位數(shù) 12 */ private final static long SEQUENCE_BIT = 12; /** * 機器標(biāo)識占用的位數(shù) */ private final static long MACHINE_BIT = 10; /** * 機器數(shù)量最大值 */ private final static long MAX_MACHINE_NUM = ~(-1L << MACHINE_BIT); /** * 序列號最大值 */ private final static long MAX_SEQUENCE = ~(-1L << SEQUENCE_BIT); /** * 每一部分向左的位移 */ private final static long MACHINE_LEFT = SEQUENCE_BIT; private final static long TIMESTAMP_LEFT = SEQUENCE_BIT + MACHINE_BIT; /** * 機器標(biāo)識 */ private long machineId; /** * 序列號 */ private long sequence = 0L; /** * 上一次時間戳 */ private long lastStamp = -1L; /** * 構(gòu)造方法 * @param machineId 機器ID */ public SnowFlake(long machineId) { if (machineId > MAX_MACHINE_NUM || machineId < 0) { throw new RuntimeException("機器超過最大數(shù)量"); } this.machineId = machineId; } /** * 產(chǎn)生下一個ID */ public synchronized long nextId() { long currStamp = getNewStamp(); if (currStamp < lastStamp) { throw new RuntimeException("時鐘后移,拒絕生成ID!"); } if (currStamp == lastStamp) { // 相同毫秒內(nèi),序列號自增 sequence = (sequence + 1) & MAX_SEQUENCE; // 同一毫秒的序列數(shù)已經(jīng)達(dá)到最大 if (sequence == 0L) { currStamp = getNextMill(); } } else { // 不同毫秒內(nèi),序列號置為0 sequence = 0L; } lastStamp = currStamp; return (currStamp - START_STAMP) << TIMESTAMP_LEFT // 時間戳部分 | machineId << MACHINE_LEFT // 機器標(biāo)識部分 | sequence; // 序列號部分 } private long getNextMill() { long mill = getNewStamp(); while (mill <= lastStamp) { mill = getNewStamp(); } return mill; } private long getNewStamp() { return System.currentTimeMillis(); } public static void main(String[] args) { // 訂單ID生成測試,機器ID指定第0臺 SnowFlake snowFlake = new SnowFlake(0); System.out.println(snowFlake.nextId()); } }
輸出結(jié)果:
6836348333850624
接入非常簡單,不需要搭建服務(wù)集群,。代碼邏輯非常簡單,,同一毫秒內(nèi),訂單ID的序列號自增。同步鎖只作用于本機,機器之間互不影響,每毫秒可以生成四百萬個訂單ID,非常強悍。
生成規(guī)則不是固定的,可以根據(jù)自身的業(yè)務(wù)需求調(diào)整。如果你不需要那么大的并發(fā)量,可以把機器標(biāo)識位拆出一部分,當(dāng)作業(yè)務(wù)標(biāo)識位,標(biāo)識是哪個業(yè)務(wù)線生成的訂單ID。
面試官: 小伙子,有點東西,深藏不漏啊。再問個更難的問題,你覺得雪花算法還有改進的空間嗎?
你真是打破砂鍋問到底,不把我問趴下不結(jié)束。幸虧來之前我瞥了一眼一燈的文章。
我: 有的,雪花算法嚴(yán)重依賴系統(tǒng)時鐘。如果時鐘回?fù)?,就會生成重?fù)ID。
面試官: 有什么解決辦法嗎?
我: 有問題就會有答案。比如美團的Leaf(美團自研一種分布式ID生成系統(tǒng)),為了解決時鐘回?fù)埽肓藌ookeeper,原理也很簡單,就是比較當(dāng)前系統(tǒng)時間跟生成節(jié)點的時間。
有的對并發(fā)要求更高的系統(tǒng),比如雙十一秒殺,每毫秒4百萬并發(fā)還不能滿足要求,就可以使用雪花算法和號段模式相結(jié)合,比如百度的UidGenerator、滴滴的TinyId。想想也是,號段模式的預(yù)先生成ID肯定是高性能分布式訂單ID的最終解決方案。
“MySQL訂單ID是怎么生成的”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。