資訊專(zhuān)欄INFORMATION COLUMN
摘要：幾乎所有的系統(tǒng)都存在生成唯一的需求，如用戶(hù)賬單等，由于系統(tǒng)通常是分布式架構(gòu)，因而需要有合適的分布式生成方案。優(yōu)勢(shì)和數(shù)據(jù)庫(kù)自增方案類(lèi)似缺點(diǎn)同樣仍然有性能上限，依賴(lài)數(shù)據(jù)庫(kù)的可用性。使用時(shí)，可以使用具體的場(chǎng)景選擇合適的方案。
幾乎所有的系統(tǒng)都存在生成唯一ID的需求，如用戶(hù)ID、賬單ID等，由于系統(tǒng)通常是分布式架構(gòu)，因而需要有合適的分布式ID生成方案。
常見(jiàn)的分布式唯一ID方法有（歡迎補(bǔ)充）：
時(shí)間戳
數(shù)據(jù)庫(kù)自增ID
UUID
放號(hào)系統(tǒng)
類(lèi)snowflake
一、時(shí)間戳
原理： 使用直接使用時(shí)間戳毫秒值或微秒值作為ID
缺點(diǎn)： 每個(gè)時(shí)間單位只能生成一個(gè)ID， 在分布式架構(gòu)中不好保證唯一性。
適用場(chǎng)景： 一般很少適用這種方案
二、數(shù)據(jù)庫(kù)自增ID
原理： 基于MySQL等數(shù)據(jù)庫(kù)的auto_inscrement功能
優(yōu)勢(shì)： 實(shí)現(xiàn)簡(jiǎn)單（數(shù)據(jù)庫(kù)自帶功能），生成的ID單調(diào)遞增，保證全局唯一；ID長(zhǎng)度靈活
缺點(diǎn)： 存儲(chǔ)性能上限（MySQL性能）， 對(duì)數(shù)據(jù)庫(kù)重度依賴(lài)，一旦數(shù)據(jù)庫(kù)宕機(jī)則無(wú)法生產(chǎn)繼續(xù)生成ID。
三、UUID
原理： 多個(gè)版本，大致原理是 時(shí)間戳+機(jī)器ID+CPU時(shí)鐘+隨機(jī)數(shù)。 通過(guò)CPU時(shí)鐘保證本地唯一，通過(guò)機(jī)器ID+CPU時(shí)鐘保證全局唯一
優(yōu)勢(shì)： 全局唯一，本地生成，沒(méi)有性能上限
缺點(diǎn)： 生成ID過(guò)長(zhǎng)（32位16進(jìn)制字符），不是單調(diào)遞增
四、放號(hào)系統(tǒng)
原理： 通常是基于數(shù)據(jù)庫(kù)自增ID的方案改造，只是每次批量獲取一個(gè)號(hào)段，提升了性能。
優(yōu)勢(shì)： 和”數(shù)據(jù)庫(kù)自增ID“方案類(lèi)似
缺點(diǎn)： 同樣仍然有性能上限，依賴(lài)數(shù)據(jù)庫(kù)的可用性。數(shù)據(jù)庫(kù)主備切換時(shí)可能發(fā)生ID沖突。存儲(chǔ)耗時(shí)尖刺（更新DB時(shí)延時(shí)高）。因?yàn)樘?hào)段通常是定長(zhǎng)，拓展性差，對(duì)流量波動(dòng)大的場(chǎng)景不太適用。
參考： https://tech.meituan.com/2019/03/07/open-source-project-leaf.html
升級(jí)
放號(hào)系統(tǒng)可以升級(jí)多個(gè)變種，比如采用多個(gè)數(shù)據(jù)庫(kù)（通過(guò)數(shù)據(jù)庫(kù)實(shí)例ID+數(shù)據(jù)庫(kù)自增ID）， 在ID消耗完之前（比如消耗了50%）就預(yù)申請(qǐng)?zhí)柖蔚确桨浮?/p>
五、類(lèi)snowflake算法方案
原理： 時(shí)間戳+機(jī)器ID+序列號(hào)
優(yōu)勢(shì)： uint64型，全局唯一，單調(diào)遞增，本地生成性能高，每秒能生成的ID較多。
缺點(diǎn)： 需要解決三大問(wèn)題（增加了復(fù)雜度）
三大問(wèn)題
時(shí)間回?fù)?/strong>
時(shí)間回?fù)軉?wèn)題的幾種解決方案：
機(jī)器ID的分配和回收
機(jī)器ID的分配：
機(jī)器ID的上限
snowflake算法使用10bit存儲(chǔ)機(jī)器，所以機(jī)器ID的上線(xiàn)是2^10=1024； 不過(guò)這一般也能滿(mǎn)足業(yè)務(wù)需要了（只要做好分配和回收）
六、小結(jié)
實(shí)際業(yè)務(wù)中，<放號(hào)系統(tǒng)>和<類(lèi)snowflake>兩種方案適用的場(chǎng)景較廣。 使用時(shí)，可以使用具體的場(chǎng)景選擇合適的方案。同時(shí)，可以結(jié)合需要進(jìn)行優(yōu)化。
比如：用戶(hù)ID可以使用<放號(hào)系統(tǒng)>生成，訂單號(hào)等可以使用類(lèi)snowflake方案來(lái)生成。
使用類(lèi)snowflake方案時(shí)，使用哪種方式分配機(jī)器ID也可以根據(jù)具體的場(chǎng)景選擇。 比如機(jī)器較少，各個(gè)進(jìn)程配置方便手動(dòng)配置時(shí)，可以采用手動(dòng)配置的方式； 如果實(shí)在集群中，Pods節(jié)點(diǎn)的最后8bit肯定不同，Pods自動(dòng)擴(kuò)縮容的場(chǎng)景，可以采用IP地址Hash值的方式來(lái)生成機(jī)器ID。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/125952.html
摘要：數(shù)據(jù)遷移，主要利用阿里云數(shù)據(jù)傳輸服務(wù)的數(shù)據(jù)遷移能力，涉及到全量遷移增量遷移一致性校驗(yàn)及反向任務(wù)。小結(jié)通過(guò)周密的遷移方案設(shè)計(jì)，以及強(qiáng)大的數(shù)據(jù)遷移工具的能力，閑魚(yú)商品庫(kù)順利完成億在線(xiàn)數(shù)據(jù)庫(kù)服務(wù)遷移，獨(dú)立的物理部署顯著提升商品庫(kù)在線(xiàn)服務(wù)的穩(wěn)定性。 背景 在系統(tǒng)的快速迭代過(guò)程中，業(yè)務(wù)系統(tǒng)往往部署在同一個(gè)物理庫(kù)，沒(méi)有做核心數(shù)據(jù)和非核心數(shù)據(jù)的物理隔離。隨著數(shù)據(jù)量的擴(kuò)大這種情況會(huì)帶來(lái)穩(wěn)定性的風(fēng)險(xiǎn)，如...
摘要：但是，隨者工程開(kāi)發(fā)的復(fù)雜程度和代碼規(guī)模不斷地增加，暴露出來(lái)的各種性能問(wèn)題也愈發(fā)明顯，極大的影響著開(kāi)發(fā)過(guò)程中的體驗(yàn)。對(duì)應(yīng)的資源也可以直接由頁(yè)面外鏈載入，有效地減小了資源包的體積。 背景 如今前端工程化的概念早已經(jīng)深入人心，選擇一款合適的編譯和資源管理工具已經(jīng)成為了所有前端工程中的標(biāo)配，而在諸多的構(gòu)建工具中，webpack以其豐富的功能和靈活的配置而深受業(yè)內(nèi)吹捧，逐步取代了grunt和gu...
摘要：表示生成一個(gè)懶加載的，只有當(dāng)需要時(shí)才會(huì)被加載。主要是作用域提升，將所有模塊放在同一個(gè)作用域當(dāng)中，一方面能提高運(yùn)行速度，另一方面也能降低文件體積。前提是你的代碼是用模塊寫(xiě)的。參考文章學(xué)習(xí)小結(jié) 前言 之前接手公司一個(gè)前端項(xiàng)目，開(kāi)發(fā)了幾個(gè)月后越來(lái)越難以忍受項(xiàng)目結(jié)構(gòu)的混亂和打包體積的臃腫（腳手架和基本功能代碼都是從公司的其他項(xiàng)目復(fù)制過(guò)來(lái)的），如果不立即進(jìn)行重構(gòu)，難以想象以后要怎么維護(hù)各個(gè)產(chǎn)品線(xiàn)...
閱讀 3538·2023-04-25 20:09
閱讀 3739·2022-06-28 19:00
閱讀 3060·2022-06-28 19:00
閱讀 3081·2022-06-28 19:00
閱讀 3175·2022-06-28 19:00
閱讀 2880·2022-06-28 19:00
閱讀 3047·2022-06-28 19:00
閱讀 2638·2022-06-28 19:00
