對強一致要求比較高的，應採用實時同步方案，即查詢快取查詢不到再從db查詢，儲存到快取；更新快取時，先更新資料庫，再將快取設定過期（建議不要去更新快取內容，直接設定快取過期）
@cacheable：查詢時使用，注意long型別需轉換為string型別，否則會拋異常。
@cacheput：更新時使用，使用此註解，一定會從db上查詢資料
@cacheevict：刪除時使用
@caching：組合用法
快取穿透是指查詢乙個一定不存在的資料，由於快取是不命中時需要從資料庫查詢，查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到資料庫去查詢，造成快取穿透。
解決辦法：
持久層查詢不到就快取空結果，查詢時先判斷快取中是否exists(key)，如果有直接返回空，沒有則查詢後返回。
注意insert時需清除查詢的key，否則即便db中有值也查不到（當然也可以設定空快取的過期時間）
如果快取集中在一段時間內失效，發生大量的快取穿透，所有的查詢都落在資料庫上，造成了快取雪崩。
解決方法：
這個沒有完美解決辦法，但可以分析使用者行為，盡量讓失效時間點均勻分布。
大多數系統設計者考慮用加鎖或者佇列的方式保證快取的單執行緒（程序）寫，從而避免失效時大量的併發請求落到底層儲存系統上。
熱點key：某個key訪問非常頻繁，當key失效的時候有大量執行緒來構建快取，導致負載增加，系統崩潰。
解決方法：
1、使用鎖，單機用synchronized，lock等，分布式用分布式鎖。
2、快取過期時間不設定，而是設定在key對應的value裡。如果檢測到存的時間超過過期時間則非同步更新快取。
3、在value設定乙個比過期時間t0小的過期時間值t1，當t1過期的時候，延長t1並做更新快取操作。
4、設定標籤快取，標籤快取設定過期時間，標籤快取過期後，需非同步的更新實際快取。
redis快取與mysql一致性問題
使用redis例項如下 先讀取快取，如果快取不存在，則讀取資料庫 object stuobj new object public stu getstufromcache string key return stu 問題分析 不管是先寫庫，再刪除快取 還是先刪快取，再寫庫，都有可能出現資料不一致的情況...
Redis快取一致性
用過redis的應該都清楚，redis作為記憶體快取，只是他查詢快的一大優勢，關係型資料庫只能用作儲存重要資料，或者備份快取的資料，這個時候，不可避免，我們會遇到快取中的資料與關係型資料庫中的資料不一致的情況。出現不一致的現象很常見，如果你是單個使用者肯定不會出現這種情況，如果在多執行緒併發的情況下...
redis 快取更新一致性
當執行寫操作後，需要保證從快取讀取到的資料與資料庫中持久化的資料是一致的，因此需要對快取進行更新。因為涉及到資料庫和快取兩步操作，難以保證更新的原子性。在設計更新策略時，我們需要考慮多個方面的問題 更新快取有兩種方式 更新快取和更新資料庫有兩種順序 兩兩組合共有四種更新策略，現在我們逐一進行分析。併...