不少人看到 J2Cache 第一眼時，會認為這就是一個普普通通的快取框架，和例如 Ehcache、Caffeine 、Spring Cache 之類的專案沒什麼區別，無非是造了一個新的輪子而已。事實上完全不是一回事！

目前快取的解決方案一般有兩種：

記憶體快取（如 Ehcache） —— 速度快，程序內可用 集中式快取（如 Redis）—— 可同時為多節點提供服務 現有的快取框架已經非常成熟而且優秀，J2Cache 無心造一個新的輪子，它要解決的幾個問題如下：

使用記憶體快取時，一旦應用重啟後，由於快取資料丟失，快取雪崩，給資料庫造成巨大壓力，導致應用堵塞 使用記憶體快取時，多個應用節點無法共享快取資料 使用集中式快取，由於大量的資料通過快取獲取，導致快取服務的資料吞吐量太大，頻寬跑滿。現象就是 Redis 服務負載不高，但是由於機器網絡卡頻寬跑滿，導致資料讀取非常慢 在遭遇問題1、2 時，很多人自然而然會想到使用 Redis 來快取資料，因此就難以避免的導致了問題3的發生。

當發生問題 3 時，又有很多人想到 Redis 的叢集，通過叢集來降低快取服務的壓力，特別是頻寬壓力。

但其實，這個時候的 Redis 上的資料量並不一定大，僅僅是資料的吞吐量大而已。

咱們假設這樣一個場景：

有這麼一個網站，某個頁面每天的訪問量是 1000萬，每個頁面從快取讀取的資料是 50K。快取資料存放在一個 Redis 服務，機器使用千兆網絡卡。那麼這個 Redis 一天要承受 500G 的資料流，相當於平均每秒鐘是 5.78M 的資料。而網站一般都會有高峰期和低峰期，兩個時間流量的差異可能是百倍以上。我們假設高峰期每秒要承受的流量比平均值高 50 倍，也就是說高峰期 Redis 服務每秒要傳輸超過 250 兆的資料。請注意這個 250 兆的單位是 byte，而千兆網絡卡的單位是“bit” ，你懂了嗎？ 這已經遠遠超過 Redis 服務的網絡卡頻寬。

所以如果你能發現這樣的問題，一般你會這麼做：

升級到萬兆網絡卡 —— 這個有多麻煩，相信很多人知道，特別是一些雲主機根本沒有萬兆網絡卡給你使用（運維工程師一般會給這樣的建議） 多個 Redis 搭建叢集，將流量分攤多多臺機器上 如果你採用第2種方法來解決上述的場景中碰到的問題，那麼你最好準備 5 個 Redis 服務來支撐。在快取服務這塊成本直接攀升了 5 倍。你有錢當然沒任何問題，但是結構就變得非常複雜了，而且可能你快取的資料量其實不大，1000 萬高頻次的快取讀寫 Redis 也能輕鬆應付，可是因為頻寬的問題，你不得不付出 5 倍的成本。

那麼 J2Cache 的用武之處就在這裡。

如果我們不用每次頁面訪問的時候都去 Redis 讀取資料，那麼 Redis 上的資料流量至少降低 1000 倍甚至更多，以至於一臺 Redis 可以輕鬆應付。

J2Cache 其實不是一個快取框架，它是一個快取框架的橋樑。它利用現有優秀的記憶體快取框架作為一級快取，而把 Redis 作為二級快取。所有資料的讀取先從一級快取中讀取，不存在時再從二級快取讀取，這樣來確保對二級快取 Redis 的訪問次數降到最低。

有人會質疑說，那豈不是應用節點的記憶體佔用要飆升？我的答案是 —— 現在伺服器的記憶體都是幾十 G 打底，多則百 G 數百 G，這點點的記憶體消耗完全不在話下。其次一級快取框架可以通過配置來控制在記憶體中儲存的資料量，所以不用擔心記憶體溢位的問題。

剩下的另外一個問題就是，當快取資料更新的時候，怎麼確保每個節點記憶體中的資料是一致的。而這一點算你問到點子上了，這恰恰是 J2Cache 的核心所在。

J2Cache 目前提供兩種節點間資料同步的方案 —— Redis Pub/Sub 和 JGroups 。當某個節點的快取資料需要更新時，J2Cache 會通過 Redis 的訊息訂閱機制或者是 JGroups 的組播來通知叢集內其他節點。當其他節點收到快取資料更新的通知時，它會清掉自己記憶體裡的資料，然後重新從 Redis 中讀取最新資料。

這就完成了 J2Cache 快取資料讀寫的閉環。

為什麼不用 Ehcache 的叢集方案？

對 Ehcache 比較熟悉的人還會問的就是這個問題，Ehcache 本身是提供叢集模式的，可以在多個節點同步快取資料。但是 Ehcache 的做法是將整個快取資料在節點間進行傳輸。如咱們前面的說的，一個頁面需要讀取 50K 的快取資料，當這 50K 的快取資料有更新時，那麼需要在幾個節點間傳遞整個 50K 的資料。這也會造成應用節點間大量的資料傳輸，這個情況完全不可控。

補充：當然這個單個數據傳輸量本身並不比使用 J2Cache 多，但是 ehcache 利用 jgroups 來同步資料的做法，在實際測試過程中發現可靠性還是略低，而且 jgroups 的同步資料在雲主機上無法使用。

而 J2Cache 傳輸的僅僅是快取的 key 而已，因此相比 Ehcache 的叢集模式，J2Cache 要傳輸的資料極其小，對節點間的資料通訊完全不會產生大的影響。

那如何學習才能快速入門並精通呢？

當真正開始學習的時候難免不知道從哪入手，導致效率低下影響繼續學習的信心。

但最重要的是不知道哪些技術需要重點掌握，學習時頻繁踩坑，最終浪費大量時間，所以有一套實用的視訊課程用來跟著學習是非常有必要的。

為了讓學習變得輕鬆、高效，今天給大家免費分享一套阿里架構師傳授的一套教學資源。加群：874811168免費獲取以下資料 幫助大家在成為架構師的道路上披荊斬棘。

這套視訊課程詳細講解了（Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構）等成為架構師必備的內容！