之前我有部落格也嘗試過使用redis，在實際的專案中確實作用挺大的。至少對於資料的頻繁讀取來說都起著至關重要的作用。

但是隨著技術的學習，慢慢的業務要複雜起來，以後也許會用到redis叢集，所以在這邊查詢了一些資料，做了一些思考和理解。

如果有問題，請提出，虛心接受，認真學習。

一般的redis邏輯

請求過來，redis裡面有沒有？有就給使用者

沒有查詢資料庫

資料庫裡面有沒有？沒有告訴使用者沒有

有就查詢出來，給使用者，並且存放到redis

redis快取會出現什麼問題？

redis快取資料庫的資料，有一點就顯得特別重要，那就是資料一致性的問題。

單個數據庫在多執行緒操作的時候如果不是資料庫鎖的限制會出現很多資料不一致的問題，ACID這裡我就不多說了。

redis快取也會有這樣的問題，就是資料庫的資料更新到redis是會有時間差的，這樣的時間差就會導致資料不一致。

比如一件商品價格在資料庫裡面是500，然後redis也是500，但是突然資料庫修改成了600，如果所有使用者都是讀入資料庫的話，資料庫會加鎖，然後避免使用者讀出之前那個500，但是redis的更新怎麼說都是有時間差的，所以使用者就有可能讀取到500這個資料。

這就是資料不一致的問題。

redis適合快取怎麼樣的資料？

這裡的資料分為兩塊，第一是資料庫的資料，第二是頁面的一些靜態資料。

這裡說的是資料庫的資料。

頁面的一些靜態資料不適合存放在快取中。

然後對於上面提出的資料不一致的問題，所以快取的資料也有要求。

不要快取那些對於資料一致性要求很高的資料。

如果這個資料存在被修改的可能性，那麼最好不要存快取，要麼，就不要放資料庫，只放快取。

那些對於資料一致性不高的資料，都是可以放的。

強調一點是，如果這個資料放了，但是對於這個資料的操作不是修改，而是隻有刪除的話，也是可以存放快取的，因為在實際操作中，如果一個刪除操作被執行的時候，快取可以先進行刪除，這樣就能確保沒有使用者能夠讀取到刪除之後的資料，然後再對資料庫進行刪除。

redis叢集

redis叢集，這邊我給出的建議是使用redis的主從複製功能，這個功能和mysql的主從複製是一個道理，都能很好的確保資料的一致性。

具體redis叢集的配置以及實驗我會在後面新的部落格中給出的。

總結一下：具體的使用過程中，使用redis的超時可以對資料進行一些持久化管理，對於一些資料一致性不高的資料進行快取，使得讀取速度提高，使用redis叢集時可以是用主從複製功能，Redis叢集沒有中心節點，並且帶有複製和故障轉移特性，這可以避免單個節點成為效能瓶頸，或者因為某個節點下線而導致整個叢集下線。