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