物流合約中心是京東物流合同管理的唯一入口。為商家提供合同的創建，蓋章等能力，為不同業務條線提供合同的定製，歸檔，查詢等功能。由於各個業務條線眾多，為各個業務條線提供高可用查詢能力是物流合約中心重中之重。同時計費系統在每個物流單結算時，都需要查詢合約中心，確保商家簽署的合同內容來保證計費的準確性。 ...
作者：京東物流 趙帥 姚再毅 王旭東 孟偉傑 孔祥東
1 前言
物流合約中心是京東物流合同管理的唯一入口。為商家提供合同的創建，蓋章等能力，為不同業務條線提供合同的定製，歸檔，查詢等功能。由於各個業務條線眾多，為各個業務條線提供高可用查詢能力是物流合約中心重中之重。同時計費系統在每個物流單結算時，都需要查詢合約中心，確保商家簽署的合同內容來保證計費的準確性。
2 業務場景
1.查詢維度分析
從業務調用的來源來看，合同的大部分是計費系統在每個物流單計費的時候，需要調用合約中心來判斷，該商家是否簽署合同。
從業務調用的入參來看，絕大部分是多個條件來查詢合同，但基本都是查詢某個商家，或通過商家的某個屬性（例如業務賬號）來查詢合同。
從調用的結果來看，40%的查詢是沒有結果的，其中絕大部分是因為商家沒有簽署過合同，導致查詢為空。其餘的查詢結果，每次返回的數量較少，一般一個商家只有3到5個合同。
2.調用量分析
調用量
目前合同的調用量，大概是在每天2000W次。
一天的調用量統計：
調用時間
每天高峰期為上班時間，最高峰為4W/min。
一個月的調用量統計：
由上可以看出，合同每日的調用量比較平均，主要集中在9點到12點和13點到18點，也就是上班時間，整體調用量較高，基本不存在調用暴增的情況。
總體分析來看，合約中心的查詢，調用量較高，且較平均，基本都是隨機查詢，也並不存在熱點數據，其中無效查詢占比較多，每次查詢條件較多，返回數據量比不大。
3 方案設計
從整體業務場景分析來看，我們決定做三層防護來保證調用量的支撐，同時需要對數據一致性做好處理。第一層是布隆過濾器，來攔截絕大部分無效的請求。第二層是redis緩存數據，來保證各種查詢條件的查詢儘量命中redis。第三層是直接查詢資料庫的兜底方案。同時再保證數據一致性的問題，我們藉助於廣播mq來實現。
1.第一層防護
由於近一半的查詢都是空，我們首先這是緩存穿透的現象。
緩存穿透問題
緩存穿透（cache penetration）是用戶訪問的數據既不在緩存當中，也不在資料庫中。出於容錯的考慮，如果從底層資料庫查詢不到數據，則不寫入緩存。這就導致每次請求都會到底層資料庫進行查詢，緩存也失去了意義。當高併發或有人利用不存在的Key頻繁攻擊時，資料庫的壓力驟增，甚至崩潰，這就是緩存穿透問題。
常規解決方案
緩存特定值
一般對於緩存穿透我們比較常規的做法就是，將不存在的key 設置一個固定值，比如說NULL,&&等等，在查詢返回這個值的時候，我們應用就可以認為這是一個不存在的key,那我們應用就可以決定是否繼續等待，還是繼續訪問，還是直接放棄，如果繼續等待訪問的話，設置一個輪詢時間，再次請求，如果取到的值不再是我們預設的，那就代表已經有值了，從而避免了透傳到資料庫，從而把大量的類似請求擋在了緩存之中。
緩存特定值並同步更新
特定值做了緩存，那就意味著需要更多的記憶體存儲空間。當存儲層數據變化了，緩存層與存儲層的數據會不一致。有人會說，這個問題，給key 加上一個過期時間不就可以了，確實，這樣是最簡單的，也能在一定程度上解決這兩個問題，但是當併發比較高的時候（緩存併發），其實我是不建議使用緩存過期這個策略的，我更希望緩存一直存在；通過後臺系統來更新緩存中的數據一致性的目的。
布隆過濾器
布隆過濾器的核心思想是這樣的，它不保存實際的數據，而是在記憶體中建立一個定長的點陣圖用0,1來標記對應數據是否存在系統；過程是將數據經過多個哈希函數計算出不同的哈希值，然後用哈希值對點陣圖的長度進行取模，最後得到點陣圖的下標位，然後在對應的下標位上進行標記；找數的時候也是一樣，先通過多個哈希函數得到哈希值，然後哈希值與點陣圖的長度進行取模得到多個下標。如果多個下標都被標記成1了，那麼說明數據存在於系統，不過只要有一個下標為0那麼就說明該數據肯定不存在於系統中。
在這裡先通過一個示例介紹一下布隆過濾器的場景：
以ID查詢文章為例，如果我們要知道資料庫是否存在對應的文章，那麼最簡單的方式就是我們把所有資料庫存在的ID都保存到緩存去，這個時候當請求過進入系統，先從這個緩存數據里判斷系統是否存在對應的數據ID，如果不存在的話直接返回出去，避免請求進入到資料庫層，存在的話再從獲取文章的信息。但是這個不是最好的方式，因為當文章的數量很多很多的時候，那緩存中就需要存大量的文檔id而且只能持續增長，所以我們得想一種方式來節省記憶體資源當又能是請求都能命中緩存，這個就是布隆過濾器要做的。
我們分析布隆過濾器的優缺點
優點
1.不需要存儲數據，只用比特表示，因此在空間占用率上有巨大的優勢
2.檢索效率高，插入和查詢的時間複雜度都為 O(K)（K 表示哈希函數的個數）
3.哈希函數之間相互獨立，可以在硬體指令層次並行計算，因此效率較高。
缺點
1.存在不確定的因素，無法判斷一個元素是否一定存在，所以不適合要求 100% 準確率的場景
2.只能插入和查詢元素，不能刪除元素。
布隆過濾器分析：面對優點，完全符合我們的訴求，針對缺點1，會有極少的數據穿透對系統來說並無壓力。針對缺點2，合同的數據，本來就是不可刪除的。如果合同過期，我們可以查出單個商家的所有合同，從合同的結束時間來判斷合同是否有效，並不需要取刪除布隆過濾器里的元素。
考慮到調用redis布隆過濾器，會走一次網路，而我們的查詢近一半都是無效查詢，我們決定使用本地布隆過濾器，這樣就可以減少一次網路請求。但是如果是本地布隆過濾器，在更新時，就需要對所有機器的本地布隆過濾器更新，我們監聽合同的狀態來更新，通過mq的廣播模式，來對布隆過濾器插入元素，這樣就做到了所有機器上的布隆過濾器統一元素插入。
2.第二層防護
面對高併發，我們首先想到的是緩存。
引入緩存，我們就要考慮緩存穿透，緩存擊穿，緩存雪崩的三大問題。
其中緩存穿透，我們已再第一層防護中處理，這裡只解決緩存擊穿，緩存雪崩的問題。
緩存擊穿（Cache Breakdown）緩存雪崩是指只大量熱點key同時失效的情況，如果是單個熱點key，在不停的扛著大併發，在這個key失效的瞬間，持續的大併發請求就會擊破緩存，直接請求到資料庫，好像蠻力擊穿一樣。這種情況就是緩存擊穿。
常規解決方案
緩存失效分散
這個問題其實比較好解決，就是在設置緩存的時效時間的時候增加一個隨機值，例如增加一個1-3分鐘的隨機，將失效時間分散開，降低集體失效的概率；把過期時間控制在系統低流量的時間段,比如凌晨三四點，避過流量的高峰期。
加鎖
加鎖，就是在查詢請求未命中緩存時，查詢資料庫操作前進行加鎖，加鎖後後面的請求就會阻塞，避免了大量的請求集中進入到資料庫查詢數據了。
永久不失效
我們可以不設置過期時間來保證緩存永遠不會失效，然後通過後臺的線程來定時把最新的數據同步到緩存里去
解決方案：使用分散式鎖，針對同一個商家，只讓一個線程構建緩存，其他線程等待構建緩存執行完畢，重新從緩存中獲取數據。
緩存雪崩（Cache Avalanche）當緩存中大量熱點緩存採用了相同的實效時間，就會導致緩存在某一個時刻同時實效，請求全部轉發到資料庫，從而導致資料庫壓力驟增，甚至宕機。從而形成一系列的連鎖反應，造成系統崩潰等情況，這就是緩存雪崩。
解決方案：緩存雪崩的解決方案是將key的過期設置為固定時間範圍內的一個隨機數，讓key均勻的失效即可。
我們考慮使用redis緩存，因為每次查詢的條件都不一樣，返回的結果數據又比較少，我們考慮限制查詢都必須有一個固定的查詢條件，商家編碼。如果查詢條件中沒有查商家編碼，我們可以通過商家名稱，商家業務賬號這些條件來反查查商家編碼。
這樣我們就可以緩存單個商家編碼的所有合同，然後再通過代碼使用filter對其他查詢條件做支持，避免不同的查詢條件都去緩存數據而引發的緩存數據更新，緩存數據淘汰已經緩存數據一致等問題。
同時只緩存單個商家編碼的所有合同，緩存的數據量也是可控，每個緩存的大小也可控，基本不會出現redis大key的問題。
引入緩存，我們就要考慮緩存數據一致性的問題。
有關緩存一致性問題，可自行百度，這個就不在敘述。
如圖所示 對於商家編碼維度的緩存數據，我們通過監聽合同的狀態，使用mq廣播來刪除對應商家的緩存，從而避免出現緩存和數據一致性的相關問題。
3.第三層防護
第三層防護，自然是資料庫，如果有查詢經過了第一層和第二層，那我們需要直接查詢資料庫來返回結果，同時，我們對直接調用到資料庫的線程進行監控。
為避免一些未知的查詢大量查詢涌入，導致資料庫調用保證的問題，尤其是大促時，我們可以提前對資料庫里的所有商家合同進行提前緩存。在緩存時，為避免緩存雪崩問題，我們對將key的過期設置為固定時間範圍內的一個隨機數，讓key均勻的失效。
同時，為避免依然存在意外的情況，有大量查詢涌入。我們通過ducc開關控制資料庫的查詢，如調用量太高導致無法支撐，則直接關閉資料庫的調用，保證資料庫不會直接宕機導致整個業務不可用。
4 總結
本文主要分析了面對高併發調用的調用場景設計及的技術方案，在引入緩存的同時，也要考慮實際的調用入參及結果，面對增加的網路請求，是否可以進一步減少。面對redis緩存，是否可以通過一些手段避免所有查詢條件都需要緩存，帶來的緩存爆炸，緩存淘汰策略等問題，以及解決緩存與數據一致等一系列問題。
本方案是根據具體的查詢業務場景設計具體的技術方案，針對不同的業務場景，對應的技術方案也是不一樣的。
