作者 | Garnett
頭圖 | CSDN 下載自東方IC
caffeine是什麼，它和redis什麼區別，有哪些作用，那麼讓我們帶著疑問讓Garnett來告訴你這個來自未來的緩存-Caffeine！
Caffeine和Redis的區別是什麼？
1、相同點：
兩個都是緩存的方式
2、不同點：
redis是將數據存儲到內存裡
caffeine是將數據存儲在本地應用裡
caffeine和redis相比，沒有了網絡IO上的消耗
3、聯繫：
一般將兩者結合起來，形成一二級緩存。使用流程大致如下：
去一級緩存中查找數據（caffeine-本地應用內）
如果沒有的話，去二級緩存中查找數據（redis-內存）
再沒有，再去資料庫中查找數據（資料庫-磁碟）
到這裡大家應該清楚了其實redis和caffeine都是緩存，但是他們並不相同，所以別混淆了！
那麼什麼是 Caffeine
1、Caffeine簡介
Caffeine是基於jdk 1.8 Version的高性能緩存庫。Caffeine提供的內存緩存使用參考Google guava的API。Caffeine是基於Google Guava Cache設計經驗上改進的成果。
Caffeine是使用jdk 1.8對Guava cache的重寫版本，基於LRU算法實現，支持多種緩存過期策略。
那麼先來看看Caffeine和其他的進程緩存的區別，為什麼叫它來自未來的緩存呢？
2、其他進程緩存的簡單介紹
Google Guava工具包中的一個非常方便易用的本地化緩存實現，基於LRU算法實現，支持多種緩存過期策略。
EhCache 是一個純Java的進程內緩存框架，具有快速、精幹等特點，是Hibernate中默認的CacheProvider。
3、性能比較
場景1：8個線程讀，100%的讀操作
場景二：6個線程讀，2個線程寫，也就是75%的讀操作，25%的寫操作
場景三：8個線程寫，100%的寫操作
可以清楚的看到Caffeine效率明顯的高於其他緩存。
4、如何使用
5、參數方法
initialCapacity(1) 初始緩存長度為1
maximumSize(100) 最大長度為100
expireAfterWrite(1, TimeUnit.DAYS) 設置緩存策略在1天未寫入過期緩存
Caffeine的原理
1、W-TinyLFU
既然說到了淘汰策略，那麼就簡單說說redis的吧
繼續說Caffeine的淘汰策略
傳統的LFU受時間周期的影響比較大。所以各種LFU的變種出現了，基於時間周期進行衰減，或者在最近某個時間段內的頻率。同樣的LFU也會使用額外空間記錄每一個數據訪問的頻率，即使數據沒有在緩存中也需要記錄，所以需要維護的額外空間很大。
可以試想我們對這個維護空間建立一個hashMap，每個數據項都會存在這個hashMap中，當數據量特別大的時候，這個hashMap也會特別大。
再回到LRU，我們的LRU也不是那麼一無是處，LRU可以很好的應對突發流量的情況，因為他不需要累計數據頻率。
所以W-TinyLFU結合了LRU和LFU，以及其他的算法的一些特點。
為了改進上述 LRU 和 LFU 存在的問題，前Google工程師在 TinyLfu的基礎上發明了 W-TinyLFU 緩存算法。Caffine 就是基於此算法開發的。
Caffeine 因使用 Window TinyLfu 回收策略，提供了一個近乎最佳的命中率。
TinyLFU維護了近期訪問記錄的頻率信息，作為一個過濾器，當新記錄來時，只有滿足TinyLFU要求的記錄才可以被插入緩存。
TinyLFU藉助了數據流Sketching技術，它可以用小得多的空間存放頻次信息。TinyLFU採用了一種基於滑動窗口的時間衰減設計機制，藉助於一種簡易的 reset 操作：每次添加一條記錄到Sketch的時候，都會給一個計數器上加 1，當計數器達到一個尺寸 W 的時候，把所有記錄的 Sketch 數值都除以 2，該 reset 操作可以起到衰減的作用 。
W-TinyLFU主要用來解決一些稀疏的突發訪問元素。在一些數目很少但突發訪問量很大的場景下，TinyLFU將無法保存這類元素，因為它們無法在給定時間內積累到足夠高的頻率。因此 W-TinyLFU 就是結合 LFU 和LRU，前者用來應對大多數場景，而 LRU 用來處理突發流量。
在處理頻次記錄方面，採用 Bloom Filter，對於每個key，用 n 個 byte 每個存儲一個標誌用來判斷 key 是否在集合中。原理就是使用 k 個 hash 函數來將 key 散列成一個整數。
在 W-TinyLFU 中使用 Count-Min Sketch 記錄 key 的訪問頻次，而它就是布隆過濾器的一個變種。
2、讀寫性能
在guava cache中我們說過其讀寫操作中夾雜著過期時間的處理，也就是你在一次Put操作中有可能還會做淘汰操作，所以其讀寫性能會受到一定影響，可以看上面的圖中，caffeine的確在讀寫操作上面完爆guava cache。主要是因為在caffeine，對這些事件的操作是通過異步操作，他將事件提交至隊列，這裡的隊列的數據結構是RingBuffer。然後會通過默認的ForkJoinPool.commonPool()，或者自己配置線程池，進行取隊列操作，然後在進行後續的淘汰，過期操作。
當然讀寫也是有不同的隊列，在caffeine中認為緩存讀比寫多很多，所以對於寫操作是所有線程共享一個Ringbuffer。
對於讀操作比寫操作更加頻繁，進一步減少競爭，其為每個線程配備了一個RingBuffer：
3、數據淘汰策略
在caffeine所有的數據都在ConcurrentHashMap中，這個和guava cache不同，guava cache是自己實現了個類似ConcurrentHashMap的結構。在caffeine中有三個記錄引用的LRU隊列:
Eden隊列:在caffeine中規定只能為緩存容量的%1,如果size=100,那這個隊列的有效大小就等於1。這個隊列中記錄的是新到的數據，防止突發流量由於之前沒有訪問頻率，而導致被淘汰。比如有一部新劇上線，在最開始其實是沒有訪問頻率的，防止上線之後被其他緩存淘汰出去，而加入這個區域。伊甸區，最舒服最安逸的區域，在這裡很難被其他數據淘汰。
Probation隊列:叫做緩刑隊列，在這個隊列就代表你的數據相對比較冷，馬上就要被淘汰了。這個有效大小為size減去eden減去protected。
Protected隊列:在這個隊列中，可以稍微放心一下了，你暫時不會被淘汰，但是別急，如果Probation隊列沒有數據了或者Protected數據滿了，你也將會被面臨淘汰的尷尬局面。當然想要變成這個隊列，需要把Probation訪問一次之後，就會提升為Protected隊列。這個有效大小為(size減去eden) X 80% 如果size =100，就會是79。
這三個隊列關係如下:
所有的新數據都會進入Eden。
Eden滿了，淘汰進入Probation。
如果在Probation中訪問了其中某個數據，則這個數據升級為Protected。
如果Protected滿了又會繼續降級為Probation。
對於發生數據淘汰的時候，會從Probation中進行淘汰。會把這個隊列中的數據隊頭稱為受害者，這個隊頭肯定是最早進入的，按照LRU隊列的算法的話那他其實他就應該被淘汰，但是在這裡只能叫他受害者，這個隊列是緩刑隊列，代表馬上要給他行刑了。這裡會取出隊尾叫候選者，也叫攻擊者。這裡受害者會和攻擊者PK決出我們應該被淘汰的。
通過我們的Count-Min Sketch中的記錄的頻率數據有以下幾個判斷:
如果攻擊者大於受害者，那麼受害者就直接被淘汰。
如果攻擊者
他認為設置一個預熱的門檻會讓整體命中率更高。
其他情況，隨機淘汰。
Caffeine功能剖析
1、轉瞬即逝-過期策略
在Caffeine中分為兩種緩存，一個是有界緩存，一個是無界緩存，無界緩存不需要過期並且沒有界限。在有界緩存中提供了三個過期API：
expireAfterWrite：代表著寫了之後多久過期。（上面列子就是這種方式）
expireAfterAccess：代表著最後一次訪問了之後多久過期。
expireAfter：在expireAfter中需要自己實現Expiry接口，這個接口支持create,update,以及access了之後多久過期。注意這個API和前面兩個API是互斥的。這裡和前面兩個API不同的是，需要你告訴緩存框架，他應該在具體的某個時間過期，也就是通過前面的重寫create,update,以及access的方法，獲取具體的過期時間。
2、除舊布新-更新策略
何為更新策略？就是在設定多長時間後會自動刷新緩存。
Caffeine提供了refreshAfterWrite()方法來讓我們進行寫後多久更新策略：
上面的代碼我們需要建立一個CacheLodaer來進行刷新,這裡是同步進行的，可以通過buildAsync方法進行異步構建。在實際業務中這裡可以把我們代碼中的mapper傳入進去，進行數據源的刷新。
但是實際使用中，你設置了一天刷新，但是一天後你發現緩存並沒有刷新。這是因為必有在1天後這個緩存再次訪問才能刷新，如果沒人訪問，那麼永遠也不會刷新。你明白了嗎？
我們來看看自動刷新他是怎麼做的呢？自動刷新只存在讀操作之後，也就是我們afterRead()這個方法，其中有個方法叫refreshIfNeeded，他會根據你是同步還是異步然後進行刷新處理。
3、知己知彼-打點監控
在Caffeine中提供了一些的打點監控策略，通過recordStats()Api進行開啟，默認是使用Caffeine自帶的，也可以自己進行實現。在StatsCounter接口中，定義了需要打點的方法目前來說有如下幾個:
recordHits：記錄緩存命中
recordMisses：記錄緩存未命中
recordLoadSuccess：記錄加載成功(指的是CacheLoader加載成功)
recordLoadFailure：記錄加載失敗
recordEviction：記錄淘汰數據
通過上面的監聽，我們可以實時監控緩存當前的狀態，以評估緩存的健康程度以及緩存命中率等，方便後續調整參數。
4、有始有終-淘汰監聽
有很多時候我們需要知道Caffeine中的緩存為什麼被淘汰了呢，從而進行一些優化？這個時候我們就需要一個監聽器,代碼如下所示:
在Caffeine中被淘汰的原因有很多種:
EXPLICIT: 這個原因是，用戶造成的，通過調用remove方法從而進行刪除。
REPLACED: 更新的時候，其實相當於把老的value給刪了。
COLLECTED: 用於我們的垃圾收集器，也就是我們上面減少的軟引用，弱引用。
EXPIRED：過期淘汰。
SIZE: 大小淘汰，當超過最大的時候就會進行淘汰。
當我們進行淘汰的時候就會進行回調，我們可以列印出日誌，對數據淘汰進行實時監控。