在高并發(fā)的業(yè)務(wù)場景下，數(shù)據(jù)庫的性能瓶頸往往都是用戶并發(fā)訪問過大。所以，一般都使用redis做一個緩沖操作，讓請求先訪問到redis，而不是直接去訪問MySQL等數(shù)據(jù)庫。從而減少網(wǎng)絡(luò)請求的延遲響應(yīng)
數(shù)據(jù)為什么會不一致這樣的問題主要是在并發(fā)讀寫訪問的時候，緩存和數(shù)據(jù)相互交叉執(zhí)行。
一、單庫情況下
同一時刻發(fā)生了并發(fā)讀寫請求，例如為A(寫) B (讀)2個請求
A請求發(fā)送一個寫操作到服務(wù)端，第一步會淘汰cache，然后因為各種原因卡主了，不在執(zhí)行后面業(yè)務(wù)(例：大量的業(yè)務(wù)操作、調(diào)用其他服務(wù)處理消耗了1s）。
B請求發(fā)送一個讀操作，讀cache，因為cache淘汰，所以為空
B請求繼續(xù)讀DB，讀出一個臟數(shù)據(jù)，并寫入cache
A請求終于執(zhí)行完全，在寫入數(shù)據(jù)到DB
總結(jié)：因最后才把寫操作數(shù)據(jù)入DB，并沒同步。cache里面一直保持臟數(shù)據(jù)
臟數(shù)據(jù)是指源系統(tǒng)中的數(shù)據(jù)不在給定的范圍內(nèi)或?qū)τ趯嶋H業(yè)務(wù)毫無意義，或是數(shù)據(jù)格式非法，以及在源系統(tǒng)中存在不規(guī)范的編碼和含糊的業(yè)務(wù)邏輯。
二、主從同步，讀寫分離的情況下，讀從庫而產(chǎn)生臟數(shù)據(jù)
A請求發(fā)送一個寫操作到服務(wù)端，第一步會淘汰cache
A請求寫主數(shù)據(jù)庫，寫了最新的數(shù)據(jù)。
B請求發(fā)送一個讀操作，讀cache，因為cache淘汰，所以為空
B請求繼續(xù)讀DB，讀的是從庫，此時主從同步還沒同步成功。讀出臟數(shù)據(jù)，然后臟數(shù)據(jù)入cache
最后數(shù)據(jù)庫主從同步完成
總結(jié)：這種情況下請求A和請求B操作時序沒問題，是主從同步的時延問題(假設(shè)1s)，導(dǎo)致讀請求讀取從庫讀到臟數(shù)據(jù)導(dǎo)致的不一致
根本原因:
單庫下，邏輯處理中消耗1s?？赡茏x到舊數(shù)據(jù)入緩存
主從+讀寫分離，在1s的主從同步時延中。讀到從庫的舊數(shù)據(jù)入緩存
數(shù)據(jù)優(yōu)化方案一、緩存雙淘汰法
先淘汰緩存
再寫數(shù)據(jù)庫
往消息總線esb發(fā)送一個淘汰消息，發(fā)送立即返回。寫請求的處理時間幾乎沒有增加，這個方法淘汰了緩存兩次。因此被稱為“緩存雙淘汰法“，而在消息總線下游，有一個異步淘汰緩存的消費者，在拿到淘汰消息在1s后淘汰緩存，這樣，即使在一秒內(nèi)有臟數(shù)據(jù)入緩存，也能夠被淘汰掉。
二、異步淘汰緩存
上述的步驟，都是在業(yè)務(wù)線里面執(zhí)行，新增一個線下的讀取binlog異步淘汰緩存模塊，讀取binlog總的數(shù)據(jù)，然后進行異步淘汰。
1.思路：
MySQL binlog增量發(fā)布訂閱消費+消息隊列+增量數(shù)據(jù)更新到redis
1）讀請求走Redis：熱數(shù)據(jù)基本都在Redis
2）寫請求走MySQL: 增刪改都操作MySQL
3）更新Redis數(shù)據(jù)：MySQ的數(shù)據(jù)操作binlog，來更新到Redis
2.Redis更新
1）數(shù)據(jù)操作主要分為兩塊：
一個是全量(將全部數(shù)據(jù)一次寫入到redis)
一個是增量（實時更新）
這里說的是增量,指的是mysql的update、insert、delate變更數(shù)據(jù)。
這樣一旦MySQL中產(chǎn)生了新的寫入、更新、刪除等操作，就可以把binlog相關(guān)的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對Redis進行更新。就無需在從業(yè)務(wù)線去操作緩存內(nèi)容
如有感悟，歡迎關(guān)注和交流探討額
