前兩篇文章大致實現了通用快取，快取加不加，哪些方法加，哪些方法不加已經實現了人為的控制，但是！！！
如果想讓這個註解
@around("execution(* com.lkl.service.*serviceimpl.find*(..))")
生效，方法必須要以指定的方法名開頭，該例子中必須要以find開頭。如果方法名是queryall()的話，還需要另外做乙個切入點，這樣就沒有達到通用的目的。
想要做到更加靈活，就要用到@annotation切入點表示式。代表只用該註解的方法，才會進入切面。
@around("@annotation(com.lkl.annotations.rediscache)")
此時，對應上面文章（redis通用快取設計2）中就不在判斷是否方法上是否存在@rediscache這個註解了，因為@annotation這種表示式就代表有這個註解才會進入切面。
**修改如下：
@around("@annotation(com.lkl.annotations.rediscache)")
public
object around(proceedingjoinpoint pjp)
else
catch
(throwable throwable)
}return
result;
}
Redis快取設計
策略 一致性維護成本 lru lrf fifo最差低 超時剔除 較差較低 主動更新強高 低一致性業務 最大記憶體和淘汰策略的方式，maxmemory policy 高一致性業務 超時剔除和主動更新 解決快取穿透 適用場景 維護成本 快取空物件 資料命中不高，資料頻繁變化實時性高 維護簡單，需要過多的...
redis 快取設計
1 快取穿透 查詢乙個不存在的key 資料,快取層和儲存層都不會命中，將導致不存在的資料每次請求都要到儲存層去查詢，失去快取保護db 的意義。解決方案 有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器 不了解的可以看這裡 將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一...
redis 快取擊穿 3
在談論快取擊穿之前，我們先來回憶下從快取中載入資料的邏輯，如下圖所示 因此，如果黑客每次故意查詢乙個在快取內必然不存在的資料，導致每次請求都要去儲存層去查詢，這樣快取就失去了意義。如果在大流量下資料庫可能掛掉。這就是快取擊穿。場景如下圖所示 我們正常人在登入首頁的時候，都是根據userid來命中資料...