A. redis做mysql的緩存
redis緩存其實就是把經常訪問的數據放到redis裡面，用戶查詢的時候先去redis查詢，沒有查到就執行sql語句查詢，同時把數據同步到redis裡面。redis只做讀操作，在內存中查詢速度快。
使用redis做緩存必須解決兩個問題，首先就是確定用何種數據結構存儲來自mysql的數據；確定數據結構之後就是需要確定用什麼標識來作為數據的key。
mysql是按照表存儲數據的，這些表是由若干行組成。每一次執行select查詢，mysql都會返回一個結果集，這個結果是由若干行組成的。redis有五種數據結構：列表list，哈希hash，字元串string，集合set，sorted set(有序集合)，對比幾種數據結構，string和hash是比較適合存儲行的數據結構，可以把數據轉成json字元串存入redis。
全量遍歷鍵： keys pattern keys *
有人說 KEYS 相當於關系性數據的庫的 select * ，在生產環境幾乎是要禁用的
不管上面說的對不對， keys 肯定是有風險的。那我們就換一種方案，在存數據的時候。把數據的鍵存一下，也存到redis裡面選hash類型，那麼取的時候就可以直接通過這個hash獲取所有的值，自我感覺非常好用！
B. Redis 如何保持和 MySQL 數據一致
redis在啟動之後，從資料庫載入數據。
讀請求：
不要求強一致性的讀請求，走redis，要求強一致性的直接從mysql讀取
寫請求：
數據首先都寫到資料庫，之後更新redis（先寫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、熱點商品的路由問題，導致請求的傾斜
某些商品的讀請求特別高，全部打到了相同的機器的相同丟列里了，可能造成某台伺服器壓力過大，因為只有在商品數據更新的時候才會清空緩存，然後才會導致讀寫並發，所以更新頻率不是太高的話，這個問題的影響並不是很大，但是確實有可能某些伺服器的負載會高一些。
img
搜索微信號（ID：芋道源碼），可以獲得各種 Java 源碼解析。
並且，回復【書籍】後，可以領取筆者推薦的各種 Java 從入門到架構的書籍。
C. 如何保證redis與mysql數據最終一致性
保證redis與mysql數據最終一致性，有以下幾種方案
先更新redis，再更新mysql
流程圖
最後mysql是請求1的數據，redis是請求2的數據，不能保證最終一致性
先更新mysql，再更新redis
流程圖
最後mysql是請求2的數據，redis是請求1的數據，不能保證最終一致性
先刪redis，再更新mysql
流程圖
最後mysql是新數據，redis是舊數據，不能保證最終一致性
先更新mysql，再刪redis
流程圖
最後mysql是新數據，redis是舊數據
延遲刪除: 先更新mysql，然後sleep一段時間，再刪除redis
流程圖
sleep時間，由業務側決定，最好是大於查詢介面的耗時。
本方案有一個問題: 更新mysql後，刪除redis之前，查詢請求從redis查到的是舊數據，雖然可以保證最終一致性，但是查到舊數據的時間較長
延遲雙刪: 先刪redis，然後更新mysql，然後sleep一段時間，再刪除redis。
本方案可以讓用戶更早查詢到新數據。
方案六看起來是所有方案中最優的，但其實還是有問題，比如下面的情況（出現概率極低），如果確實發生了這種情況，只能等key到達過期時間自己失效，或者引入mq等中間件對刪除redis失敗做重試。
最後，友情提示一下，這個問題是面試高頻題，但是面試沒法畫圖，很難描述清楚各種場景，可以用下面的表達方式