摘要：在技術領域中，沒有銀彈，我們需要不斷探索和研究新的技術，結合具體問題和需求，選擇最適合的解決方案，

本文分享自華為云社區《知乎問題：如何說服技術老大用 Redis ？》，作者：勇哥java實戰分享，

最近在某問答平臺看到一個技術討論：如何說服技術老大用Redis?

“他總覺得用Redis每次都要去請求，肯定是沒有加載記憶體里快，專案一直是搞個map裝下要快取的資料，一個定時任務去重繪這個map……”

這個問題很微妙，可能這位同學內心深處，覺得 Redis 是所有應用快取的標配，

快取的世界很廣闊，對于應用系統來講，我們經常將快取劃分為本地快取和分布式快取，

本地快取 ：應用中的快取組件，快取組件和應用在同一行程中，快取的讀寫非常快，沒有網路開銷，但各應用或集群的各節點都需要維護自己的單獨快取，無法共享快取，

分布式快取：和應用分離的快取組件或服務，與本地應用隔離，多個應用可直接共享快取，

1 快取的本質

我們常常會講：“加了快取，我們的系統就會更快” ，

所謂的“更快”，本質上做到了如下兩點：

減小 CPU 消耗

將原來需要實時計算的內容提前算好、把一些公用的資料進行復用，這可以減少 CPU 消耗，從而提升回應性能，
減小 I/O 消耗

將原來對網路、磁盤等較慢介質的讀寫訪問變為對記憶體等較快介質的訪問，從而提升回應性能，

假如可以通過增強 CPU、I/O 本身的性能來滿足需求的話，升級硬體往往是更好的解決方案，即使需要一些額外的投入成本，也通常要優于引入快取后可能帶來的風險，

從開發角度來說，引入快取會提高系統復雜度，因為你要考慮快取的失效、更新、一致性等問題，

從運維角度來說，快取會掩蓋掉一些缺陷，讓問題在更久的時間以后，出現在距離發生現場更遠的位置上，

從安全角度來說，快取可能泄漏某些保密資料，也是容易受到攻擊的薄弱點，

因此，快取是把雙刃劍，

2 本地快取 JDK Map

JDK Map 經常用于快取實作：

HashMap

HashMap 是一種基于哈希表的集合類，它提供了快速的插入、查找和洗掉操作，可以將鍵值對作為快取項的存盤方式，將鍵作為快取項的唯一識別符號，值作為快取項的內容，
ConcurrentHashMap

ConcurrentHashMap 是執行緒安全的 HashMap，它在多執行緒環境下可以保證高效的并發讀寫操作，
LinkedHashMap

LinkedHashMap 是一種有序的 HashMap ，它保留了元素插入的順序，可以按照插入順序或者訪問順序進行遍歷，
TreeMap

TreeMap 是一種基于紅黑樹的有序 Map，它可以按照鍵的順序進行遍歷，

筆者曾經負責藝龍紅包系統，紅包活動就是存盤在 ConcurrentHashMap 中，通過定時任務重繪快取 ，

核心流程：

1、紅包系統啟動后，初始化一個 ConcurrentHashMap 作為紅包活動快取；

2、資料庫查詢所有的紅包活動 , 并將活動資訊存盤在 Map 中 ;

3、定時任務每隔 30 秒，執行快取加載方法，重繪快取，

為什么紅包系統會將紅包活動資訊存盤在本地記憶體 ConcurrentHashMap 呢？

紅包系統是高并發應用，快速將請求結果回應給前端，大大提升用戶體驗；
紅包活動數量并不多，就算全部放入到 Map 里也不會產生記憶體溢位的問題；
定時任務重繪快取并不會影響紅包系統的業務，

筆者見過很多單體應用都使用這種方案，該方案的特點是簡潔易用，工程實作也容易，

3 本地快取框架

雖然使用 JDK Map 能快捷構建快取，但快取的功能還是比較孱弱的，

因為現實場景里，我們可能需要給快取添加快取統計、過期失效、淘汰策略等功能，

于是，本地快取框架應運而生，

流行的 Java 快取框架包括： Ehcache , Google Guava , Caffine Cache ，

下圖展示了 Caffine 框架的使用示例，

雖然本地快取框架的功能很強大，但是本地快取的缺陷依然明顯，

1、高并發的場景，應用重啟之后，本地快取就失效了，系統的負載就比較大，需要花較長的時間才能恢復；

2、每個應用節點都會維護自己的單獨快取，快取同步比較頭疼，

4 分布式快取

分布式快取是指將快取資料分布在多臺機器上，以提高快取容量和并發讀寫能力的快取系統，分布式快取通常由多臺機器組成一個集群，每臺機器上都運行著相同的快取服務行程，快取資料被均勻地分布在集群中的各個節點上，

Redis 是分布式快取的首選，甚至我們一提到快取，很多后端工程師首先想到的就它，

下圖是神州專車訂單的 Redis 集群架構，將 Redis 集群拆分成四個分片，每個分片包含一主一從，主從可以切換，應用 A 根據不同的快取 key 訪問不同的分片，

與本地快取相比，分布式快取具有以下優點：

1、容量和性能可擴展

通過增加集群中的機器數量，可以擴展快取的容量和并發讀寫能力，同時，快取資料對于應用來講都是共享的，

2、高可用性

由于資料被分布在多臺機器上，即使其中一臺機器故障，快取服務也能繼續提供服務，

但是分布式快取的缺點同樣不容忽視，

1、網路延遲

分布式快取通常需要通過網路通信來進行資料讀寫，可能會出現網路延遲等問題，相對于本地快取而言，回應時間更長，

2、復雜性

分布式快取需要考慮序列化、資料分片、快取大小等問題，相對于本地快取而言更加復雜，

筆者曾經也認為無腦上快取，系統就一定更快，但直到一次事故，對于分布式快取的觀念才徹底改變，

2014年，同事開發了比分直播的系統，所有的請求都是從分布式快取 Memcached 中獲取后直接回應，常規情況下，從快取中查詢資料非常快，但在線用戶稍微多一點，整個系統就會特別卡，

通過 jstat 命令發現 GC 頻率極高，幾次請求就將新生代占滿了，而且 CPU 的消耗都在 GC 執行緒上，初步判斷是快取值過大導致的，果不其然，快取大小在 300k 到 500k 左右，

解決程序還比較波折，分為兩個步驟：

修改新生代大小，從原來的 2G 修改成 4G，并精簡快取資料大小 (從平均 300k 左右降為 80k 左右)；
把快取拆成兩個部分，第一部分是全量資料，第二部分是增量資料（資料量很小），頁面第一次請求拉取全量資料，當比分有變化的時候，通過 websocket 推送增量資料，

經過這次優化，筆者理解到：快取雖然可以提升整體速度，但是在高并發場景下，快取物件大小依然是需要關注的點，稍不留神就會產生事故，另外我們也需要合理地控制讀取策略，最大程度減少 GC 的頻率 , 從而提升整體性能，

5 多級快取

開源中國網站最開始完全是用本地快取框架 Ehcache ，

后來隨著訪問量的激增，出現了一個可怕的問題：“因為 Java 程式更新很頻繁，每次更新的時候都要重啟，一旦重啟后，整個 Ehcache 快取里的資料都被清掉，重啟后若大量訪問進來的話，開源中國的資料庫基本上很快就會崩掉”，

于是，開源中國開發了多級快取框架 J2Cache，使用了多級快取 Ehcache + Redis ，

多級快取有如下優勢：

離用戶越近，速度越快；
減少分布式快取查詢頻率，降低序列化和反序列化的 CPU 消耗；
大幅度減少網路 IO 以及帶寬消耗，

本地快取做為一級快取，分布式快取做為二級快取，首先從一級快取中查詢，若能查詢到資料則直接回傳，否則從二級快取中查詢，若二級快取中可以查詢到資料，則回填到一級快取中，并回傳資料，若二級快取也查詢不到，則從資料源中查詢，將結果分別回填到一級快取，二級快取中，

2018年，筆者服務的一家電商公司需要進行 app 首頁介面的性能優化，筆者花了大概兩天的時間完成了整個方案，采取的是兩級快取模式，同時利用了 Guava 的惰性加載機制，整體架構如下圖所示：

快取讀取流程如下：

1、業務網關剛啟動時，本地快取沒有資料，讀取 Redis 快取，如果 Redis 快取也沒資料，則通過 RPC 呼叫導購服務讀取資料，然后再將資料寫入本地快取和 Redis 中；若 Redis 快取不為空，則將快取資料寫入本地快取中，

2、由于步驟1已經對本地快取預熱，后續請求直接讀取本地快取，回傳給用戶端，

3、Guava 配置了 refresh 機制，每隔一段時間會呼叫自定義 LoadingCache 執行緒池（5個最大執行緒，5個核心執行緒）去導購服務同步資料到本地快取和 Redis 中，

優化后，性能表現很好，平均耗時在 5ms 左右，最開始我以為出現問題的幾率很小，可是有一天晚上，突然發現 app 端首頁顯示的資料時而相同，時而不同，

也就是說：雖然 LoadingCache 執行緒一直在呼叫介面更新快取資訊，但是各個服務器本地快取中的資料并非完成一致，說明了兩個很重要的點：

1、惰性加載仍然可能造成多臺機器的資料不一致

2、LoadingCache 執行緒池數量配置的不太合理, 導致了執行緒堆積

最終，我們的解決方案是：

1、惰性加載結合訊息機制來更新快取資料，也就是：當導購服務的配置發生變化時，通知業務網關重新拉取資料，更新快取，

2、適當調大 LoadigCache 的執行緒池引數，并在執行緒池埋點，監控執行緒池的使用情況，當執行緒繁忙時能發出告警，然后動態修改執行緒池引數，

6 沒有銀彈

沒有銀彈是 Fred Brooks 在 1987 年所發表的一篇關于軟體工程的經典論文，

論文強調真正的銀彈并不存在，而所謂的銀彈則是指沒有任何一項技識訓方法可以能讓軟體工程的生產力在十年內提高十倍，

通俗來講：在技術領域中沒有一種通用的解決方案可以解決所有問題，

技術本質上是為了解決問題而存在的，每個問題都有其獨特的環境和限制條件，沒有一種通用的技識訓工具可以完美地解決所有問題，

雖然技術不斷發展和進步，但是對于復雜的問題，仍需要結合多種技術和方法，進行系統性的思考和綜合性的解決方案設計，才能得到最優解決方案，

回到文章開頭的問題，如何說服技術老大用 Redis ？

假如應用就是一個單體應用，快取可以不共享，通過定時任務重繪快取對業務沒有影響，而且本地記憶體可以 Hold 住快取的物件大小，那么你的技術老大的方案沒有問題，

假如應用業務比較復雜，需要使用快取提升系統的性能，同時分布式快取共享的特性對于研發來講開發更加快捷，Redis 確實是個不錯的選擇，可以從研發成本、代碼維護、人力模型等多個角度和技術老大提出自己的觀點，

總而言之，在技術領域中，沒有銀彈，我們需要不斷探索和研究新的技術，但同時也需要認識到技術的局限性，不盲目追求所謂的“銀彈”，而是結合具體問題和需求，選擇最適合的解決方案，

點擊關注，第一時間了解華為云新鮮技術~

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/552171.html

標籤：其他

上一篇：基于華為云圖引擎GES，使用Cypher子查詢進行圖探索