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

[[441138]]

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

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

為了應(yīng)對(duì)商品數(shù)量激增引起的風(fēng)險(xiǎn)，秒殺后臺(tái)組在年初成立了秒殺商品池?cái)U(kuò)容技術(shù)優(yōu)化專項(xiàng)，在 618 前按計(jì)劃完成了千萬級(jí)商品池?cái)U(kuò)容的架構(gòu)升級(jí)。本文主要介紹秒殺商品池?cái)U(kuò)容專項(xiàng)的優(yōu)化經(jīng)驗(yàn)。

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

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

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

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

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

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

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

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

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

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

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

問題分析

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

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

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

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

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

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

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

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

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

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

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

堆對(duì)象中的 String 對(duì)象也是這種更新方式的副產(chǎn)品，這是因?yàn)樯唐窋?shù)據(jù)在 JIMDB 中以 String 方式存儲(chǔ)，在更新時(shí)會(huì)從 JIMDB 中拉取到本地反序列化后得到對(duì)象列表。

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

圖 6：?jiǎn)栴}代碼

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

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

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

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

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

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

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

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

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

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

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

圖 7：GC 日志

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

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

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

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

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

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

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

優(yōu)化方案

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

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

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

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

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

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

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

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

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

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

②引入本地 LRU 緩存

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

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

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

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

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

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

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

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

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

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

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

圖 10：緩存方案升級(jí)

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

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

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

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

其優(yōu)勢(shì)有：

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

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

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

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

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

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

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

③引入布隆過濾器

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

商詳、購物車等渠道商品池?cái)?shù)量比秒殺商品池高幾個(gè)數(shù)量級(jí)，秒殺查詢服務(wù)請(qǐng)求 SKU 中存在大量的非秒殺商品，這會(huì)導(dǎo)致本地緩存的命中率降低，同時(shí)帶來緩存雪崩的風(fēng)險(xiǎn)。

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

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

優(yōu)化效果

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

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

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

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

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

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

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

總結(jié)

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

作者：洪超

編輯：陶家龍

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