京東秒殺是京東最大的營銷頻道，近年來隨著業(yè)務(wù)的高速發(fā)展，頻道商品數(shù)量和用戶流量都呈現(xiàn)出迅猛增長的態(tài)勢。

[[441138]]

圖片來自 包圖網(wǎng)

同時業(yè)務(wù)方規(guī)劃未來頻道商品數(shù)量會增加 5 至 10 倍，對商品池擴容訴求較為強烈，這對我們現(xiàn)有的系統(tǒng)架構(gòu)提出了挑戰(zhàn)。

為了應(yīng)對商品數(shù)量激增引起的風險，秒殺后臺組在年初成立了秒殺商品池擴容技術(shù)優(yōu)化專項，在 618 前按計劃完成了千萬級商品池擴容的架構(gòu)升級。本文主要介紹秒殺商品池擴容專項的優(yōu)化經(jīng)驗。

京東秒殺頻道業(yè)務(wù)主要包括兩部分：

• 一部分是頻道核心服務(wù)，即直接面向終端用戶提供頻道服務(wù)。
• 另一部分是維護秒殺商品池數(shù)據(jù)，為商詳、購物車等多端提供秒殺商品讀服務(wù)，以展示“京東秒殺”的促銷氛圍標簽，我們稱為秒殺商品打標服務(wù)。

圖 1：京東秒殺頻道業(yè)務(wù)

秒殺系統(tǒng)是一個高并發(fā)大流量系統(tǒng)，使用緩存技術(shù)來提高系統(tǒng)性能。

在頻道核心服務(wù)的歷史業(yè)務(wù)迭代過程中，采用了在內(nèi)存中全量緩存商品池數(shù)據(jù)的緩存方案。

這是因為頻道業(yè)務(wù)中存在全量商品按照多維度排序的訴求，同時在頻道發(fā)展初期商品數(shù)量不多，采用全量緩存的方式內(nèi)存壓力不大，開發(fā)成本較低。

由于秒殺商品存在時促銷、庫存有限的特點，對數(shù)據(jù)更新的實時性要求較高，我們通過 ZK 通知的方式實現(xiàn)商品數(shù)據(jù)更新。

原系統(tǒng)架構(gòu)如圖 2 所示：

圖 2：京東秒殺原系統(tǒng)架構(gòu)圖

秒殺 CMS 系統(tǒng)在商品錄入或更新時，以活動的維度將商品數(shù)據(jù)推動到 JIMDB(京東內(nèi)部分布式緩存與高速鍵值存儲服務(wù)，類似于 Redis)中，同時通過 ZooKeeper 發(fā)送通知。

秒殺 SOA 系統(tǒng)監(jiān)聽通知后從 JIMDB 中獲取最新的數(shù)據(jù)，更新本地緩存，以提供頻道核心服務(wù)和商品打標服務(wù)。

問題分析

在以往大促期間，當商品池數(shù)量激增時，觀察到系統(tǒng)的堆內(nèi)存消耗過快，同時 Minor GC 垃圾回收效果有限，Minor GC 回收后堆內(nèi)存低點不斷抬高，堆內(nèi)存呈持續(xù)增長的態(tài)勢，并且會規(guī)律性地定期猛增。

Full GC 較為頻繁，對 CPU 利用率的影響較大，接口性能毛刺現(xiàn)象嚴重。

圖 3：系統(tǒng)異常監(jiān)控

通過 JVM 堆內(nèi)存變化圖可以看到：

• 堆空間增長很快，且 Minor GC 無法回收新增的堆空間。
• 堆空間呈現(xiàn)有規(guī)律的上升，且會定期猛增，推測和定時任務(wù)有關(guān)。
• Full GC后，內(nèi)存回收率高，排除內(nèi)存泄漏。
• Full GC 對 CPU 利用率影響較大。

頻繁 GC 對系統(tǒng)的穩(wěn)定性和接口的性能造成嚴重的影響分析堆對象增長情況，通過 jmap -histo 指令在發(fā)生 Full GC 前后打印 JVM 堆中的對象，如圖 4、圖 5 所示：

圖 4：發(fā)生 Full GC 前堆內(nèi)存對象

圖 5：發(fā)生 Full GC 后堆內(nèi)存對象

從 Full GC 前后堆中對象分布情況分析，以品類秒殺為例，在 Full GC 后堆中不到 100 萬商品對象，占內(nèi)存 125M 左右，和品類秒殺實際有效商品數(shù)量大致相當， String 對象共占約 385M 左右。

而在發(fā)生 Full GC 前，堆中品類秒殺商品數(shù)量達到了接近 500 萬，占用內(nèi)存達到了 700M，另外 String 對象占用內(nèi)存達到 1.2G。

結(jié)合系統(tǒng)架構(gòu)分析，可以確定是在商品的覆蓋更新過程中，舊對象未被回收而不斷進入老年代，老年代內(nèi)存占用越來越高，最終導(dǎo)致堆內(nèi)存不足而產(chǎn)生 Full GC。

堆對象中的 String 對象也是這種更新方式的副產(chǎn)品，這是因為商品數(shù)據(jù)在 JIMDB 中以 String 方式存儲，在更新時會從 JIMDB 中拉取到本地反序列化后得到對象列表。

可以從圖 6 所示問題代碼中看到產(chǎn)生大 String 對象的原因：

圖 6：問題代碼

對于上述的全量更新場景，舊對象和臨時產(chǎn)生的 String 對象滿足垃圾回收的條件，為什么沒有在 Minor GC 階段被回收?

我們知道大多數(shù)情況下，對象在新生代 Eden 區(qū)中分配，對象進入老年代有以下幾種情況：

①大對象直接進入年老代：大對象即需要大量連續(xù)內(nèi)存空間的 Java 對象，如長字符串及數(shù)組。

大對象會導(dǎo)致內(nèi)存剩余空間足夠時，就提前觸發(fā)垃圾收集以獲取足夠的連續(xù)空間來安置，同時大對象的頻繁復(fù)制也會影響性能。

虛擬機提供了一個 -XX:PretenureSizeThreshold 參數(shù)，使大于該閾值的對象直接在老年代分配。為避免臨時 String 對象直接進入老年代的情況，我們顯式關(guān)閉了該功能。

②長期存活的對象將進入年老代：虛擬機給每個對象定義了一個對象年齡計數(shù)器，在對象在 Eden 創(chuàng)建并經(jīng)過第一次 Minor GC 后仍然存活，并能被 Suivivor 容納的話，將會被移動到 Survivor 空間，并對象年齡設(shè)置為 1。

每經(jīng)歷一次 Minor GC，年齡增加 1 歲，當?shù)竭_閾值時(可以通過參數(shù) -XX: MaxTenuringThreshold 設(shè)置，CMS 垃圾回收器默認值為 6)，將會晉升老年代。上述分析情況，臨時 String 對象不會存活過 6 次 Minor GC。

③動態(tài)對象年齡判定：為了更好地適應(yīng)不同程序內(nèi)存狀況，虛擬機并不硬性要求對象年齡達到 MaxTenuringThreshold 才能晉升老年代。

如果在 Survivor 空間中小于等于某個年齡所有對象大小的總和大于 Survivor 空間的一半，年齡大于或等于該年齡的對象就可以直接進入年老代。

通過上述分析，我們發(fā)現(xiàn)臨時 String 對象最有可能觸發(fā)了動態(tài)對象年齡判定機制而進入老年代。

打印虛擬機 GC 信息，并添加 -XX: +PrintTenuringDistribution 參數(shù)來打印發(fā)生 GC 時新生代的對象年齡信息，得到圖 7 所示 GC 日志信息：

圖 7：GC 日志

從 GC 日志可以看到，Survivor 空間大小為 358M，Survivor 區(qū)的目標使用率默認是 50%，Desired Survivor size 是 179M，age <= 2 的對象大小總和為 269M。

因此雖然設(shè)定的晉升閾值是 6，虛擬機動態(tài)計算晉升閾值為 2，最終導(dǎo)致 age 大于等于 2 的對象都進入老年代。

我們嘗試從優(yōu)化 JVM 參數(shù)的方式解決問題，效果并不理想。做過的嘗試有：

增大年輕代的空間來減少對象進入老年代，結(jié)果適得其反，STW 更加頻繁，CPU 利用率波動也更大。

改用 G1 垃圾收集器，效果不明顯，CPU 利用率波動也更大。

顯式設(shè)置晉升老年代的閾值(MaxTenuringThreshold)，試圖推遲對象進入老年代的速度，無任何效果。

上述問題分析的結(jié)論對我們的啟示是：如果在新生代中頻繁產(chǎn)生朝生夕死的大對象，會觸發(fā)虛擬機的動態(tài)對象年齡判定機制，降低對象進入老年代的門檻，導(dǎo)致堆內(nèi)存增長過快。

優(yōu)化方案

①雙緩存區(qū)定時散列更新

通過上面的分析可以發(fā)現(xiàn)，為了防止堆內(nèi)存增長過快，需要控制商品數(shù)據(jù)更新的粒度和頻次。

原有的商品更新方案是商品數(shù)據(jù)按照活動的維度全量覆蓋更新，每個商品的狀態(tài)變化都會觸發(fā)更新操作。

我們希望數(shù)據(jù)更新能控制在更小的范圍，同時能夠控制數(shù)據(jù)更新的頻率，最終設(shè)計出雙緩存區(qū)定時散列更新方案，如圖 8 所示。

圖 8：雙緩存區(qū)定時散列更新示意圖

該方案的實現(xiàn)是將活動下的商品以 SKU 維度散列到不同的桶中，更新的操作以桶的粒度進行。

同時為了控制數(shù)據(jù)更新的頻率，我們在 SOA 端設(shè)計了雙緩存區(qū)定時切量的方式。

在 CMS 商品數(shù)據(jù)更新時，會映射到需要更新的桶，并實時通知 SOA 端;在 SOA 端收到 ZK 通知后，會在讀緩存區(qū)標記需要更新的桶，但不會實時的更新數(shù)據(jù)。

在達到定時時間后，會自動切換讀寫緩存區(qū)，此時會讀取讀緩存區(qū)中標記的待更新桶，從 JIMDB 中獲取桶對應(yīng)的商品列表，完成數(shù)據(jù)的細粒度分段更新。

該方案散列份數(shù)和定時時間可以根據(jù)具體業(yè)務(wù)情況進行調(diào)整，在性能和實時性上取得平衡，在上線后取得了較好的優(yōu)化效果。

②引入本地 LRU 緩存

雙緩存區(qū)定時散列更新的方案雖然在系統(tǒng)性能上得到了提升，但依然無法支持千萬級商品的擴容。

為了徹底擺脫機器內(nèi)存對商品池容量的限制，我們啟動了秒殺架構(gòu)的全面升級，核心思路是引入本地 LRU 緩存組件，實現(xiàn)冷數(shù)據(jù)淘汰，以控制內(nèi)存中緩存商品的總數(shù)量在安全區(qū)間。

系統(tǒng)拆分：原系統(tǒng)存在的問題是，頻道核心服務(wù)和商品打標服務(wù)共用相同的基礎(chǔ)數(shù)據(jù)，存在系統(tǒng)耦合的問題。

從商品池角度分析，頻道核心服務(wù)商品池是秒殺商品池的子集。從業(yè)務(wù)角度分析，頻道核心服務(wù)業(yè)務(wù)邏輯復(fù)雜，調(diào)用鏈路長，響應(yīng)時間長，商品打標服務(wù)邏輯簡單，調(diào)用鏈路短，響應(yīng)時間短。

將頻道核心服務(wù)和商品打標服務(wù)進行拆分，獨立部署，實現(xiàn)資源隔離，這樣可以根據(jù)業(yè)務(wù)特點做針對性優(yōu)化。

頻道核心服務(wù)可以減少內(nèi)存中商品緩存的數(shù)量，商品打標服務(wù)可以升級商品緩存方案，另外也可以規(guī)避架構(gòu)升級過程中對頻道核心服務(wù)的影響。

圖 9：系統(tǒng)拆分

緩存方案優(yōu)化：頻道核心服務(wù)歷史邏輯復(fù)雜，且直接面向終端用戶，升級難度大。

在擴容專項一期中的主要優(yōu)化點是拆分出頻道核心服務(wù)商品池，去除非頻道展示商品，以減少商品緩存數(shù)量。一期優(yōu)化主要聚焦于秒殺打標服務(wù)的緩存方案升級。

在原有的系統(tǒng)架構(gòu)中秒殺商品池全量緩存在內(nèi)存中，這會導(dǎo)致商品數(shù)量激增時，JVM 堆內(nèi)存資源緊張，商品池的容量受到限制，且無法水平擴容。

商品以活動的維度進行存儲和更新，會導(dǎo)致大 key 的問題，在進行覆蓋更新時會在內(nèi)存中產(chǎn)生臨時的大對象，不利于 JVM 垃圾回收表現(xiàn)。

圖 10：緩存方案升級

對于拆封后的商品打標服務(wù)，緩存方案優(yōu)化的總體思路是實現(xiàn)冷熱數(shù)據(jù)的拆分。

升級后的商品打標服務(wù)不再使用本地全量緩存，而是使用 JIMDB 全量緩存+本地 LRU 緩存組件的方式。

對緩存組件的要求是在緩存數(shù)據(jù)達到預(yù)設(shè)商品數(shù)量上限時，實現(xiàn)冷數(shù)據(jù)的清退，同時具有較高的緩存命中率和讀寫性能。

在對比常用的緩存框架 Caffeine 和 Guava Cache 后最終采用 Caffeine 緩存。

其優(yōu)勢有：

• 性能更優(yōu)。Caffeine 的讀寫性能顯著優(yōu)于 Guava， 這是由于 Guava 中讀寫操作夾雜著過期時間的處理，一次 put 操作中有可能會觸發(fā)淘汰操作，所以其讀寫性能會受到一定影響。

而 Caffeine 對這些事件的操作是異步的，將事件提交至隊列，通過默認的 ForkJoinPool.commonPool() 或自己配置的線程池，進行取隊列操作，再進行異步淘汰、過期操作。

• 高命中率，低內(nèi)存占用。Guava 使用分段 LRU 算法，而 Caffeine 使用了一種結(jié)合 LRU、LFU 優(yōu)點的算法：W-TinyLFU，可以使用較少的資源來記錄訪問頻次，同時能夠解決稀疏突發(fā)訪問元素的問題。

升級后的架構(gòu)圖如圖 11 所示：

圖 11：升級后架構(gòu)圖

頻道核心服務(wù)和商品打標服務(wù)獨立部署，資源隔離。秒殺 CMS 在商品錄入和更新時，以 SKU 維度寫入 JIMDB 中組成全量秒殺商品池。

商品打標服務(wù)通過 Caffeine 緩存的方式，設(shè)置寫入寫入 30s 過期，最大緩存 200w 商品數(shù)據(jù)，實現(xiàn)熱數(shù)據(jù)緩存，過期數(shù)據(jù)和冷數(shù)據(jù)的淘汰。

③引入布隆過濾器

在非秒殺 SKU 查詢處理上，為了避免緩存穿透問題(即單個無效商品的高頻次查詢，如果本地緩存中沒有則每次請求都會訪問到 JIMDB)，我們對于非秒殺商品的查詢結(jié)果，在本地緩存中存儲一個空值標識，避免無效 SKU 請求每次都訪問到 JIMDB。

商詳、購物車等渠道商品池數(shù)量比秒殺商品池高幾個數(shù)量級，秒殺查詢服務(wù)請求 SKU 中存在大量的非秒殺商品，這會導(dǎo)致本地緩存的命中率降低，同時帶來緩存雪崩的風險。

為了攔截大量非秒殺 SKU 的請求，我們引入過濾器機制。在本地過濾器的選擇上，我們嘗試使用所有有效商品 SkuId 組成的 Set 集合來生成本地過濾器，上線后觀察到本地過濾器數(shù)據(jù)更新時會產(chǎn)生性能波動。

分析發(fā)現(xiàn)這種方式空間復(fù)雜度高，內(nèi)存占用比較高。過濾器優(yōu)化為布隆過濾器后，內(nèi)存占用降低，性能得到進一步提升。

優(yōu)化效果

在完成架構(gòu)升級后，經(jīng)過單機壓測、灰度驗證、灰度上線、全量壓測等過程嚴格驗證了新系統(tǒng)的性能和結(jié)果準確性，在 618 大促前新系統(tǒng)全量平穩(wěn)上線。

從近年來大促期間系統(tǒng)表現(xiàn)來看，優(yōu)化效果顯著，如圖 12、圖 13 所示，主要體現(xiàn)在以下幾個方面。

圖 12：大促性能表現(xiàn)對比

業(yè)務(wù)支撐：秒殺商品池數(shù)量持續(xù)增長，由于架構(gòu)的調(diào)整全量商品緩存在 JIMDB，新系統(tǒng)支持水平擴容，后續(xù)可支持更高數(shù)量級的商品，滿足業(yè)務(wù)的長期規(guī)劃。

性能優(yōu)化：大促期間打標服務(wù)的接口 tp999 持續(xù)下降，618 大促接口性能提升 90%，同時從接口性能對比上看，接口性能的毛刺現(xiàn)象得到解決。

穩(wěn)定性提升：GC 頻率持續(xù)下降，系統(tǒng)穩(wěn)定性得到提高。

圖 13：接口性能監(jiān)控對比

總結(jié)

本次秒殺商品池擴容優(yōu)化專項通過優(yōu)化商品更新方式、系統(tǒng)拆分、優(yōu)化緩存方案等方式，實現(xiàn)了系統(tǒng)架構(gòu)升級，提升了頻道的商品容量和性能，達到了預(yù)設(shè)目標。

作者：洪超

編輯：陶家龍

來源：轉(zhuǎn)載自公眾號京東零售技術(shù)