1、 高并發(fā)網(wǎng)站多級緩存設計什么是多級緩存所謂多級緩存，即在整個系統(tǒng)架構的不同系統(tǒng)層級進行數(shù)據(jù)緩存，以提升訪問效率，這也是應用最廣的方案之一。我們應用的整體架構如圖1所示：圖1 多級緩存方案整體流程如上圖所示：1）首先接入Nginx將請求負載均衡到應用Nginx，此處常用的負載均衡算法是輪詢或者一致性哈希，輪詢可以使服務器的請求更加均衡，而一致性哈?？梢蕴嵘龖肗ginx的緩存命中率，相對于輪詢，一致性哈希會存在單機熱點問題，一種解決辦法是熱點直接推送到接入層Nginx，一種辦法是設置一個閥值，當超過閥值，改為輪詢算法。2）接著應用Nginx讀取本地緩存（本地緩存可以使用Lua Shared Di

2、ct、Nginx Proxy Cache（磁盤/內(nèi)存）、Local Redis實現(xiàn)），如果本地緩存命中則直接返回，使用應用Nginx本地緩存可以提升整體的吞吐量，降低后端的壓力，尤其應對熱點問題非常有效。3）如果Nginx本地緩存沒命中，則會讀取相應的分布式緩存（如Redis緩存，另外可以考慮使用主從架構來提升性能和吞吐量），如果分布式緩存命中則直接返回相應數(shù)據(jù)（并回寫到Nginx本地緩存）。4）如果分布式緩存也沒有命中，則會回源到Tomcat集群，在回源到Tomcat集群時也可以使用輪詢和一致性哈希作為負載均衡算法。5）在Tomcat應用中，首先讀取本地堆緩存，如果有則直接返回（并會寫到主R

3、edis集群），為什么要加一層本地堆緩存將在緩存崩潰與快速修復部分細聊。6）作為可選部分，如果步驟4沒有命中可以再嘗試一次讀主Redis集群操作。目的是防止當從有問題時的流量沖擊。7）如果所有緩存都沒有命中只能查詢DB或相關服務獲取相關數(shù)據(jù)并返回。8）步驟7返回的數(shù)據(jù)異步寫到主Redis集群，此處可能多個Tomcat實例同時寫主Redis集群，可能造成數(shù)據(jù)錯亂，如何解決該問題將在更新緩存與原子性部分細聊。應用整體分了三部分緩存：應用Nginx本地緩存、分布式緩存、Tomcat堆緩存，每一層緩存都用來解決相關的問題，如應用Nginx本地緩存用來解決熱點緩存問題，分布式緩存用來減少訪問回源率、To

4、mcat堆緩存用于防止相關緩存失效/崩潰之后的沖擊。雖然就是加緩存，但是怎么加，怎么用細想下來還是有很多問題需要權衡和考量的，接下來部分我們就詳細來討論一些緩存相關的問題。如何緩存數(shù)據(jù)接下來部將從緩存過期、維度化緩存、增量緩存、大Value緩存、熱點緩存幾個方面來詳細介紹如何緩存數(shù)據(jù)。1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 16.1. 16.2. 16.3. 16.4. 16.5. 過期與不過期對于緩存的數(shù)據(jù)我們可以考慮不過期緩存和帶過期時間緩存，什么場景應該選擇哪種模式需要根據(jù)業(yè)務和數(shù)據(jù)量等因素來決定。不過期緩存場景一般思

5、路如圖2所示：圖2不過期緩存方案使用Cache-Aside模式，首先寫數(shù)據(jù)庫，如果成功，則寫緩存。這種場景下存在事務成功、緩存寫失敗但無法回滾事務的情況。另外，不要把寫緩存放在事務中，尤其寫分布式緩存，因為網(wǎng)絡抖動可能導致寫緩存響應時間很慢，引起數(shù)據(jù)庫事務阻塞。如果對緩存數(shù)據(jù)一致性要求不是那么高，數(shù)據(jù)量也不是很大，則可以考慮定期全量同步緩存。也有提到如下思路：先刪緩存，然后執(zhí)行數(shù)據(jù)庫事務；不過這種操作對于如商品這種查詢非常頻繁的業(yè)務不適用，因為在你刪緩存的同時，已經(jīng)有另一個系統(tǒng)來讀緩存了，此時事務還沒有提交。當然對于如用戶維度的業(yè)務是可以考慮的。不過為了更好地解決以上多個事務的問題，可以考慮使

6、用訂閱數(shù)據(jù)庫日志的架構，如使用canal訂閱mysql的binlog實現(xiàn)緩存同步。對于長尾訪問的數(shù)據(jù)、大多數(shù)數(shù)據(jù)訪問頻率都很高的場景、緩存空間足夠都可以考慮不過期緩存，比如用戶、分類、商品、價格、訂單等，當緩存滿了可以考慮LRU機制驅逐老的緩存數(shù)據(jù)。1. 過期緩存機制即采用懶加載，一般用于緩存別的系統(tǒng)的數(shù)據(jù)（無法訂閱變更消息、或者成本很高）、緩存空間有限、低頻熱點緩存等場景；常見步驟是：首先讀取緩存如果不命中則查詢數(shù)據(jù)，然后異步寫入緩存并過期緩存，設置過期時間，下次讀取將命中緩存。熱點數(shù)據(jù)經(jīng)常使用即在應用系統(tǒng)上緩存比較短的時間。這種緩存可能存在一段時間的數(shù)據(jù)不一致情況，需要根據(jù)場景來決定如何設

7、置過期時間。如庫存數(shù)據(jù)可以在前端應用上緩存幾秒鐘，短時間的不一致時可以忍受的。2.維度化緩存與增量緩存對于電商系統(tǒng)，一個商品可能拆成如基礎屬性、圖片列表、上下架、規(guī)格參數(shù)、商品介紹等；如果商品變更了要把這些數(shù)據(jù)都更新一遍那么整個更新成本很高：接口調用量和帶寬；因此最好將數(shù)據(jù)進行維度化并增量更新（只更新變的部分）。尤其如上下架這種只是一個狀態(tài)變更，但是每天頻繁調用的，維度化后能減少服務很大的壓力。圖3 維度化緩存方案按照不同維度接收MQ進行更新。3.大Value 緩存要警惕緩存中的大Value，尤其是使用Redis時。遇到這種情況時可以考慮使用多線程實現(xiàn)的緩存，如Memcached，來緩存大Value；或者對Value進行壓縮；或者將Value拆分為多個小Value，客戶端再進行查詢、聚合。4.熱點緩存對于那些訪問非常頻繁的熱點緩存，如果每次都去遠程緩存系統(tǒng)中獲取，可能會因為訪問量太大導致遠程緩存系統(tǒng)請求過多、負載過高或者帶寬過高等問題，最終可能導致緩存響應慢，使客戶端請求超時。一