1.Redis 緩存和 MySQL 數據如何實現一致性
-
需求原由javascript
-
緩存和數據庫一致性解決方案java
在高併發的業務場景下，數據庫大多數狀況都是用戶併發訪問最薄弱的環節。因此，就須要使用redis作一個緩衝操做，讓請求先訪問到redis，而不是直接訪問MySQL等數據庫。mysql
讀取緩存步驟通常沒有什麼問題，可是一旦涉及到數據更新：數據庫和緩存更新，就容易出現緩存(Redis)和數據庫（MySQL）間的數據一致性問題。redis
不論是先寫MySQL數據庫，再刪除Redis緩存；仍是先刪除緩存，再寫庫，都有可能出現數據不一致的狀況。sql
舉一個例子：數據庫
1.若是刪除了緩存Redis，尚未來得及寫庫MySQL，另外一個線程就來讀取，發現緩存爲空，則去數據庫中讀取數據寫入緩存，此時緩存中爲髒數據。緩存
2.若是先寫了庫，在刪除緩存前，寫庫的線程宕機了，沒有刪除掉緩存，則也會出現數據不一致狀況。架構
由於寫和讀是併發的，無法保證順序,就會出現緩存和數據庫的數據不一致的問題。併發
如來解決？這裏給出兩個解決方案，先易後難，結合業務和技術代價選擇使用。框架
緩存和數據庫一致性解決方案
1.第一種方案：採用延時雙刪策略
在寫庫先後都進行redis.del(key)操做，而且設定合理的超時時間。
僞代碼以下
public void write(String key,Object data){ redis.delKey(key); db.updateData(data); Thread.sleep(500); redis.delKey(key); }
2.具體的步驟就是：
1）先刪除緩存
2）再寫數據庫
3）休眠500毫秒
4）再次刪除緩存
那麼，這個500毫秒怎麼肯定的，具體該休眠多久呢？
須要評估本身的項目的讀數據業務邏輯的耗時。這麼作的目的，就是確保讀請求結束，寫請求能夠刪除讀請求形成的緩存髒數據。
固然這種策略還要考慮redis和數據庫主從同步的耗時。最後的的寫數據的休眠時間：則在讀數據業務邏輯的耗時基礎上，加幾百ms。好比：休眠1秒。
3.設置緩存過時時間
從理論上來講，給緩存設置過時時間，是保證最終一致性的解決方案。全部的寫操做以數據庫爲準，只要到達緩存過時時間，則後面的讀請求天然會從數據庫中讀取新值而後回填緩存。
4.該方案的弊端
結合雙刪策略+緩存超時設置，這樣最差的狀況就是在超時時間內數據存在不一致，並且又增長了寫請求的耗時。
第二種方案：異步更新緩存(基於訂閱binlog的同步機制)
1.技術總體思路：
MySQL binlog增量訂閱消費+消息隊列+增量數據更新到redis
1）讀Redis：熱數據基本都在Redis
2）寫MySQL:增刪改都是操做MySQL
3）更新Redis數據：MySQ的數據操做binlog，來更新到Redis
2.Redis更新
1）數據操做主要分爲兩大塊：
一個是全量(將所有數據一次寫入到redis)
一個是增量（實時更新）
這裏說的是增量,指的是mysql的update、insert、delate變動數據。
2）讀取binlog後分析 ，利用消息隊列,推送更新各臺的redis緩存數據。
這樣一旦MySQL中產生了新的寫入、更新、刪除等操做，就能夠把binlog相關的消息推送至Redis，Redis再根據binlog中的記錄，對Redis進行更新。
其實這種機制，很相似MySQL的主從備份機制，由於MySQL的主備也是經過binlog來實現的數據一致性。
這裏能夠結合使用canal(阿里的一款開源框架)，經過該框架能夠對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave數據庫的備份請求，使得Redis的數據更新達到了相同的效果。
固然，這裏的消息推送工具你也能夠採用別的第三方：kafka、rabbitMQ等來實現推送更新Redis。
總結
第一種
- 讀的時候，先讀緩存，緩存沒有的話，讀數據庫，取出數據後放入緩存，同時返回響應。
- 更新的時候，先刪除緩存，在更新數據庫。
第二種
- 讀的時候，先讀緩存，緩存沒有的話，讀數據庫，取出數據後放入緩存，同時返回響應。
- 更新的時候，先更新數據庫，再刪除緩存。
第二種是Cache Aside Pattern的本來思路，用的比較多，第一種也有在用。爲何會形成這兩種分歧勒？緣由在於：
第一種方案引入了緩存-數據庫雙寫不一致的問題，即讀數據（寫緩存）與修改數據（寫數據庫）併發的狀況下，若修改數據數據庫事務還沒提交，可是已經把緩存從redis中刪除，此時來了個讀請求，會把舊的數據刷到緩存裏面，這樣就致使了緩存中的數據直到下一次修改數據庫以前確定是與數據庫不一致的。
第二種方案引入了另一個問題，在提交事務以後，若更新緩存失敗，也會致使緩存數據庫不一致。
facebook公司用的是第二種方案，由於在高併發的狀況下，第一種方案帶來的影響確定比第二種方案要大。由於：
- 第一：致使更新緩存失敗的狀況機率是很小的，就算髮生了，那麼問題就大了，比起解決緩存和數據庫不一致，更應該增強Redis架構的可用性。
- 第二，高併發狀況下第一種狀況發生的機率是很高的。、
其實我的以爲在沒有讀寫分離的狀況下就用第二種方案就夠了，引入redis主從架構解決redis可用性就完了，另外，咱們能夠爲緩存設置過時時間，減少第二種方案極端狀況下數據庫緩存不一樣步形成的影響。
這是否是說第一種方案徹底不能夠用勒，也不是，在保證雙寫串行化的狀況下，咱們也可以使用第一種方案，但這種方式會犧牲必定的性能，如經過內存隊列的形式。好比：
讀請求沒讀到緩存就往內存隊列丟一個消息，去更新緩存，同時本身開始輪詢緩存。針對寫請求，也把數據庫更新的操做發送到隊列裏面去。而後後臺線程輪詢獲取內存隊列元素，消費信息。用內存隊列的方式將更新緩存和刪除緩存的操做給串行化起來。這裏能夠優化的是
- 第一: 後臺內存隊列能夠多個，經過業務IdHash分發到不一樣的內存隊列當中，只須要保證同一業務id的雙寫是串行化的就行。
- 第二：爲了不無心義的緩存更新消息連續，能夠維護一個map，鍵爲產品id，值爲一個Boolean值，boolean值標記的是否須要將更新緩存操做推到對隊列中（當消費刪緩存消息置爲ture，當消費寫緩存消息置爲false）。但這裏須要慎重，根據業務量來，若是有100萬條數據，這個map的大小會佔用到15MB。
另外也能夠粗暴的加鎖，對讀和寫加鎖串行化，方案實現起來較簡單一點。
若是引入了讀寫分離
可是若是引入了讀寫分離怎麼辦勒，因爲主從同步延遲，若是採起上面的兩種方案，在極端狀況下，有可能致使讀請求寫入緩存中的多是舊數據。這裏根據網上的資料紙上談兵分析一下，若是嚴格要求這種狀況下也要保住緩存數據庫一致性的話，只有經過引入阿里的canel組件，實現針對從庫binlog日誌的消費邏輯，等到從庫更新以後再去刪除緩存了。總結一下，在讀寫分離的狀況下，直接使用上面的方案二就可。但若是引入了讀寫分離，能夠採用上面所述的根據從庫的Binlog日誌來異步更新緩存，但沒有具體實操，可能代價有點大，若是沒有嚴格要求緩存數據庫一致性，我的以爲能夠不採用，實在不行直接放棄