資訊專欄INFORMATION COLUMN
摘要：先簡單介紹一下愛奇藝的緩存道路的發(fā)展吧。可以看見圖中分為幾個階段第一階段數(shù)據(jù)同步加通過消息隊列進(jìn)行數(shù)據(jù)同步至，然后應(yīng)用直接去取緩存這個階段優(yōu)點(diǎn)是由于是使用的分布式緩存，所以數(shù)據(jù)更新快。愛奇藝的緩存的發(fā)展也是基于此之上，通過對的二次開發(fā)
1.背景
本文是上周去技術(shù)沙龍聽了一下愛奇藝的Java緩存之路有感寫出來的。先簡單介紹一下愛奇藝的java緩存道路的發(fā)展吧。
可以看見圖中分為幾個階段:
第一階段:數(shù)據(jù)同步加redis
通過消息隊列進(jìn)行數(shù)據(jù)同步至redis，然后Java應(yīng)用直接去取緩存
這個階段優(yōu)點(diǎn)是:由于是使用的分布式緩存，所以數(shù)據(jù)更新快。缺點(diǎn)也比較明顯:依賴Redis的穩(wěn)定性，一旦redis掛了，整個緩存系統(tǒng)不可用，造成緩存雪崩，所有請求打到DB。
第二，三階段:JavaMap到Guava cache
這個階段使用進(jìn)程內(nèi)緩存作為一級緩存，redis作為二級。優(yōu)點(diǎn):不受外部系統(tǒng)影響，其他系統(tǒng)掛了，依然能使用。缺點(diǎn):進(jìn)程內(nèi)緩存無法像分布式緩存那樣做到實(shí)時更新。由于java內(nèi)存有限，必定緩存得設(shè)置大小，然后有些緩存會被淘汰，就會有命中率的問題。
第四階段: Guava Cache刷新
為了解決上面的問題，利用Guava Cache可以設(shè)置寫后刷新時間，進(jìn)行刷新。解決了一直不更新的問題，但是依然沒有解決實(shí)時刷新。
第五階段: 外部緩存異步刷新
這個階段擴(kuò)展了Guava Cache,利用redis作為消息隊列通知機(jī)制，通知其他java應(yīng)用程序進(jìn)行刷新。
這里簡單介紹一下愛奇藝緩存發(fā)展的五個階段，當(dāng)然還有一些其他的優(yōu)化，比如GC調(diào)優(yōu)，緩存穿透，緩存覆蓋的一些優(yōu)化等等。有興趣的同學(xué)可以關(guān)注公眾號，聯(lián)系我進(jìn)行交流。
原始社會 - 查庫上面說的是愛奇藝的一個進(jìn)化線路，但是在大家的一般開發(fā)過程中，第一步一般都沒有redis，而是直接查庫。
在流量不大的時候，查數(shù)據(jù)庫或者讀取文件是最為方便，也能完全滿足我們的業(yè)務(wù)要求。
古代社會 - HashMap當(dāng)我們應(yīng)用有一定流量之后或者查詢數(shù)據(jù)庫特別頻繁，這個時候就可以祭出我們的java中自帶的HashMap或者ConcurrentHashMap。我們可以在代碼中這么寫:
public class CustomerService {
private HashMap hashMap = new HashMap<>();
private CustomerMapper customerMapper;
public String getCustomer(String name){
String customer = hashMap.get(name);
if ( customer == null){
customer = customerMapper.get(name);
hashMap.put(name,customer);
}
return customer;
}
}
但是這樣做就有個問題HashMap無法進(jìn)行數(shù)據(jù)淘汰，內(nèi)存會無限制的增長，所以hashMap很快也被淘汰了。當(dāng)然并不是說他完全就沒用，就像我們古代社會也不是所有的東西都是過時的，比如我們中華名族的傳統(tǒng)美德是永不過時的，就像這個hashMap一樣的可以在某些場景下作為緩存，當(dāng)不需要淘汰機(jī)制的時候，比如我們利用反射，如果我們每次都通過反射去搜索Method,field，性能必定低效，這時我們用HashMap將其緩存起來，性能能提升很多。
近代社會 - LRUHashMap在古代社會中難住我們的問題無法進(jìn)行數(shù)據(jù)淘汰，這樣會導(dǎo)致我們內(nèi)存無限膨脹,顯然我們是不可以接受的。有人就說我把一些數(shù)據(jù)給淘汰掉唄，這樣不就對了，但是怎么淘汰呢？隨機(jī)淘汰嗎？當(dāng)然不行，試想一下你剛把A裝載進(jìn)緩存，下一次要訪問的時候就被淘汰了，那又會訪問我們的數(shù)據(jù)庫了，那我們要緩存干嘛呢？
所以聰明的人們就發(fā)明了幾種淘汰算法，下面列舉下常見的三種FIFO,LRU,LFU（還有一些ARC,MRU感興趣的可以自行搜索）:
FIFO:先進(jìn)先出，在這種淘汰算法中，先進(jìn)入緩存的會先被淘汰。這種可謂是最簡單的了，但是會導(dǎo)致我們命中率很低。試想一下我們?nèi)绻袀€訪問頻率很高的數(shù)據(jù)是所有數(shù)據(jù)第一個訪問的，而那些不是很高的是后面再訪問的，那這樣就會把我們的首個數(shù)據(jù)但是他的訪問頻率很高給擠出。
LRU:最近最少使用算法。在這種算法中避免了上面的問題，每次訪問數(shù)據(jù)都會將其放在我們的隊尾，如果需要淘汰數(shù)據(jù)，就只需要淘汰隊首即可。但是這個依然有個問題，如果有個數(shù)據(jù)在1個小時的前59分鐘訪問了1萬次(可見這是個熱點(diǎn)數(shù)據(jù)),再后一分鐘沒有訪問這個數(shù)據(jù)，但是有其他的數(shù)據(jù)訪問，就導(dǎo)致了我們這個熱點(diǎn)數(shù)據(jù)被淘汰。
LFU:最近最少頻率使用。在這種算法中又對上面進(jìn)行了優(yōu)化，利用額外的空間記錄每個數(shù)據(jù)的使用頻率，然后選出頻率最低進(jìn)行淘汰。這樣就避免了LRU不能處理時間段的問題。
上面列舉了三種淘汰策略，對于這三種，實(shí)現(xiàn)成本是一個比一個高，同樣的命中率也是一個比一個好。而我們一般來說選擇的方案居中即可，即實(shí)現(xiàn)成本不是太高，而命中率也還行的LRU,如何實(shí)現(xiàn)一個LRUMap呢？我們可以通過繼承LinkedHashMap，重寫removeEldestEntry方法，即可完成一個簡單的LRUMap。
class LRUMap extends LinkedHashMap {
private final int max;
private Object lock;
public LRUMap(int max, Object lock) {
//無需擴(kuò)容
super((int) (max * 1.4f), 0.75f, true);
this.max = max;
this.lock = lock;
}
/**
* 重寫LinkedHashMap的removeEldestEntry方法即可
* 在Put的時候判斷，如果為true，就會刪除最老的
* @param eldest
* @return
*/
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
return size() > max;
}
public Object getValue(Object key) {
synchronized (lock) {
return get(key);
}
}
public void putValue(Object key, Object value) {
synchronized (lock) {
put(key, value);
}
}
public boolean removeValue(Object key) {
synchronized (lock) {
return remove(key) != null;
}
}
public boolean removeAll(){
clear();
return true;
}
}
在LinkedHashMap中維護(hù)了一個entry(用來放key和value的對象)鏈表。在每一次get或者put的時候都會把插入的新entry，或查詢到的老entry放在我們鏈表末尾。
可以注意到我們在構(gòu)造方法中，設(shè)置的大小特意設(shè)置到max*1.4，在下面的removeEldestEntry方法中只需要size>max就淘汰，這樣我們這個map永遠(yuǎn)也走不到擴(kuò)容的邏輯了，通過重寫LinkedHashMap，幾個簡單的方法我們實(shí)現(xiàn)了我們的LruMap。
在近代社會中已經(jīng)發(fā)明出來了LRUMap,用來進(jìn)行緩存數(shù)據(jù)的淘汰，但是有幾個問題:
鎖競爭嚴(yán)重，可以看見我的代碼中，Lock是全局鎖，在方法級別上面的，當(dāng)調(diào)用量較大時，性能必然會比較低。
不支持過期時間
不支持自動刷新
所以谷歌的大佬們對于這些問題，按捺不住了，發(fā)明了Guava cache，在Guava cache中你可以如下面的代碼一樣，輕松使用:
public static void main(String[] args) throws ExecutionException {
LoadingCache cache = CacheBuilder.newBuilder()
.maximumSize(100)
//寫之后30ms過期
.expireAfterWrite(30L, TimeUnit.MILLISECONDS)
//訪問之后30ms過期
.expireAfterAccess(30L, TimeUnit.MILLISECONDS)
//20ms之后刷新
.refreshAfterWrite(20L, TimeUnit.MILLISECONDS)
//開啟weakKey key 當(dāng)啟動垃圾回收時，該緩存也被回收
.weakKeys()
.build(createCacheLoader());
System.out.println(cache.get("hello"));
cache.put("hello1", "我是hello1");
System.out.println(cache.get("hello1"));
cache.put("hello1", "我是hello2");
System.out.println(cache.get("hello1"));
}
public static com.google.common.cache.CacheLoader createCacheLoader() {
return new com.google.common.cache.CacheLoader() {
@Override
public String load(String key) throws Exception {
return key;
}
};
}
我將會從guava cache原理中，解釋guava cache是如何解決LRUMap的幾個問題的。
鎖競爭guava cache采用了類似ConcurrentHashMap的思想，分段加鎖，在每個段里面各自負(fù)責(zé)自己的淘汰的事情。在Guava根據(jù)一定的算法進(jìn)行分段，這里要說明的是，如果段太少那競爭依然很嚴(yán)重，如果段太多會容易出現(xiàn)隨機(jī)淘汰，比如大小為100的，給他分100個段，那也就是讓每個數(shù)據(jù)都獨(dú)占一個段，而每個段會自己處理淘汰的過程，所以會出現(xiàn)隨機(jī)淘汰。在guava cache中通過如下代碼，計算出應(yīng)該如何分段。
int segmentShift = 0;
int segmentCount = 1;
while (segmentCount < concurrencyLevel && (!evictsBySize() || segmentCount * 20 <= maxWeight)) {
++segmentShift;
segmentCount <<= 1;
}
上面segmentCount就是我們最后的分段數(shù)，其保證了每個段至少10個Entry。如果沒有設(shè)置concurrencyLevel這個參數(shù)，那么默認(rèn)就會是4，最后分段數(shù)也最多為4，例如我們size為100，會分為4段，每段最大的size是25。
在guava cache中對于寫操作直接加鎖，對于讀操作，如果讀取的數(shù)據(jù)沒有過期，且已經(jīng)加載就緒，不需要進(jìn)行加鎖，如果沒有讀到會再次加鎖進(jìn)行二次讀，如果還沒有需要進(jìn)行緩存加載，也就是通過我們配置的CacheLoader，我這里配置的是直接返回Key，在業(yè)務(wù)中通常配置從數(shù)據(jù)庫中查詢。
如下圖所示:
相比于LRUMap多了兩種過期時間，一個是寫后多久過期expireAfterWrite，一個是讀后多久過期expireAfterAccess。很有意思的事情是，在guava cache中對于過期的Entry并沒有馬上過期(也就是并沒有后臺線程一直在掃)，而是通過進(jìn)行讀寫操作的時候進(jìn)行過期處理，這樣做的好處是避免后臺線程掃描的時候進(jìn)行全局加鎖。看下面的代碼:
public static void main(String[] args) throws ExecutionException, InterruptedException {
Cache cache = CacheBuilder.newBuilder()
.maximumSize(100)
//寫之后5s過期
.expireAfterWrite(5, TimeUnit.MILLISECONDS)
.concurrencyLevel(1)
.build();
cache.put("hello1", "我是hello1");
cache.put("hello2", "我是hello2");
cache.put("hello3", "我是hello3");
cache.put("hello4", "我是hello4");
//至少睡眠5ms
Thread.sleep(5);
System.out.println(cache.size());
cache.put("hello5", "我是hello5");
System.out.println(cache.size());
}
輸出:
4
1
從這個結(jié)果中我們知道，在put的時候才進(jìn)行的過期處理。特別注意的是我上面concurrencyLevel(1)我這里將分段最大設(shè)置為1，不然不會出現(xiàn)這個實(shí)驗(yàn)效果的，在上面一節(jié)中已經(jīng)說過，我們是以段位單位進(jìn)行過期處理。在每個Segment中維護(hù)了兩個隊列:
final Queue> writeQueue;
final Queue> accessQueue;
writeQueue維護(hù)了寫隊列，隊頭代表著寫得早的數(shù)據(jù)，隊尾代表寫得晚的數(shù)據(jù)。
accessQueue維護(hù)了訪問隊列,和LRU一樣，用來我們進(jìn)行訪問時間的淘汰，如果當(dāng)這個Segment超過最大容量，比如我們上面所說的25，超過之后，就會把a(bǔ)ccessQueue這個隊列的第一個元素進(jìn)行淘汰。
void expireEntries(long now) {
drainRecencyQueue();
ReferenceEntry e;
while ((e = writeQueue.peek()) != null && map.isExpired(e, now)) {
if (!removeEntry(e, e.getHash(), RemovalCause.EXPIRED)) {
throw new AssertionError();
}
}
while ((e = accessQueue.peek()) != null && map.isExpired(e, now)) {
if (!removeEntry(e, e.getHash(), RemovalCause.EXPIRED)) {
throw new AssertionError();
}
}
}
上面就是guava cache處理過期Entries的過程，會對兩個隊列一次進(jìn)行peek操作，如果過期就進(jìn)行刪除。一般處理過期Entries可以在我們的put操作的前后，或者讀取數(shù)據(jù)時發(fā)現(xiàn)過期了，然后進(jìn)行整個Segment的過期處理，又或者進(jìn)行二次讀lockedGetOrLoad操作的時候調(diào)用。
