小編給大家分享一下Laravel分布式ID生成器的使用示例,希望大家閱讀完這篇文章之后都有所收獲,下面讓我們一起去探討吧!
成都創(chuàng)新互聯(lián)專注于昌寧企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計(jì),商城網(wǎng)站開發(fā)。昌寧網(wǎng)站建設(shè)公司,為昌寧等地區(qū)提供建站服務(wù)。全流程按需設(shè)計(jì)網(wǎng)站,專業(yè)設(shè)計(jì),全程項(xiàng)目跟蹤,成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)在應(yīng)用程序中,經(jīng)常需要全局的ID作為數(shù)據(jù)庫主鍵。如何生成全局ID?
首先,需要確定全局ID是整型還是字符串?如果是字符串,那么現(xiàn)有的UUID就完全滿足需求,不需要額外的工作。缺點(diǎn)是字符串作為ID占用空間大,索引效率比整型低。
如果采用整型作為ID,那么首先排除掉32位int類型,因?yàn)榉秶?,必須使?4位long型。
采用整型作為ID時(shí),如何生成自增、全局且不重復(fù)的ID?
方案一:利用數(shù)據(jù)庫的自增ID,從1開始,基本可以做到連續(xù)遞增。Oracle可以用SEQUENCE
,MySQL可以用主鍵的AUTO_INCREMENT
,雖然不能保證全局,但每個(gè)表,也基本滿足需求。
數(shù)據(jù)庫自增ID的缺點(diǎn)是數(shù)據(jù)在插入前,無法獲得ID。數(shù)據(jù)在插入后,獲取的ID雖然是的,但一定要等到事務(wù)提交后,ID才算是有效的。有些雙向引用的數(shù)據(jù),不得不插入后再做一次更新,比較麻煩。
第二種方式是采用一個(gè)集中式ID生成器,它可以是Redis,也可以是ZooKeeper,也可以利用數(shù)據(jù)庫的表記錄最后分配的ID。
這種方式較大的缺點(diǎn)是復(fù)雜性太高,需要嚴(yán)重依賴第三方服務(wù),而且代碼配置繁瑣。一般來說,越是復(fù)雜的方案,越不可靠,并且測(cè)試越痛苦。
第三種方式是類似Twitter的Snowflake算法,它給每臺(tái)機(jī)器分配一個(gè)標(biāo)識(shí),然后通過時(shí)間戳+標(biāo)識(shí)+自增實(shí)現(xiàn)全局ID。這種方式好處在于ID生成算法完全是一個(gè)無狀態(tài)機(jī),無網(wǎng)絡(luò)調(diào)用,高效可靠。缺點(diǎn)是如果標(biāo)識(shí)有重復(fù),會(huì)造成ID沖突。
Snowflake算法采用41bit毫秒時(shí)間戳,加上10bit機(jī)器ID,加上12bit序列號(hào),理論上最多支持1024臺(tái)機(jī)器每秒生成4096000個(gè)序列號(hào),對(duì)于Twitter的規(guī)模來說夠用了。
但是對(duì)于絕大部分普通應(yīng)用程序來說,根本不需要每秒超過400萬的ID,機(jī)器數(shù)量也達(dá)不到1024臺(tái),所以,我們可以改進(jìn)一下,使用更短的ID生成方式:
53bitID由32bit秒級(jí)時(shí)間戳+16bit自增+5bit機(jī)器標(biāo)識(shí)組成,累積32臺(tái)機(jī)器,每秒可以生成6.5萬個(gè)序列號(hào),核心代碼:
private static synchronized long nextId(long epochSecond) { if (epochSecond < lastEpoch) { // warning: clock is turn back: logger.warn("clock is back: " + epochSecond + " from previous:" + lastEpoch); epochSecond = lastEpoch; } if (lastEpoch != epochSecond) { lastEpoch = epochSecond; reset(); } offset++; long next = offset & MAX_NEXT; if (next == 0) { logger.warn("maximum id reached in 1 second in epoch: " + epochSecond); return nextId(epochSecond + 1); } return generateId(epochSecond, next, SHARD_ID);}
時(shí)間戳減去一個(gè)固定值,此方案高可支持到2106年。
如果每秒6.5萬個(gè)序列號(hào)不夠怎么辦?沒關(guān)系,可以繼續(xù)遞增時(shí)間戳,向前“借”下一秒的6.5萬個(gè)序列號(hào)。
同時(shí)還解決了時(shí)間回?fù)艿膯栴}。
機(jī)器標(biāo)識(shí)采用簡(jiǎn)單的主機(jī)名方案,只要主機(jī)名符合host-1
,host-2
就可以自動(dòng)提取機(jī)器標(biāo)識(shí),無需配置。
最后,為什么采用最多53位整型,而不是64位整型?這是因?yàn)榭紤]到大部分應(yīng)用程序是Web應(yīng)用,如果要和JavaScript打交道,由于JavaScript支持的較大整型就是53位,超過這個(gè)位數(shù),JavaScript將丟失精度。因此,使用53位整數(shù)可以直接由JavaScript讀取,而超過53位時(shí),就必須轉(zhuǎn)換成字符串才能保證JavaScript處理正確,這會(huì)給API接口帶來額外的復(fù)雜度。這也是為什么新浪微博的API接口會(huì)同時(shí)返回id
和idstr
的原因。
看完了這篇文章,相信你對(duì)“Laravel分布式ID生成器的使用示例”有了一定的了解,如果想了解更多相關(guān)知識(shí),歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝各位的閱讀!