京東秒殺是京東最大的營銷頻道，近年來隨著業務的高速發展，頻道商品數量和用戶流量都呈現出迅猛增長的態勢。

[[441138]]

圖片來自 包圖網

同時業務方規劃未來頻道商品數量會增加 5 至 10 倍，對商品池擴容訴求較為強烈，這對我們現有的系統架構提出了挑戰。

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

京東秒殺頻道業務主要包括兩部分：

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

圖 1：京東秒殺頻道業務

秒殺系統是一個高并發大流量系統，使用緩存技術來提高系統性能。

在頻道核心服務的歷史業務迭代過程中，采用了在內存中全量緩存商品池數據的緩存方案。

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

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

原系統架構如圖 2 所示：

圖 2：京東秒殺原系統架構圖

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

秒殺 SOA 系統監聽通知后從 JIMDB 中獲取最新的數據，更新本地緩存，以提供頻道核心服務和商品打標服務。

問題分析

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

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

圖 3：系統異常監控

通過 JVM 堆內存變化圖可以看到：

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

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

圖 4：發生 Full GC 前堆內存對象

圖 5：發生 Full GC 后堆內存對象

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

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

結合系統架構分析，可以確定是在商品的覆蓋更新過程中，舊對象未被回收而不斷進入老年代，老年代內存占用越來越高，最終導致堆內存不足而產生 Full GC。

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

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

圖 6：問題代碼

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

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

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

大對象會導致內存剩余空間足夠時，就提前觸發垃圾收集以獲取足夠的連續空間來安置，同時大對象的頻繁復制也會影響性能。

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

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

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

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

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

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

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

圖 7：GC 日志

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

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

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

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

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

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

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

優化方案

①雙緩存區定時散列更新

通過上面的分析可以發現，為了防止堆內存增長過快，需要控制商品數據更新的粒度和頻次。

原有的商品更新方案是商品數據按照活動的維度全量覆蓋更新，每個商品的狀態變化都會觸發更新操作。

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

圖 8：雙緩存區定時散列更新示意圖

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

同時為了控制數據更新的頻率，我們在 SOA 端設計了雙緩存區定時切量的方式。

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

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

該方案散列份數和定時時間可以根據具體業務情況進行調整，在性能和實時性上取得平衡，在上線后取得了較好的優化效果。

②引入本地 LRU 緩存

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

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

系統拆分：原系統存在的問題是，頻道核心服務和商品打標服務共用相同的基礎數據，存在系統耦合的問題。

從商品池角度分析，頻道核心服務商品池是秒殺商品池的子集。從業務角度分析，頻道核心服務業務邏輯復雜，調用鏈路長，響應時間長，商品打標服務邏輯簡單，調用鏈路短，響應時間短。

將頻道核心服務和商品打標服務進行拆分，獨立部署，實現資源隔離，這樣可以根據業務特點做針對性優化。

頻道核心服務可以減少內存中商品緩存的數量，商品打標服務可以升級商品緩存方案，另外也可以規避架構升級過程中對頻道核心服務的影響。

圖 9：系統拆分

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

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

在原有的系統架構中秒殺商品池全量緩存在內存中，這會導致商品數量激增時，JVM 堆內存資源緊張，商品池的容量受到限制，且無法水平擴容。

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

圖 10：緩存方案升級

對于拆封后的商品打標服務，緩存方案優化的總體思路是實現冷熱數據的拆分。

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

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

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

其優勢有：

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

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

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

升級后的架構圖如圖 11 所示：

圖 11：升級后架構圖

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

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

③引入布隆過濾器

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

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

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

分析發現這種方式空間復雜度高，內存占用比較高。過濾器優化為布隆過濾器后，內存占用降低，性能得到進一步提升。

優化效果

在完成架構升級后，經過單機壓測、灰度驗證、灰度上線、全量壓測等過程嚴格驗證了新系統的性能和結果準確性，在 618 大促前新系統全量平穩上線。

從近年來大促期間系統表現來看，優化效果顯著，如圖 12、圖 13 所示，主要體現在以下幾個方面。

圖 12：大促性能表現對比

業務支撐：秒殺商品池數量持續增長，由于架構的調整全量商品緩存在 JIMDB，新系統支持水平擴容，后續可支持更高數量級的商品，滿足業務的長期規劃。

性能優化：大促期間打標服務的接口 tp999 持續下降，618 大促接口性能提升 90%，同時從接口性能對比上看，接口性能的毛刺現象得到解決。

穩定性提升：GC 頻率持續下降，系統穩定性得到提高。

圖 13：接口性能監控對比

總結

本次秒殺商品池擴容優化專項通過優化商品更新方式、系統拆分、優化緩存方案等方式，實現了系統架構升級，提升了頻道的商品容量和性能，達到了預設目標。

作者：洪超

編輯：陶家龍

來源：轉載自公眾號京東零售技術