分布式唯一ID生成常用方案有哪些,相信很多沒有經(jīng)驗的人對此束手無策,為此本文總結(jié)了問題出現(xiàn)的原因和解決方法,通過這篇文章希望你能解決這個問題。
十年的休寧縣網(wǎng)站建設(shè)經(jīng)驗,針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù),響應(yīng)快,48小時及時工作處理。營銷型網(wǎng)站的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同,自動調(diào)整休寧縣建站的顯示方式,使網(wǎng)站能夠適用不同顯示終端,在瀏覽器中調(diào)整網(wǎng)站的寬度,無論在任何一種瀏覽器上瀏覽網(wǎng)站,都能展現(xiàn)優(yōu)雅布局與設(shè)計,從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)建站從事“休寧縣網(wǎng)站設(shè)計”,“休寧縣網(wǎng)站推廣”以來,每個客戶項目都認(rèn)真落實執(zhí)行。
1. 使用JAVA的UUID生成
算法的核心思想是結(jié)合機器的網(wǎng)卡、當(dāng)?shù)貢r間、一個隨記數(shù)來生成UUID。
優(yōu)點:本地生成,生成簡單,性能好,沒有高可用風(fēng)險
缺點:長度過長,字母和數(shù)字組合,存儲冗余,且無序不可讀,查詢效率低
2. 數(shù)據(jù)庫自增ID
使用數(shù)據(jù)庫的id自增策略,如 MySQL 的 auto_increment、oracle的sequence。并且可以使用兩臺數(shù)據(jù)庫分別設(shè)置不同步長,生成不重復(fù)ID的策略來實現(xiàn)高可用。
優(yōu)點:數(shù)據(jù)庫生成的ID絕對有序,高可用實現(xiàn)方式簡單
缺點:需要獨立部署數(shù)據(jù)庫實例,成本高,實時操作數(shù)據(jù)庫,大并發(fā)時存在性能瓶頸問題
3. 數(shù)據(jù)庫+程序(批量生成ID)
一次按需批量生成多個ID,每次生成都需要訪問數(shù)據(jù)庫,將數(shù)據(jù)庫修改為最大的ID值,并在內(nèi)存中記錄當(dāng)前值及最大值。
優(yōu)點:避免了每次生成ID都要訪問數(shù)據(jù)庫并帶來壓力,提高了性能
缺點:屬于本地生成策略,存在單點故障,如果服務(wù)器宕機,重啟服務(wù)造成ID不連續(xù)
4. redis生成ID
Redis的所有命令操作都是單線程的,本身提供像 incr 和 increby 這樣的自增原子命令,所以能保證生成的 ID 肯定是唯一有序的。
優(yōu)點:不依賴于數(shù)據(jù)庫,靈活方便,且性能優(yōu)于數(shù)據(jù)庫;數(shù)字ID天然排序,對分頁或者需要排序的結(jié)果很有幫助。
缺點:如果系統(tǒng)中沒有Redis,還需要引入新的組件,增加系統(tǒng)復(fù)雜度;需要編碼和配置的工作量比較大。
考慮到單節(jié)點的性能瓶頸,可以使用 Redis 集群來獲取更高的吞吐量。假如一個集群中有3臺 Redis??梢猿跏蓟颗_ Redis 的值分別是1, 2, 3,然后步長都是3。各個 Redis 生成的 ID 為:
A:1, 4, 7, 10, 13
B:2, 5, 8, 11, 14
C:3, 6, 9, 12, 15
隨便負載到哪個機確定好,未來很難做修改。步長和初始值一定需要事先確定。使用 Redis 集群也可以方式單點故障的問題。
另外,比較適合使用 Redis 來生成每天從0開始的流水號。比如訂單號 = 日期 + 當(dāng)日自增長號??梢悦刻煸?Redis 中生成一個 Key ,使用 INCR 進行累加。
5.MongoDB生成ID
MongoDB的ObjectId和snowflake算法類似。它設(shè)計成輕量型的,不同的機器都能用全局唯一的同種方法方便地生成它。MongoDB 從一開始就設(shè)計用來作為分布式數(shù)據(jù)庫,處理多個節(jié)點是一個核心要求。使其在分片環(huán)境中要容易生成得多。
6.其他一些常用的方案
百度uid生成器:https://github.com/baidu/uid-generator
美團點評生成器:http://tech.meituan.com/MT_Leaf.html
zookeeper方式生成唯一UUID
snowflake算法生成UUID
看完上述內(nèi)容,你們掌握分布式唯一ID生成常用方案有哪些的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝各位的閱讀!