<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
一個美女面試官坐到我的對面,發光logo的MacBook也擋不住她那圓潤可愛的臉龐。
程式媛本就稀有,美女面試官更是難尋。
這麼溫柔可愛的面試官,應該不會為難我吧。嗯,應該是的,畢竟我這麼帥氣,面試可能就是走個過場。美女面試官是不是單身?畢竟程式設計師都不善交流,因為我也是單身,難道我的姻緣就在此註定。孩子的名字我都想好了。一冰!好名字。
面試官: 小夥子,你低著頭笑什麼吶。開始面試了,你知道訂單ID是怎麼生成的嗎?
啥?訂單ID怎麼生成?美女怎麼不按套路出牌!HashMap實現原理,我已經倒背如流,你不問。瞎問什麼訂單ID。
我: 還能咋生成?用資料庫主鍵自增唄。
面試官: 這樣不行啊。資料庫主鍵順序自增,每天有多少訂單量被競爭對手看的一清二楚,商業機密都暴露了。
況且單機MySQL只能支援幾百量級的並行,我們公司每天千萬訂單量,hold不住啊。
我: 嗯,那就用用資料庫叢集,自增ID起始值按機器編號,步長等於機器數量。
比如有兩臺機器,第一臺機器生成的ID是1、3、5、7,第二臺機器生成的ID是2、4、6、8。效能不行就加機器,這並行量der一下就上去了。
面試官: 小夥子,你想得倒是挺好。你有沒有想過實現百萬級的並行,大概就需要2000臺機器,你這還只是用來生成訂單ID,公司再有錢也經不起這麼造。
我: 既然MySQL的並行量不行,我們是不是可以提前從MySQL獲取一批自增ID,載入到本地記憶體中,然後從記憶體中並行取,這並行效能豈不是槓槓滴。
面試官: 你還挺上道,這種叫號段模式。並行量是上去了,但是自增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); } }
輸出結果:
58e93ecab9c64295b15f7f4661edcbc1
面試官: 也不行。32位元字串會佔用更大的空間,無序的字串作資料庫主鍵,每次插入資料庫的時候,MySQL為了維護B+樹結構,需要頻繁調整節點順序,影響效能。況且字串太長,也沒有任何業務含義,pass。
小夥子,你可能是沒參與過電商系統,我先跟說一下生成訂單ID要滿足哪些條件:
全域性唯一:如果訂單ID重複了,肯定要完蛋。
高效能:要做到高並行、低延遲。生成訂單ID都成為瓶頸了,那還得了。
高可用:至少要做到4個9,別動不動就宕機了。
易用性:如果為了滿足上述要求,搞了幾百臺伺服器,複雜且難以維護,也不行。
數值且有序遞增:數值佔用的空間更小,有序遞增能保證插入MySQL的時候更高效能。
嵌入業務含義:如果訂單ID裡面能嵌入業務含義,就能通過訂單ID知道是哪個業務線生成的,便於排查問題。
我擦,生成一個小小的訂單ID,搞出這麼多規則,還能玩下去嗎?難道今天的面試要跪,怎麼可能。一燈的文章我一直訂閱,這個還能難得住我,陪美女程式設計師玩玩還當真了。
我: 我聽說圈內有一種流傳已久的分散式、高效能、高可用的訂單ID生成演演算法—雪花演演算法,完全能滿足你的上述要求。雪花演演算法生成ID是Long型別,長度64位元。
第 1 位: 符號位,暫時不用。
第 2~42 位: 共41位,時間戳,單位是毫秒,可以支撐大約69年
第 43~52 位: 共10位,機器ID,最多可容納1024臺機器
第 53~64 位: 共12位元,序列號,是自增值,表示同一毫秒內產生的ID,單臺機器每毫秒最多可生成4096個訂單ID
程式碼實現:
/** * @author 一燈架構 * @apiNote 雪花演演算法 **/ public class SnowFlake { /** * 起始時間戳,從2021-12-01開始生成 */ private final static long START_STAMP = 1638288000000L; /** * 序列號佔用的位數 12 */ private final static long SEQUENCE_BIT = 12; /** * 機器標識佔用的位數 */ private final static long MACHINE_BIT = 10; /** * 機器數量最大值 */ 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; /** * 機器標識 */ private long machineId; /** * 序列號 */ private long sequence = 0L; /** * 上一次時間戳 */ private long lastStamp = -1L; /** * 構造方法 * @param machineId 機器ID */ public SnowFlake(long machineId) { if (machineId > MAX_MACHINE_NUM || machineId < 0) { throw new RuntimeException("機器超過最大數量"); } this.machineId = machineId; } /** * 產生下一個ID */ public synchronized long nextId() { long currStamp = getNewStamp(); if (currStamp < lastStamp) { throw new RuntimeException("時鐘後移,拒絕生成ID!"); } if (currStamp == lastStamp) { // 相同毫秒內,序列號自增 sequence = (sequence + 1) & MAX_SEQUENCE; // 同一毫秒的序列數已經達到最大 if (sequence == 0L) { currStamp = getNextMill(); } } else { // 不同毫秒內,序列號置為0 sequence = 0L; } lastStamp = currStamp; return (currStamp - START_STAMP) << TIMESTAMP_LEFT // 時間戳部分 | machineId << MACHINE_LEFT // 機器標識部分 | 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()); } }
輸出結果:
6836348333850624
接入非常簡單,不需要搭建服務叢集,。程式碼邏輯非常簡單,,同一毫秒內,訂單ID的序列號自增。同步鎖只作用於本機,機器之間互不影響,每毫秒可以生成四百萬個訂單ID,非常強悍。
生成規則不是固定的,可以根據自身的業務需求調整。如果你不需要那麼大的並行量,可以把機器標識位拆出一部分,當作業務標識位,標識是哪個業務線生成的訂單ID。
面試官: 小夥子,有點東西,深藏不漏啊。再問個更難的問題,你覺得雪花演演算法還有改進的空間嗎?
你真是打破砂鍋問到底,不把我問趴下不結束。幸虧來之前我瞥了一眼一燈的文章。
我: 有的,雪花演演算法嚴重依賴系統時鐘。如果時鐘回撥,就會生成重複ID。
面試官: 有什麼解決辦法嗎?
我: 有問題就會有答案。比如美團的Leaf(美團自研一種分散式ID生成系統),為了解決時鐘回撥,引入了zookeeper,原理也很簡單,就是比較當前系統時間跟生成節點的時間。
有的對並行要求更高的系統,比如雙十一秒殺,每毫秒4百萬並行還不能滿足要求,就可以使用雪花演演算法和號段模式相結合,比如百度的UidGenerator、滴滴的TinyId。想想也是,號段模式的預先生成ID肯定是高效能分散式訂單ID的最終解決方案。
面試官: 小夥子,我看你簡歷上寫著已經離職了。明天就來上班吧,薪資double,就這樣了。
總結
到此這篇關於面試官問訂單ID是如何生成的文章就介紹到這了,更多相關MySQL自增主鍵生成訂單ID內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!
相關文章
<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
综合看Anker超能充系列的性价比很高,并且与不仅和iPhone12/苹果<em>Mac</em>Book很配,而且适合多设备充电需求的日常使用或差旅场景,不管是安卓还是Switch同样也能用得上它,希望这次分享能给准备购入充电器的小伙伴们有所
2021-06-01 09:31:42
除了L4WUDU与吴亦凡已经多次共事,成为了明面上的厂牌成员,吴亦凡还曾带领20XXCLUB全队参加2020年的一场音乐节,这也是20XXCLUB首次全员合照,王嗣尧Turbo、陈彦希Regi、<em>Mac</em> Ova Seas、林渝植等人全部出场。然而让
2021-06-01 09:31:34
目前应用IPFS的机构:1 谷歌<em>浏览器</em>支持IPFS分布式协议 2 万维网 (历史档案博物馆)数据库 3 火狐<em>浏览器</em>支持 IPFS分布式协议 4 EOS 等数字货币数据存储 5 美国国会图书馆,历史资料永久保存在 IPFS 6 加
2021-06-01 09:31:24
开拓者的车机是兼容苹果和<em>安卓</em>,虽然我不怎么用,但确实兼顾了我家人的很多需求:副驾的门板还配有解锁开关,有的时候老婆开车,下车的时候偶尔会忘记解锁,我在副驾驶可以自己开门:第二排设计很好,不仅配置了一个很大的
2021-06-01 09:30:48
不仅是<em>安卓</em>手机,苹果手机的降价力度也是前所未有了,iPhone12也“跳水价”了,发布价是6799元,如今已经跌至5308元,降价幅度超过1400元,最新定价确认了。iPhone12是苹果首款5G手机,同时也是全球首款5nm芯片的智能机,它
2021-06-01 09:30:45