redis 資料庫主從不一致問題解決方案
在聊資料庫與快取一致性問題之前，先聊聊資料庫主庫與從庫的一致性問題。
問：常見的資料庫集群架構如何？
答：一主多從，主從同步，讀寫分離。
如上圖：
（1）乙個主庫提供寫服務
（2）多個從庫提供讀服務，可以增加從庫提公升讀效能
（3）主從之間同步資料
畫外音：任何方案不要忘了本心，加從庫的本心，是提公升讀效能。
問：為什麼會出現不一致？
答：主從同步有時延，這個時延期間讀從庫，可能讀到不一致的資料。
如上圖：
（1）服務發起了乙個寫請求
（2）服務又發起了乙個讀請求，此時同步未完成，讀到乙個不一致的髒資料
（3）資料庫主從同步最後才完成
畫外音：任何資料冗餘，必將引發一致性問題。
問：如何避免這種主從延時導致的不一致？
答：常見的方法有這麼幾種。
方案一：忽略
畫外音：如果業務能接受，最推崇此法。
如果業務能夠接受，別把系統架構搞得太複雜。
方案二：強制讀主
如上圖：
（1）使用乙個高可用主庫提供資料庫服務
（2）讀和寫都落到主庫上
（3）採用快取來提公升系統讀效能
這是很常見的微服務架構，可以避免資料庫主從一致性問題。
方案三：選擇性讀主
強制讀主過於粗暴，畢竟只有少量寫請求，很短時間，可能讀取到髒資料。
有沒有可能實現，只有這一段時間，可能讀到從庫髒資料的讀請求讀主，平時讀從呢？
可以利用乙個快取記錄必須讀主的資料。
如上圖，當寫請求發生時：
（1）寫主庫
（2）將哪個庫，哪個表，哪個主鍵三個資訊拼裝乙個key設定到cache裡，這條記錄的超時時間，設定為「主從同步時延」
畫外音：key的格式為「db:table:pk」，假設主從延時為1s，這個key的cache超時時間也為1s。
如上圖，當讀請求發生時：
這是要讀哪個庫，哪個表，哪個主鍵的資料呢，也將這三個資訊拼裝乙個key，到cache裡去查詢，如果，
（1）cache裡有這個key，說明1s內剛發生過寫請求，資料庫主從同步可能還沒有完成，此時就應該去主庫查詢
（2）cache裡沒有這個key，說明最近沒有發生過寫請求，此時就可以去從庫查詢
以此，保證讀到的一定不是不一致的髒資料。
總結資料庫主庫和從庫不一致，常見有這麼幾種優化方案：
（1）業務可以接受，系統不優化
（2）強制讀主，高可用主庫，用快取提高讀效能
（3）在cache裡記錄哪些記錄發生過寫請求，來路由讀主還是讀從
mysql replace的主從不一致
問題 資料庫遷移後,執行語句 load data local infile s replace into table s s 會出現 duplicate entry 的問題 但是在binlog只產生一條update語句。從庫的auto increment不會 1。詳細了解下 一。準備知識 inser...
MYSQL主從不一致的原因
2011 05 06 15 50 36 分類 mysql 標籤 mysql 主從不一致 字型大小大中小訂閱 轉至 基本上用了mysql作為oltp業務的，基本上都會配置mysql的主從，一方面用mysql的主從做資料庫的讀寫分離，另一方面mysql本身的單機備份不是很強，一般採用主從架構，在從上進行...
主從資料庫不一致如何解決
場景描述，對於主從庫，讀寫分離，如果主從庫更新同步有時差，就會導致主從資料的不一致 1 忽略這個資料不一致，在資料一致性要求不高的業務下，未必需要時實一致性 2 強制讀主庫，使用乙個高可用的主庫，資料庫讀寫都在主庫，新增乙個快取，提公升資料讀取的效能 3 選擇性讀主庫，新增乙個快取，用來記錄必須讀主...