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