(河南理工大學(xué) 計(jì)算機(jī)學(xué)院,河南 焦作 454000)

秦攀科,李有卿*

0 引言

單機(jī)時(shí)代,一個(gè)數(shù)據(jù)庫(kù)就可以滿足業(yè)務(wù)的需要,數(shù)據(jù)庫(kù)的主鍵選擇很簡(jiǎn)單,直接借助數(shù)據(jù)庫(kù)的自增主鍵就可以實(shí)現(xiàn),其他類型復(fù)雜的主鍵,在單進(jìn)程服務(wù)中也可以很簡(jiǎn)單地實(shí)現(xiàn)。 但是,隨著系統(tǒng)規(guī)模的擴(kuò)大,越來(lái)越多的公司開(kāi)始使用微服務(wù)架構(gòu),這時(shí)就面臨著數(shù)據(jù)庫(kù)主鍵一致性的問(wèn)題。 傳統(tǒng)來(lái)說(shuō),UUID 是可以解決分布式主鍵問(wèn)題的[1-2],但是大多數(shù)公司都采用MySQL數(shù)據(jù)庫(kù)[3],而UUID 的無(wú)序和跳躍會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的性能急劇下降,并且UUID 長(zhǎng)度很長(zhǎng),因此采用UUID 是不可取的。 雪花算法在時(shí)間范圍內(nèi)基本有序,同時(shí)也可以保障多進(jìn)程下不會(huì)出現(xiàn)主鍵重復(fù),但是也有可能生成重復(fù)的主鍵,而且生成的主鍵長(zhǎng)度也較長(zhǎng),在前端展示的時(shí)候會(huì)精度丟失,需要后端額外轉(zhuǎn)化為字符串。越來(lái)越多的系統(tǒng)需要定制有一定特殊格式和規(guī)則的主鍵,開(kāi)發(fā)人員需要去實(shí)現(xiàn)特定要求的主鍵,這會(huì)讓業(yè)務(wù)參與到分布式主鍵的開(kāi)發(fā),造成人力資源浪費(fèi)。 所有的這一系統(tǒng)問(wèn)題都急需解決,因此,分布式主鍵系統(tǒng)應(yīng)運(yùn)而生,可以支持多種分布式主鍵生成規(guī)則,通過(guò)Grpc方式的遠(yuǎn)程過(guò)程調(diào)用提供多種語(yǔ)言的SDK 支持[4-5],不僅方便,而且RPC 可以讓系統(tǒng)性能得到提升[6]。 內(nèi)部通過(guò)Namespace 做系統(tǒng)空間隔離,不同種類的主鍵通過(guò)主鍵類型做區(qū)分。 此系統(tǒng)上線后,所有業(yè)務(wù)系統(tǒng)都可以直接調(diào)用該系統(tǒng)提供的SDK,集成分布式主鍵。

1 分布式主鍵介紹

1.1 雪花算法

目前,最主流的分布式主鍵生成算法是基于雪花算法的,其結(jié)構(gòu)如圖1 所示。

圖1 雪花算法的結(jié)構(gòu)

可以看到,雪花算法是由64 個(gè)二進(jìn)制數(shù)組成。 其中,第一位是符號(hào)位,其值永遠(yuǎn)為0;接著是41 個(gè)二進(jìn)制位表示時(shí)間,精確到毫秒值;然后是10 個(gè)二進(jìn)制位表示機(jī)器標(biāo)識(shí);最后是12 個(gè)二進(jìn)制位標(biāo)識(shí)某一毫秒能產(chǎn)生的唯一主鍵個(gè)數(shù),即2 的12 次方,4 096 個(gè)數(shù)字。基于雪花算法的結(jié)構(gòu),可以保證:(1)所有生成的id 按時(shí)間趨勢(shì)遞增;(2)因?yàn)闄C(jī)器標(biāo)識(shí)的隔離,整個(gè)分布式系統(tǒng)不會(huì)產(chǎn)生重復(fù)的id。

雪花算法存在的問(wèn)題:(1)機(jī)器標(biāo)識(shí)只有10 個(gè)二進(jìn)制位,也即最多只支持1 024 個(gè)服務(wù)使用,現(xiàn)在的大型系統(tǒng)服務(wù)節(jié)點(diǎn)可能遠(yuǎn)遠(yuǎn)不止1 024 個(gè)。 (2)要保證1 024 個(gè)節(jié)點(diǎn)分配到的機(jī)器標(biāo)識(shí)都是唯一的。 (3)時(shí)鐘回?fù)軉?wèn)題。 當(dāng)時(shí)鐘回?fù)?會(huì)產(chǎn)生重復(fù)的主鍵,這是難以接受的。 (4)雪花算法的機(jī)器id 的分配問(wèn)題。 當(dāng)機(jī)器多起來(lái),需要仔細(xì)考慮保證每臺(tái)機(jī)器能分到唯一的機(jī)器標(biāo)識(shí)。

1.2 基于Redis 的分布式主鍵

有一種分布式主鍵的實(shí)現(xiàn)方式是基于Redis 的[7],Redis 的自增命令可以很好地提供自增主鍵,但特別依賴Redis,也不是完美的實(shí)現(xiàn)方式。 若Redis 宕機(jī),又沒(méi)有開(kāi)啟持久化,會(huì)導(dǎo)致主鍵出現(xiàn)重復(fù),對(duì)Redis 的性能造成影響,同時(shí),易于他人通過(guò)主鍵推測(cè)系統(tǒng)規(guī)模。 所以,沒(méi)有特殊需求定制全局自增的主鍵,不建議使用這種方式。但在某些特殊場(chǎng)景中,Redis 自增主鍵有著很大效果。 此外,通過(guò)Redis 的過(guò)期機(jī)制,也可以很好地模擬出定期自增主鍵,這種類型的主鍵在很多場(chǎng)景都有著廣泛的應(yīng)用。Redis 在緩存和分布式協(xié)調(diào)方面也有著廣泛的應(yīng)用[8],已經(jīng)成為開(kāi)發(fā)領(lǐng)域內(nèi)不可或缺的基礎(chǔ)組件。

1.3 基于MySQL 的號(hào)段模式主鍵

有一種分布式主鍵的生成方式是通過(guò)MySQL 數(shù)據(jù)庫(kù)的號(hào)段模式[9],向數(shù)據(jù)庫(kù)申請(qǐng)取得一段范圍數(shù)據(jù)的使用權(quán),其他節(jié)點(diǎn)將不再使用這段范圍數(shù)據(jù),以此保證數(shù)據(jù)的唯一[10]。 分配號(hào)段時(shí),需要分布式鎖保證分配范圍不會(huì)出現(xiàn)多分配的問(wèn)題。 號(hào)段模式的問(wèn)題在于如何決定號(hào)段范圍的大小,分配太大,服務(wù)重啟會(huì)導(dǎo)致范圍失效,浪費(fèi)一定數(shù)量的范圍;太少,容易頻繁觸發(fā)分布式鎖,并頻繁觸發(fā)數(shù)據(jù)庫(kù)操作,影響性能。 當(dāng)然,號(hào)段的優(yōu)點(diǎn)也很明顯,主鍵可以從0 開(kāi)始,生成的主鍵比較短[11],對(duì)于前端展示比較友好,也可以彌補(bǔ)雪花算法主鍵長(zhǎng)的缺點(diǎn)。

1.4 Go 語(yǔ)言介紹

Go 語(yǔ)言可以直接編譯成機(jī)器碼[12],不依賴其他庫(kù),部署方便,屬于靜態(tài)語(yǔ)言。 在語(yǔ)言層面就支持并發(fā),是Go 最大的特色,可以充分利用多核的優(yōu)勢(shì)。 Go內(nèi)置Runtime,支持垃圾回收,而且簡(jiǎn)單易學(xué),只有25個(gè)關(guān)鍵字,但是表達(dá)能力非常強(qiáng)大,幾乎支持了大多數(shù)面向?qū)ο笳Z(yǔ)言的特性:繼承、重載、對(duì)象等[13]。 基于Go強(qiáng)大的能力,其廣泛應(yīng)用于區(qū)塊鏈開(kāi)發(fā)、物聯(lián)網(wǎng)開(kāi)發(fā)以及云原生基礎(chǔ)服務(wù)支撐,K8s,Docker,Etcd 等都是基于Go 語(yǔ)言開(kāi)發(fā)的,可見(jiàn)Go 語(yǔ)言的發(fā)展前景極好。 考慮到Go 語(yǔ)言兼顧高性能和開(kāi)發(fā)效率,貼近K8s,可以很方便地使用K8s 進(jìn)行部署,因此使用Go 語(yǔ)言開(kāi)發(fā)一個(gè)分布式主鍵系統(tǒng)[14]。

2 搭建分布式主鍵系統(tǒng)

2.1 分布式主鍵系統(tǒng)總體設(shè)計(jì)

搭建分布式主鍵系統(tǒng)可以解決以下問(wèn)題:(1)統(tǒng)一分布式主鍵服務(wù)[15],通過(guò)Rpc 的方式去使用分布式主鍵,方便業(yè)務(wù)端的開(kāi)發(fā)。 (2)優(yōu)化雪花算法的缺點(diǎn),包括時(shí)間回?fù)堋C(jī)器id 分配以及上限問(wèn)題。 (3)可以同時(shí)滿足多種分布式主鍵的實(shí)現(xiàn),方便地?cái)U(kuò)展業(yè)務(wù)端的需求,只需直接調(diào)用即可。

分布式主鍵系統(tǒng)核心整體調(diào)用如圖2 所示,分布式主鍵系統(tǒng)可以讓業(yè)務(wù)系統(tǒng)直接接入,然后,就可以直接使用各種類型的分布式主鍵。 非常顯著地減輕了業(yè)務(wù)端的壓力。 同時(shí),業(yè)務(wù)端調(diào)用分布式主鍵系統(tǒng)通過(guò)Grpc 的方式,這就保證了調(diào)用的實(shí)時(shí)性。 業(yè)務(wù)端調(diào)用分布式主鍵系統(tǒng)如圖3 所示,通過(guò)Ingress 的方式路由到分布式主鍵服務(wù)集群。

圖2 分布式主鍵系統(tǒng)

圖3 業(yè)務(wù)端調(diào)用分布式主鍵系統(tǒng)

2.2 Grpc 協(xié)議字段設(shè)計(jì)

該分布式主鍵系統(tǒng)采用Go 語(yǔ)言開(kāi)發(fā),使用Grpc遠(yuǎn)程過(guò)程調(diào)用,Grpc 是一個(gè)高性能開(kāi)源的統(tǒng)一的RPC調(diào)用框架。 RPC 即遠(yuǎn)程過(guò)程調(diào)用,使得應(yīng)用程序之間可以進(jìn)行通信,而且也遵從Server/Client 模型。 使用的時(shí)候客戶端調(diào)用Server 提供的接口就像調(diào)用本地的函數(shù)一樣。 Grpc 最大的好處就是快和體積小,Grpc 可以通過(guò)Protobuf 定義接口,Protobuf 可以將數(shù)據(jù)序列化為二進(jìn)制編碼,這可以大幅減少數(shù)據(jù)量,從而提升傳輸 性能。 Grpc 的通信字段定義如圖4 所示。

圖4 Grpc 的通信字段定義

該P(yáng)roto 文件提供了接口的請(qǐng)求結(jié)構(gòu)和返回結(jié)構(gòu),并定義了一個(gè)服務(wù),對(duì)外提供了獲取主鍵的方法。 該分布式唯一主鍵系統(tǒng)目前對(duì)外提供3 種類型的分布式主鍵:(1)基于MySQL 數(shù)據(jù)庫(kù)號(hào)段的;(2)基于Redis自增的;(3)基于雪花算法的。

2.3 實(shí)現(xiàn)基于MySQL 的號(hào)段模式的主鍵

基于MySQL 號(hào)段模式實(shí)現(xiàn)分布式主鍵是以前許多公司經(jīng)常采用的方法。 號(hào)段可以理解為批量獲取。 比如,開(kāi)發(fā)人員會(huì)經(jīng)常批量獲取多個(gè)數(shù)據(jù)緩存在本地,提升系統(tǒng)效率。 當(dāng)需要分布式主鍵時(shí),就向數(shù)據(jù)庫(kù)獲取一個(gè)號(hào)段,如[1,10 000],于是,當(dāng)需要主鍵時(shí),就可以在這個(gè)范圍自增,等用到了10 000,再使用則超過(guò)了范圍,此時(shí)需要再次向數(shù)據(jù)庫(kù)申請(qǐng)?zhí)柖巍?數(shù)據(jù)庫(kù)的表設(shè)計(jì)如圖5 所示。

圖5 數(shù)據(jù)庫(kù)的表設(shè)計(jì)

這個(gè)數(shù)據(jù)表是用來(lái)記錄自增步長(zhǎng)以及當(dāng)前自增id的最大值,對(duì)于自增邏輯的判斷則是在系統(tǒng)實(shí)現(xiàn)中做的。 這種方案不會(huì)強(qiáng)依賴數(shù)據(jù)庫(kù),即使數(shù)據(jù)庫(kù)宕機(jī),系統(tǒng)緩存的號(hào)段也可以再使用一段時(shí)間。 不過(guò),該分布式主鍵系統(tǒng)是一個(gè)集群,集群多個(gè)服務(wù)會(huì)發(fā)生同時(shí)申請(qǐng)?zhí)柖蔚那闆r。 在這種情況下,就會(huì)發(fā)生數(shù)據(jù)一致性的問(wèn)題,解決辦法有:(1)使用數(shù)據(jù)庫(kù)的樂(lè)觀鎖,加一個(gè)Version 字段,在修改的時(shí)候只有跟以前的Version 一樣才會(huì)成功;(2)使用分布式鎖。 本文采用第二種方式。

2.4 實(shí)現(xiàn)基于Redis 的自增模式主鍵

這個(gè)方式的實(shí)現(xiàn)很簡(jiǎn)單,通過(guò)Redis 的Incr 命令實(shí)現(xiàn)。 由于Redis 的單線程特性,天生就支持并發(fā)。 但是,這種方式也有著缺點(diǎn):(1)過(guò)于依賴Redis,如果Redis 出了問(wèn)題,就無(wú)法生成主鍵;(2)Redis 需要開(kāi)啟持久化,要不然Redis 重啟就會(huì)導(dǎo)致主鍵重復(fù);(3)性能比較依賴Redis。 所以,基于Redis 的主鍵有著特殊的使用場(chǎng)景。

2.5 實(shí)現(xiàn)并優(yōu)化雪花算法

針對(duì)時(shí)間回?fù)軉?wèn)題,改進(jìn)的思路是:啟動(dòng)時(shí)間采用的是“歷史時(shí)間”,每次請(qǐng)求只增加序列值,序列值滿了,然后才把“歷史時(shí)間”增加1。 具體做法是,在進(jìn)程啟動(dòng)后,把當(dāng)前時(shí)間(實(shí)際處理采用了延遲20 ms 啟動(dòng))作為這個(gè)機(jī)器進(jìn)程的時(shí)間戳中的起始時(shí)間字段。每次有數(shù)據(jù)請(qǐng)求時(shí),序列號(hào)自增1,當(dāng)序列號(hào)到達(dá)最大值,時(shí)間戳字段自增1,也就是時(shí)間增加1 ms,然后序列號(hào)從0 開(kāi)始計(jì)算。 當(dāng)特別巨大的請(qǐng)求過(guò)來(lái)時(shí),進(jìn)程中的時(shí)間戳達(dá)到真實(shí)的當(dāng)前時(shí)間戳,這個(gè)時(shí)候如果出現(xiàn)時(shí)間回?fù)?就采用業(yè)界常用的方式,首次等待,然后等待一會(huì)兒回?fù)軙r(shí)間,時(shí)間超過(guò)一定量就拋出異常。

針對(duì)機(jī)器id 分配和回收問(wèn)題,機(jī)器id 一共占了10個(gè)二進(jìn)制位, 也就是最多1 024 個(gè)。 其中5 個(gè)Workerid,5 個(gè)Dataid。 id 的分配通過(guò)Redis 實(shí)現(xiàn),核心代碼如圖6 所示。

圖6 核心代碼

其邏輯就是,Redis 存了Workerid 和Dataid,各進(jìn)程通過(guò)分布式鎖的方式去取1 個(gè)Workid 和Dataid 聯(lián)合唯一的id。

3 結(jié)語(yǔ)

通過(guò)Go 語(yǔ)言結(jié)合Grpc 的方式開(kāi)發(fā)了分布式主鍵系統(tǒng),支持3 種分布式主鍵,對(duì)外提供RPC 遠(yuǎn)程調(diào)用。這個(gè)分布式主鍵服務(wù)可以極大地提高開(kāi)發(fā)效率,讓分布式主鍵跟業(yè)務(wù)開(kāi)發(fā)解耦。 同時(shí)也解決了雪花算法存在的幾個(gè)缺點(diǎn),讓雪花算法生成主鍵更加可靠。