Redis特性

先列舉一下Redis的特點：

讀寫效能優異

持久化

資料型別豐富

單執行緒

資料自動過期

釋出訂閱

分散式

作為快取使用時，一般有兩種方式更新資料：

1、讀取前，先去讀Redis，如果沒有資料，讀取資料庫，將資料拉入Redis。

2、修改資料時，同時寫入Redis。

看到知乎上面有個問題：

一臺MySQL，一臺Redis，兩臺應用伺服器，使用者的資料儲存持久化在MySQL中，快取在Redis，有請求的時候從Redis中獲取快取的使用者資料，有修改則同時修改
MySQL和Redis中的資料。現在問題是：
1. 先儲存到MySQL和先儲存到Redis都面臨著一個儲存成功而另外一個儲存失敗的情況，這樣，如何保證
 
MySQL與Redis中的資料同步？
2. 兩臺應用伺服器的併發訪問，如何保證資料的安全性？

深度分析：

查詢使用Redis：先查詢cache，miss時查詢db，寫入cache

寫操作db：寫db成功後，更新cache

重點說下寫：如果寫db成功後，寫cache，會有事務性和併發性兩方面問題需要注意。

1.事務性問題：一個事務包含多個db操作，操作一些db成功，寫cache成功，操作二寫db失敗，事務回滾，db資料回滾，cache無法回滾，導致髒資料。

2.併發性問題：兩個更新操作併發，如更新名字，並且cache中key以名字為關鍵字，更新一寫db成功，寫快取XXXX1成功。更新二寫db成功，寫快取XXXX2成功。導致cache髒資料。

往redis上面同步資料這塊有兩種方式：全量更新和增量更新。一般是增量更新用的多，對於及時性比較強的業務，我倒是覺得不用redis,就用mysql也沒啥問題，犧牲些效能，保證穩定性挺好的， 當然對於要求高的公司來說，可能快取是必須的，變更都在db部分，所以在db同步資料到redis上面有一定延遲，弄個訊息佇列，通過程序間通訊方式把增量的資料同步過去。寫的時候先刪快取，再寫資料庫，然後同步cache.業務上面訪問情況是先查詢cache，miss時查詢db，寫入cache.

在說一下事務性那塊的問題：mysql在存入資料時候會有日誌記錄，更新redis時候應該根據mysql的日誌記錄來進行更新redis，所以就需要一個工具來分析mysql日誌binlog,我從網上找到一個工具Canal（https://github.com/alibaba/canal），後續研究完Canal的用法再分享。