我覺得對快取認識，僅僅會寫快取及其淘汰演算法是膚淺的、不負責任的。我們還需要決定，什麼樣的資料是需要進行快取，多大的資料才能進行快取。
首先，快取資料往往是讀取次數非常頻繁的，但是底層資料不能更新太快，否則會導致快取的「髒讀」。我在一本書上看到的是讀寫比要大於10。
另外，快取資料不能太大，快取資料過大會大大占用jvm記憶體空間，同樣不利於程式響應。
所以，在新增快取之前，需要知道快取規模大小。
例：某個電網有大概100個水電站，系統需要提取這100個水電站的每日資訊（double型別），時間尺度為15min，像這樣的資訊一共有10類（水位、氣象、發電等...），問需要快取多大？
答案：對於乙個電站某日的1類資訊，因為是每15min一次的，那麼每小時4條資料，每天有96條資料，為double[96]。一共10類，即10個double[96]，一共100個電站，故有100*10*double[96]的資料量。
大小可以估算一下：100*10*96*8≈8*10^5（bit），大約是1m的資料量。所以占用的記憶體空間不大。
三大快取技術
1.瀏覽器快取 程式快取 ob快取 瀏覽器接收伺服器返回的資料，每達到一定的量，就顯示到頁面上,如果最後一次沒達到量，也顯示到頁面 每次傳送php請求，php每一次的輸出都會先存到程式快取中，當整個php程式執行結束，在返回給apache，最後返回到瀏覽器 程式快取是語言底層實現的，人為不可操控！每...
Redis三大問題 快取穿透 快取擊穿 快取雪崩
快取擊穿 快取雪崩 前台請求，後台先從快取中取資料，取到直接返回結果，取不到時從資料庫中取，資料庫取到更新快取，並返回結果，資料庫也沒取到，直接返回空結果。快取穿透就是當使用者訪問一條資料時，快取和資料庫中都不存在，就會不斷的發起請求。如果使用者是攻擊者，會導致資料庫壓力過大。解決方案 快取空物件 ...
談談redis快取三大問題（二） 快取雪崩
今天抽時間和大家聊聊redis的雪崩以及redis集群的演變過程。首先來說說什麼是redis的快取雪崩。如圖是乙個比較常見的業務流程圖，先去看快取是否存在，如果存在返回，如果不存在直接查資料庫，並更新快取。一般在設定快取的時候，都會去設定乙個失效時間，防止無用快取占用大量記憶體。常見的快取雪崩分為兩...