1、引言

在《IM消息ID技術(shù)專題》系列文章的前幾篇中，我們已經(jīng)深切體會到消息ID在分布式IM聊天系統(tǒng)中的重要性以及技術(shù)實(shí)現(xiàn)難度，各種消息ID生成算法及實(shí)現(xiàn)雖然各有優(yōu)勢，但受制于具體的應(yīng)用場景，也并不能一招吃遍天下，所以真正在IM系統(tǒng)中該如何落地消息ID算法和實(shí)現(xiàn)邏輯，還是要因地致宜，根據(jù)自已系統(tǒng)的設(shè)計(jì)邏輯和產(chǎn)品定義取其精華，綜合應(yīng)用之。

本文將基于網(wǎng)易嚴(yán)選的訂單ID使用現(xiàn)狀，分享我們是如何結(jié)合業(yè)內(nèi)常用的分布式ID解決方案，從而在此基礎(chǔ)之上進(jìn)行ID特性豐富，并不斷提升系統(tǒng)可用性和穩(wěn)定性保障。同時，也對ID生成算法的落地實(shí)踐過程中遇到坑進(jìn)行了深入剖析。

本篇中的訂單ID雖然不同于IM系統(tǒng)中的消息ID，但其技術(shù)實(shí)踐仍然相通，希望能給你的IM系統(tǒng)消息ID技術(shù)選型也來更多的啟發(fā)。

學(xué)習(xí)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4069-1-1.html）

2、關(guān)于作者

西狂：服務(wù)端研發(fā)工程師, 早期參與嚴(yán)選采購、嚴(yán)選財務(wù)、嚴(yán)選合伙人以及報警平臺等系統(tǒng)后端建設(shè)，目前主要致力于嚴(yán)選交易域技術(shù)演進(jìn)以及業(yè)務(wù)研發(fā)工作。

3、系列文章

本文是系列文章中的第7篇，本系列總目錄如下：

• 《IM消息ID技術(shù)專題(一)：微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）》

• 《IM消息ID技術(shù)專題(二)：微信的海量IM聊天消息序列號生成實(shí)踐（容災(zāi)方案篇）》

• 《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》

• 《IM消息ID技術(shù)專題(四)：深度解密美團(tuán)的分布式ID生成算法》

• 《IM消息ID技術(shù)專題(五)：開源分布式ID生成器UidGenerator的技術(shù)實(shí)現(xiàn)》

• 《IM消息ID技術(shù)專題(六)：深度解密滴滴的高性能ID生成器(Tinyid)》

• 《IM消息ID技術(shù)專題(七)：網(wǎng)易嚴(yán)選分布式ID的技術(shù)選型、優(yōu)化、落地實(shí)踐》（* 本文）

4、為什么需要分布式ID？

4.1?業(yè)務(wù)背景

如上圖所示，對于網(wǎng)易嚴(yán)選的主站、分銷和tob都會生成各自的訂單ID，在同步訂單數(shù)據(jù)到訂單中心的時候，訂單中心會生成一個訂單中心內(nèi)部的一個訂單號，只是推送給到下游倉配時使用的訂單ID略有不同。

4.2 帶來的問題

?因?yàn)橛唵蜪D使用的混亂，導(dǎo)致了一系列問題的產(chǎn)生，例如:?溝通壁壘 、管控困難以及代碼腐化等等。

4.3 技術(shù)目標(biāo)

?我們希望通過分布式ID來幫助生成訂單ID，在業(yè)務(wù)規(guī)則上必須全局唯一、安全性高，在性能上要高可用、低延遲。

5、我們的分布式ID架構(gòu)原理

5.1 技術(shù)選型

下表是業(yè)內(nèi)常見的分布式ID解決方案：

綜合考慮是否支持水平擴(kuò)展以及能夠顯示指定ID長度，最終選擇的是Leaf的Segment模式（詳見《深度解密美團(tuán)的分布式ID生成算法》）。

5.2 架構(gòu)簡介

Leaf采用了預(yù)分發(fā)的方式來生成ID（如下圖所示），在DB之上搭載若干個Server，每個Server在啟動的時候，都會去DB中拿固定長度的ID列表，存放于內(nèi)存中，因?yàn)镮D是基于內(nèi)存分發(fā)的，所以可以做到很高效。

在數(shù)據(jù)持久化方面，每次去DB拿固定長度的ID列表，只是把最大的ID持久化。

整體架構(gòu)實(shí)現(xiàn)比較簡單，主要是為了盡快解決業(yè)務(wù)層DB壓力的問題，但是在生產(chǎn)環(huán)境中也暴露出一些問題。

比如：

• 1）TP999數(shù)據(jù)波動大，當(dāng)號段使用完之后還是會hang在更新數(shù)據(jù)庫的I/O上，tp999數(shù)據(jù)會出現(xiàn)偶爾的尖刺；

• 2）當(dāng)更新DB號段的時候，如果DB宕機(jī)或者發(fā)生主從切換，會導(dǎo)致一段時間的服務(wù)不可用。

5.3 可用性優(yōu)化

為了解決上面提到這個兩個問題，引入雙Buffer機(jī)制和異步更新策略，當(dāng)一個Buffer消耗到某個臨界點(diǎn)時，就會異步的觸發(fā)任務(wù)，把下一個號段加載到內(nèi)存中。

保證無論何時DB出現(xiàn)問題，都能有一個Buffer的號段可以正常對外提供服務(wù)，只要DB在一個Buffer的下發(fā)的周期內(nèi)恢復(fù)，就不會影響整個Leaf的可用性。

5.4 步長動態(tài)調(diào)整

號段長度在固定不變的前提下，流量的突增和銳減都會使得正常流量下維持原有號段正常工作的時間縮短和提升。

可以嘗試使用以下關(guān)系表達(dá)式來描述：

Q * T = L

(Q：服務(wù)qps? L：號段長度? T：號段更新周期)

但是Leaf的本質(zhì)是希望T固定，如果Q和L可以正相關(guān)，T就可以趨于一個定值。

所以在Leaf每次更新號段的時候，會根據(jù)上一次號段更新的周期T和號段長度step，來決定下一次號段長度nextStep。

如下所示：

T < 15min，nextStep = step * 2

15min < T < 30min，nextStep = step

T > 30min，nextStep = step / 2

(初始指定step <= nextStep <= 最大值(自定義：100W))

6、我們做了什么改進(jìn)？

6.1 特性豐富

?

通過結(jié)合嚴(yán)選的實(shí)際業(yè)務(wù)場景，進(jìn)行了特性化支持，例如支持批量ID獲取、大促提前擴(kuò)容以及提前跳段處理。

6.2 可用性保障

1）針對DB：

?DB（MySql）采用主從模式（讀寫分離、降低主庫壓力），一主兩從的配置方式，Master和Slave之間采用的是半同步復(fù)制（數(shù)據(jù)一致性要求，后期可考慮使用MySql Group Replication）。同時還添加了雙1配置，保證不丟數(shù)據(jù)。

2）引入SDK：

通過引入SDK可以降低各個業(yè)務(wù)方的接入成本、降低Leaf服務(wù)端壓力以及在Leaf服務(wù)不可用時，客戶端起到短暫降級的效果。

SDK的實(shí)現(xiàn)原理和Leaf類似，在項(xiàng)目啟動之初會加載業(yè)務(wù)關(guān)心參數(shù)配置信息，在應(yīng)用構(gòu)建本地緩存，同樣采用了雙Buffer存儲模式。

6.3 穩(wěn)定性保障

1）運(yùn)維方面：

主要分為3個方面：

• 1）日志監(jiān)控：可以幫助發(fā)現(xiàn)預(yù)期之外的異常情況；

• 2）流量監(jiān)控：流有助于號段長度的評估范圍，預(yù)防號段被快速消費(fèi)的極端場景；

• 3）線上巡檢：可以時刻對服務(wù)進(jìn)行存活校驗(yàn)。

2）SLA高可用方面：

除了運(yùn)維之外還做了SLA的接入，通常用SLA來衡量系統(tǒng)的穩(wěn)定性，除此之外我們還按照接口維度設(shè)定了SLO目標(biāo)規(guī)則，目前的指標(biāo)項(xiàng)比較單一只有請求延遲和錯誤率這兩項(xiàng)。

?

?

7、我們遇到的坑

7.1 問題發(fā)現(xiàn)

如下圖所示，我們發(fā)現(xiàn)每次服務(wù)啟動上線接口的rt（響應(yīng)時間）都要比平時高的多，但是過了一段時間之后卻又恢復(fù)成正常水平。

7.2 問題探究

在分析之前，我們可以先簡單的回顧下java虛擬機(jī)是如何運(yùn)行Java字節(jié)碼的。

虛擬機(jī)視角下Java字節(jié)碼如何被虛擬機(jī)運(yùn)行：

Java虛擬機(jī)將class文件加載到虛擬機(jī)中，然后將字節(jié)碼翻譯成機(jī)器碼給底層硬件執(zhí)行，而這里的翻譯有兩種形式，解釋執(zhí)行和編譯執(zhí)行。前者的優(yōu)勢在于無需等待編譯，后者的優(yōu)勢在于實(shí)際運(yùn)行速度更快。HotSpot默認(rèn)采用混合模式，它會先解釋執(zhí)行字節(jié)碼，然后將其中反復(fù)執(zhí)行的熱點(diǎn)代碼，以方法為單位進(jìn)行即時編譯，JVM是依據(jù)方法的調(diào)用次數(shù)以及循環(huán)回邊的執(zhí)行次數(shù)來觸發(fā)JIT編譯的。

在Java7之前我們可以根據(jù)程序的特性選擇對應(yīng)的即時編譯器。Java7開始引入分層編譯機(jī)制（-XX:+TieredCompilation）：綜合了C1的啟動性能優(yōu)勢和C2的峰值性能優(yōu)勢。

分層編譯將JVM的執(zhí)行狀態(tài)分為了5個層次：

• L0：解釋執(zhí)行（也會profiling）；

• L1：執(zhí)行不帶profiling的C1代碼；

• L2：執(zhí)行僅帶方法調(diào)用次數(shù)和循環(huán)回邊執(zhí)行次數(shù)profiling的C1代碼；

• L3：執(zhí)行帶所有profiling的C1代碼；

• L4：執(zhí)行C2代碼。

對于C1編譯的三個層次，按執(zhí)行效率從高至低：L1 > L2 > L3, 這是因?yàn)閜rofiling越多，額外的性能開銷越大。通常情況下，C2代碼的執(zhí)行效率比C1代碼高出30%以上。（這里需要注意的是Java8默認(rèn)開啟了分層編譯）

這張圖列出了常見的分層編譯的編譯路徑：

• 1）通常情況下，熱點(diǎn)方法會被第三層的C1編譯器編譯，再被C2編譯器編譯(0-> 3-> 4)；

• 2）如果方法的字節(jié)數(shù)目比較少并且第三層的profilling沒有可收集的數(shù)據(jù)，jvm會判定該方法對于C1和C2的執(zhí)行效率相同，在經(jīng)過3層的C1編譯過后，直接回到1層的C1(0-> 3-> 1)；

• 3）在C1忙碌的情況下，JVM在解釋執(zhí)行過程中對程序進(jìn)行profiling，而后直接由4層的C2編譯(0-> 4)；

• 4）在C2忙碌的情況下，方法會被2層的C1編譯，然后再被3層的C1編譯，以減少方法在3層的執(zhí)行時間(0-> 2-> 3-> 4)。

上圖是項(xiàng)目啟動時的分層編譯日志以及整個過程接口響應(yīng)RT。

從圖中可以看到先是執(zhí)行了C1編譯，再執(zhí)行C2編譯（日志文件中的3和4分別打標(biāo)L3和L4），滿足?0->3->4?編譯順序。

發(fā)現(xiàn)從C1編譯到C2編譯耗時過程比較長，這符合我們一開始提出的疑問，為什么項(xiàng)目啟動需要經(jīng)過一段時間接口RT才能趨于穩(wěn)定。

7.3 解決方案

為了能在項(xiàng)目啟動之初，快速達(dá)到接口RT峰值，因此只要盡最大程度縮短解釋執(zhí)行這個中間過程即可。

相應(yīng)的解決方案：

• 方案 1：關(guān)閉分層編譯，降低編譯閾值；

• 方案 2：Mock接口數(shù)據(jù), 快速觸發(fā)JIT編譯以及C2編譯；

• 方案 3：Java9 AOT提前編譯。

針對方案3：Java9中支持新特性AOT提前編譯，相比較于JIT即時編譯而言，AOT在運(yùn)行前就已經(jīng)編譯好了，避免 JIT 編譯器的運(yùn)行時性能消耗，同時避免解釋程序的早期性能開銷，可以極大提高java代碼性能。

8、落地使用概況

Leaf已經(jīng)在線上環(huán)境投入使用，各個業(yè)務(wù)方（包括主站、渠道、tob）也相應(yīng)接入進(jìn)行統(tǒng)一整改，自此嚴(yán)選訂單ID生成得到統(tǒng)一收攏。

在整個嚴(yán)選的落地情況，按照業(yè)務(wù)維度，目前累計(jì)接入3個業(yè)務(wù)，分別是訂單ID、訂單快照ID、訂單商品快照ID，都經(jīng)受住了雙十一和雙十二考驗(yàn)。

9、參考資料

[1]?微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）

[2]?解密融云IM產(chǎn)品的聊天消息ID生成策略

[3]?深度解密美團(tuán)的分布式ID生成算法

[4]?深度解密滴滴的高性能ID生成器(Tinyid)

（本文已同步發(fā)布于：http://www.52im.net/thread-4069-1-1.html）