Spring Cloud Spring Boot mybatis分佈式微服務雲架構（三十六）使用Redis作集中式緩存（2）

問題思考

爲何一樣的邏輯在EhCache中沒有問題，可是到Redis中會出現這個問題呢？

在EhCache緩存時沒有問題，主要是因爲EhCache是進程內的緩存框架，第一次經過select查詢出的結果被加入到EhCache緩存中，第二次查詢從EhCache取出的對象與第一次查詢對象其實是同一個對象（能夠在使用Chapter4-4-1工程中，觀察u1==u2來看看是不是同一個對象），所以咱們在更新age的時候，實際已經更新了EhCache中的緩存對象。

而Redis的緩存獨立存在於咱們的Spring應用以外，咱們對數據庫中數據作了更新操做以後，沒有通知Redis去更新相應的內容，所以咱們取到了緩存中未修改的數據，致使了數據庫與緩存中數據的不一致。

所以咱們在使用緩存的時候，要注意緩存的生命週期，利用好上一篇上提到的幾個註解來作好緩存的更新、刪除

進一步修改

針對上面的問題，咱們只須要在更新age的時候，經過@CachePut來讓數據更新操做同步到緩存中，就像下面這樣：

@CacheConfig(cacheNames = "users")
public interface UserRepository extends JpaRepository<User, Long> {

    @Cacheable(key = "#p0")
    User findByName(String name);

    @CachePut(key = "#p0.name")
    User save(User user);

}

在redis-cli中flushdb，清空一下以前的緩存內容，再執行單元測試，能夠得到下面的結果：

Hibernate: insert into user (age, name) values (?, ?)
第一次查詢：10
第二次查詢：10
Hibernate: select user0_.id as id1_0_0_, user0_.age as age2_0_0_, user0_.name as name3_0_0_ from user user0_ where user0_.id=?
Hibernate: update user set age=?, name=? where id=?
第三次查詢：20

能夠看到，咱們的第三次查詢得到了正確的結果！同時，咱們的第一次查詢也不是經過select查詢得到的，由於在初始化數據的時候，調用save方法時，就已經將這條數據加入了redis緩存中，所以後續的查詢就直接從redis中獲取了。

本文內容到此爲止，主要介紹了爲何要使用Redis作緩存，以及如何在Spring Boot中使用Redis作緩存，而且經過一個小問題來幫助你們理解緩存機制，在使用過程當中，必定要注意緩存生命週期的控制，防止數據不一致的狀況出現。

源碼來源