整體分成三部分緩存：應用Nginx本地緩存、分布式緩存、Tomcat堆緩存。
每層都用來解決相關問題，第一層解決熱點緩存的問題，第二層減少訪問回源率，第三層防止相關緩存失效/崩潰之后的沖擊
11.2 如何緩存數據
11.2.1 過期與不過期
過不過期應該根據業務和數據量等因素決定
不過期緩存的場景
對於訪問頻率很高的場景，或者緩存空間足夠，都可以考慮不過期緩存，比如用戶、分類、商品、價格、訂單等。當緩存滿了，考慮使用LRU機制驅逐老緩存數據。
不過期緩存的更新設計
注意不要把寫緩存放到事務中，特別是分布式緩存，因為網絡抖動可能導致寫緩存響應時間很慢，引起數據庫事務阻塞。如果數據量不大且實時性要求不高，可以考慮全量同步緩存。
過期緩存的場景
一般用於緩存其他系統的數據（無法訂閱變更消息或者成本很高）、緩存空間有限、低頻熱點緩存等場景。熱點數據因為頻繁更新，經常使用過期緩存。
11.2.2 維度化緩存與增量緩存
當全部更新成本很高時，只更新變化的部分
11.2.3 大Value緩存
使用Redis避免設置大Value，因為Redis是單線程操作，更新大Value將會占用很長時間造成其他請求等待超時。此時可以考慮使用多線程實現的緩存比如Memcached。或者對Value進行壓縮，或者將Value拆分成多個小Value，由客戶端進行查詢和聚合。
11.2.4 熱點緩存
對於訪問非常頻繁的熱點緩存，如果每次都去遠程緩存系統獲取，可能會因為訪問量太大導致遠程緩存系統請求過多，負載過高或者貸款過高等問題。可以對分布式緩存做主從或集群，或者簡單的在本地也做一個短時間的緩存。
11.3 分布式緩存與應用負載均衡
11.3.1 緩存分布式
將緩存分散到多個實例或者多台服務器，使用一致性哈希分片，或者使用Redis集群
11.3.2 應用負載均衡
請求進入接入層Nginx，根據負載均衡算法將請求轉發給應用Nginx，如果應用Nginx本地緩存命中，則直接返回數據，否則讀取分布式緩存或者回源到Tomcat
一般采用輪詢或一致性哈希。
輪詢的優點是請求更加均勻，每個服務器負載基本一致，不會因為熱點問題導致其中一台服務器負載過重，缺點是當Nginx服務器增加，緩存的命中率降低。
一致性哈希的優點是命中率高，且不會應為服務器的增加或減少而降低。缺點是如果熱點數據在一台服務器上，會被打崩。解決方案：
(1)負載較低時，使用一致性哈希
(2)熱點請求降級一致性哈希為輪詢
(3)將熱點數據推送到接入層Nginx，直接響應給用戶
11.4 熱點數據與更新緩存
熱點數據緩存方案
11.4.1 單機全量緩存+主從
11.4.2 分布式緩存+應用本地熱點
在應用層Nginx和分布式集群中都設置緩存，若不存在則回源Tomcat。
11.5 更新緩存與原子性
針對同時更新一份數據沖突的解決策略
1. 更新數據時使用更新時間戳或者版本對比，如果使用Redis，則可以利用單線程機制進行原子化更新
2. 使用canal訂閱數據庫binlog
3. 更新請求按照相應規則分散到多個隊列，每個隊列進行單線程更新，更新時拉取最新的數據保存
4. 使用分布式鎖，在更新之前獲取相關鎖
11.6 緩存崩潰與快速修復
11.6.1 取模
使用取模來實現負載均衡時，當集群中節點下線或者新增，都會導致大量緩存不命中。對於節點下線，可以使用主從解決。對於新增節點，一般是另起一個集群，將數據遷移到新集群，或者停機更新。
11.6.2 一致性哈希
采用一致性哈希實現負載均衡，新增或者節點下線，影響的只有一個節點的緩存。
11.6.3 快速恢復
1. 主從機制，做好冗余備份，主節點壞了從節點頂上
2. 如果已經出現緩存失效，為了避免造成雪崩，需要將部分用戶降級或者限流，然后慢慢還原，在這段時間內，后台通過Worker預熱緩存數據