百萬級QPS，支撐淘寶雙11需要哪些技術(shù)
前言
又到一年雙11，相信大部分同學都曾經(jīng)有這個疑問：支撐起淘寶雙11這么大的流量，需要用到哪些核心技術(shù)？性能優(yōu)化系列的第二篇我想跟大家探討一下這個話題。
完整的雙11鏈路是非常長的，我當前也沒這個實力跟大家去探討完整的鏈路，本文只跟大家探討其中的一個核心環(huán)節(jié)：商品瀏覽。
商品瀏覽是整個鏈路中流量最大的或者至少是之一，這個大家應(yīng)該不會有疑問，因為幾乎每個環(huán)節(jié)都需要商品瀏覽。
阿里云公布的2020年雙11訂單創(chuàng)建峰值是58.3萬筆/秒，而我們在下單前經(jīng)常會點來點去看這個看那個的，因此商品瀏覽肯定至少在百萬QPS級別。
廢話不多說，直接開懟。
正文
1、MySQL硬抗
不知道有沒有老鐵想過用MySQL硬抗雙11百萬QPS，反正我是沒有
，不過我們還是用數(shù)據(jù)來說說為什么不可能這么做。
根據(jù)MySQL官方的基準測試，MySQL在通常模式下的性能如下圖所示：
當然這個數(shù)據(jù)僅供參考，實際性能跟使用的機器配置、數(shù)據(jù)量、讀寫比例啥的都有影響。
首先，淘寶的數(shù)據(jù)量肯定是比較大的，這個毋庸置疑，但是無論怎么分庫分表，由于成本等原因，肯定每個庫還是會有大量的數(shù)據(jù)。
我當前所在的業(yè)務(wù)剛好數(shù)據(jù)量也比較大，我們DBA給的建議是單庫QPS盡量控制在5000左右，實際上有可能到1萬也沒問題，但是此時可能存在潛在風險。
DBA給的這個建議值是比較穩(wěn)健保守的，控制在這個值下基本不會出問題，因此我們盡量按DBA的建議來，畢竟他們在這方面會更專業(yè)一些。
如果按照單庫抗5000來算，即使多加幾個從庫，也就抗個十來萬QPS頂天了，要抗百萬QPS就根本不可能了，流量一進來，DB肯定馬上跪成一片灰燼。
有同學可能會想，能不能無限加從庫硬懟？
這個是不行的，因為從庫是需要占用主庫資源的，看過我之前MySQL面試題的同學應(yīng)該知道，主庫需要不斷和從庫進行通信，傳輸binlog啥的，從庫多了主庫會受影響，無限加從庫最后的結(jié)果肯定是將主庫懟掛了，我們這邊的建議值是從庫數(shù)量盡量不要超過20個，超了就要想其他法子來優(yōu)化。
2、分布式緩存（Tair）硬抗
上分布式緩存硬抗應(yīng)該是大部分老哥會想到的，我們也用數(shù)據(jù)來分析一下可行性。
阿里用的分布式緩存是自研的 Tair，不知道的可以理解為 Redis 吧，對外其實也是說的 Redis 企業(yè)版。
Tair官方自稱性能約為同規(guī)格社區(qū)版實例的3倍。阿里云官網(wǎng)上，Tair企業(yè)版性能增強-集群版當前的實例規(guī)格如下圖所示：
右下角最猛的【4096GB集群性能增強版】的QPS參考值超過6000萬+，沒錯，我數(shù)了好幾遍，就是6000萬，我的龜龜，太變態(tài)了。
直接把【4096GB集群性能增強版】懟上去就解決了，還要啥優(yōu)化。如果一個解決不了，大不了就兩個嘛。
分布式緩存確實是大多數(shù)情況下抗讀流量的主力，所以用Tair硬抗的方案肯定是沒大問題的，但是我們需要思考下是否存在以一些細節(jié)問題，例如：
分布式緩存通常放在服務(wù)端，上游通過RPC來調(diào)用獲取商品信息，百萬級的流量瞬間打進來，是否會直接將RPC的線程池打掛？
緩存里的信息通常是先查詢DB再寫到緩存里，百萬級的流量瞬間打進來，是否會直接將DB打掛？
是否存在熱點商品，導致Tair單節(jié)點扛不住？
...
這些問題我們接下來一一討論。
3、客戶端分布式緩存
分布式緩存放在服務(wù)端，我們稱之為服務(wù)端分布式緩存，但是要使用服務(wù)端分布式緩存需要上游進行RPC調(diào)用，請求量太大會帶來隱患，同時帶來了額外的網(wǎng)絡(luò)請求耗時。
為了解決這個問題，我們引入客戶端分布式緩存，所謂客戶端分布式緩存就是將請求Tair的流程集成在SDK里，如果Tair存在數(shù)據(jù)，則直接返回結(jié)果，無需再請求到服務(wù)端。
這樣一來，商品信息只要在Tair緩存里，請求到客戶端就會結(jié)束流程，服務(wù)端的壓力會大大降低，同時實現(xiàn)也比較簡單，只是將服務(wù)端的Tair請求流程在SDK里實現(xiàn)一遍。
4、緩存預熱
為了解決緩存為空穿透到DB將DB打掛的風險，可以對商品進行預熱，提前將商品數(shù)據(jù)加載到Tair緩存中，將請求直接攔截在Tair，避免大量商品數(shù)據(jù)同時穿透DB，打掛DB。
具體預熱哪些商品了？
這個其實不難選擇，將熱點商品統(tǒng)計出來即可，例如以下幾類：
1）在雙11零點付款前，大部分用戶都會將要買的商品放到購物車，因此可以對購物車的數(shù)據(jù)進行一個統(tǒng)計，將其中的熱點數(shù)據(jù)計算出來即可。
2）對一些有參與優(yōu)惠或秒殺活動的商品進行統(tǒng)計，參與活動的商品一般也會被搶購的比較厲害。
3）最近一段時間銷量比較大的商品，或者瀏覽量比較大的商品。
4）有參與到首頁活動的商品，最近一段時間收藏夾的商品等等...
淘寶背后有各種各樣的數(shù)據(jù)，統(tǒng)計出需要預熱的商品并不難。
通過預熱，可以大大降低DB被穿透的風險。
5、本地緩存
阿里云官網(wǎng)的數(shù)據(jù)【4096GB集群性能增強版】的QPS參考值超過6000萬+，但是這個值是在請求分布比較均勻的情況下的參考值，256個分片上每個分片二三十萬這樣。
通常個別分片高一點也沒事，五六十萬估計也ok，但是一般不能高太多，否則可能出現(xiàn)帶寬被打滿、節(jié)點處理不過來等情況，導致整個集群被打垮。
這個時候就需要祭出我們的最終神器了，也就是本地緩存。本地緩存的性能有多牛逼了，我們看下這張圖。
這張圖是caffeine（一個高性能Java緩存框架）官方提供的本地測試結(jié)果，并不是服務(wù)器上的測試結(jié)果。
測試運行在 MacBook Pro i7-4870HQ CPU @ 2.50GHz (4 core) 16 GB Yosemite系統(tǒng)，簡單來說，比較一般的配置，大部分服務(wù)器配置應(yīng)該都會比這個高。
在這個基準測試中， 8 線程對一個配置了最大容量的緩存進行并發(fā)讀。
可以看到，caffeine支持每秒操作數(shù)差不多是1.5億，而另一個常見的緩存框架Guava差不多也有2000多萬的樣子。
而在服務(wù)器上測試結(jié)果如下：
服務(wù)器配置是單插槽 Xeon E5-2698B v3 @ 2.00GHz (16 核， 禁用超線程)，224 GB，Ubuntu 15.04。
可以看到caffeine在使用16線程時支持每秒操作數(shù)已經(jīng)達到3.8億次，其他的框架也基本都是千萬級以上。
通過上面的數(shù)據(jù)，大家應(yīng)該都明白了，本地緩存在抗讀流量上理論上是無敵的。當然本地緩存有一些缺點，例如需要占用服務(wù)器的本地內(nèi)存，因此通常我們只會存儲少量的熱點數(shù)據(jù)，嚴格配置好參數(shù)，控制好本地緩存的占用內(nèi)存上限，避免影響服務(wù)器本身的使用。
因此，我們會對之前的熱點數(shù)據(jù)，再進行一次篩選，選出“熱點中的熱點”，將這些數(shù)據(jù)提前預熱到本地緩存中。
可能有同學會問，如果本地緩存里的商品數(shù)據(jù)發(fā)生了變更，怎么辦？
一個辦法是使用類似ZK的監(jiān)聽方式，當本地緩存的商品發(fā)生變更時，觸發(fā)更新操作，本地緩存去拉取最新數(shù)據(jù)，因為本地緩存的商品數(shù)較少，所以ZK整體壓力不會太大。
另一個辦法是本地緩存定期拉取最新數(shù)據(jù)，例如每隔N秒后，就主動查詢一次DB，將數(shù)據(jù)更新為最新數(shù)據(jù)，具體延遲幾秒，根據(jù)業(yè)務(wù)上能接受的來控制。
具體選哪種看業(yè)務(wù)的選擇吧，這些被篩選進入本地緩存的數(shù)據(jù)基本都是最熱的那些商品，無論是商家還是運營都心里有數(shù)，肯定在活動前會再三確認，所以出現(xiàn)變更的幾率其實不大。
6、訪問DB加鎖
盡管我們對熱點數(shù)據(jù)進行了預熱，但是我們必須考慮到可能會有這么一些緩存擊穿的場景：
1）某個熱點數(shù)據(jù)在緩存里失效了，大量流量瞬間打到DB，導致DB被打垮。
2）某個商品并不屬于熱點商品，所以并沒有預熱，但是在活動開始后成為熱點商品，導致流量大量打到DB，DB被瞬間打垮。
等等，這些場景都可能會導致DB瞬間被打垮，DB是生命線，DB一掛就涼了，因此我們必須要有相應(yīng)的措施來應(yīng)對。
解決方案在之前講緩存擊穿的文章里其實提過了，就是在訪問DB時加鎖，保證單臺服務(wù)器上對于同一個商品在同一時刻，只會有一個線程去請求DB，其他的全部原地阻塞等待該線程返回結(jié)果。
注意，這邊我們是不會加分布式鎖的，只會加JVM鎖，因為JVM鎖保證了在單臺服務(wù)器上只有一個請求走到數(shù)據(jù)庫，通常來說已經(jīng)足夠保證數(shù)據(jù)庫的壓力大大降低，同時在性能上比分布式鎖更好。這個在Guava中就有現(xiàn)成的實現(xiàn)，有興趣的可以看看。
7、熱點探測
我們上述所說的熱點商品都是基于已有數(shù)據(jù)的分析，屬于靜態(tài)數(shù)據(jù)，難免會有漏掉的，因此也需要有辦法能實時的探測出熱點數(shù)據(jù)，從而進行緩存，保護系統(tǒng)穩(wěn)定。
8、限流
無論你想的多么齊全，真正面臨線上考驗的時候，經(jīng)常會出現(xiàn)一些你沒考慮到的情況，因此，我們必須要有最終的保護措施。
限流降級作為最后一道防御墻，不到萬不得已我們不希望使用到他，但是我們必須做好準備，萬一發(fā)生沒預料到的情況，可以保證大部分用戶不會受到影響。
9、全鏈路壓測
模擬雙11當天的流量進行測試，系統(tǒng)到底能抗多少，只有壓測一下才知道，同時壓測出來的指標，也會作為我們設(shè)置限流值很重要的參考依據(jù)。
10、預案
預案是指根據(jù)評估分析或經(jīng)驗，對潛在的或可能發(fā)生的突發(fā)事件的類別和影響程度而事先制定的應(yīng)急處置方案。
簡單來說就是關(guān)鍵時刻一鍵拉閘，直接切換某些功能或者關(guān)閉降級某些功能，以保障核心功能不會受到影響。
11、降級部分非核心功能
在雙11高峰期將一些非核心功能進行降級，避免影響核心流程，例如我記得訂單是超過幾個月就不讓查。
12、監(jiān)控大盤
各項核心指標都需要有監(jiān)控和告警，例如：緩存命中率、服務(wù)端請求QPS、DB讀寫QPS等等。
同時要設(shè)置合理的告警值，萬一出現(xiàn)異常可以及時感知及時解決。
同時要有一個核心業(yè)務(wù)監(jiān)控大盤，放置最核心的業(yè)務(wù)指標監(jiān)控，方便大家及時了解業(yè)務(wù)核心指標情況。
13、加機器
雖然很多人會看不起加機器解決，但是實際上加機器是必不可少的，簡單粗暴，花錢就能解決。
14、其他
以上列的只是我當前能想到的，實際上肯定比這要多的多。
最后
我是囧輝，一個堅持分享原創(chuàng)技術(shù)干貨的程序員。
由于本人實力有限難免會有錯誤，歡迎大家指教，如果有疑問，也歡迎留言探討。
推薦閱讀
最近我將面試：阿里、字節(jié)、美團、快手、拼多多等大廠的高頻面試整理出來，并按大廠的標準給出自己的解析。
群里有不少同學看完拿下了阿里、美團等大廠 Offer，希望能助你一臂之力，早日拿下大廠 Offer。
獲取方式：點擊【在看】，關(guān)注公眾號回復【面試】即可領(lǐng)取，更多大廠面試真題解析 PDF 整理中。
