1. MySQL持久化數據,Redis只讀數據
redis在啓動之後，從數據庫加載數據。
讀請求：
不要求強一致性的讀請求，走redis，要求強一致性的直接從mysql讀取
寫請求：
數據首先都寫到數據庫，之後更新redis（先寫redis再寫mysql，如果寫入失敗事務回滾會造成redis中存在髒數據）
2.MySQL和Redis處理不同的數據類型
MySQL處理實時性數據，例如金融數據、交易數據
Redis處理實時性要求不高的數據，例如網站最熱貼排行榜，好友列表等
在併發不高的情況下，讀操作優先讀取redis，不存在的話就去訪問MySQL，並把讀到的數據寫回Redis中；寫操作的話，直接寫MySQL，成功後再寫入Redis(可以在MySQL端定義CRUD觸發器，在觸發CRUD操作後寫數據到Redis，也可以在Redis端解析binlog，再做相應的操作)
在併發高的情況下，讀操作和上面一樣，寫操作是異步寫，寫入Redis後直接返回，然後定期寫入MySQL
舉個例子：
1.當更新數據時，如更新某商品的庫存，當前商品的庫存是100，現在要更新爲99，先更新數據庫更改成99，然後刪除緩存，發現刪除緩存失敗了，這意味着數據庫存的是99，而緩存是100，這導致數據庫和緩存不一致。
解決方法：
這種情況應該是先刪除緩存，然後在更新數據庫，如果刪除緩存失敗，那就不要更新數據庫，如果說刪除緩存成功，而更新數據庫失敗，那查詢的時候只是從數據庫裏查了舊的數據而已，這樣就能保持數據庫與緩存的一致性。
2.在高併發的情況下，如果當刪除完緩存的時候，這時去更新數據庫，但還沒有更新完，另外一個請求來查詢數據，發現緩存裏沒有，就去數據庫裏查，還是以上面商品庫存爲例，如果數據庫中產品的庫存是100，那麼查詢到的庫存是100，然後插入緩存，插入完緩存後，原來那個更新數據庫的線程把數據庫更新爲了99，導致數據庫與緩存不一致的情況
解決方法：
遇到這種情況，可以用隊列的去解決這個問，創建幾個隊列，如20個，根據商品的ID去做hash值，然後對隊列個數取摸，當有數據更新請求時，先把它丟到隊列裏去，當更新完後在從隊列裏去除，如果在更新的過程中，遇到以上場景，先去緩存裏看下有沒有數據，如果沒有，可以先去隊列裏看是否有相同商品ID在做更新，如果有也把查詢的請求發送到隊列裏去，然後同步等待緩存更新完成。
這裏有一個優化點，如果發現隊列裏有一個查詢請求了，那麼就不要放新的查詢操作進去了，用一個while（true）循環去查詢緩存，循環個200MS左右，如果緩存裏還沒有則直接取數據庫的舊數據，一般情況下是可以取到的。
在高併發下解決場景二要注意的問題：
（1）讀請求時長阻塞
由於讀請求進行了非常輕度的異步化，所以一定要注意讀超時的問題，每個讀請求必須在超時間內返回，該解決方案最大的風險在於可能數據更新很頻繁，導致隊列中擠壓了大量的更新操作在裏面，然後讀請求會發生大量的超時，最後導致大量的請求直接走數據庫，像遇到這種情況，一般要做好足夠的壓力測試，如果壓力過大，需要根據實際情況添加機器。
（2）請求併發量過高
這裏還是要做好壓力測試，多模擬真實場景，併發量在最高的時候QPS多少，扛不住就要多加機器，還有就是做好讀寫比例是多少
（3）多服務實例部署的請求路由
可能這個服務部署了多個實例，那麼必須保證說，執行數據更新操作，以及執行緩存更新操作的請求，都通過nginx服務器路由到相同的服務實例上
（4）熱點商品的路由問題，導致請求的傾斜
某些商品的讀請求特別高，全部打到了相同的機器的相同丟列裏了，可能造成某臺服務器壓力過大，因爲只有在商品數據更新的時候纔會清空緩存，然後纔會導致讀寫併發，所以更新頻率不是太高的話，這個問題的影響並不是很大，但是確實有可能某些服務器的負載會高一些。
