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

秦攀科,李有卿*

0 引言

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

1 分布式主鍵介紹

1.1 雪花算法

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

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

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

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

1.2 基于Redis 的分布式主鍵

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

1.3 基于MySQL 的號段模式主鍵

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

1.4 Go 語言介紹

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

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

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

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

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

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

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

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

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

圖4 Grpc 的通信字段定義

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

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

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

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

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

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

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

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

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

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

圖6 核心代碼

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

3 結(jié)語

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