敢說你沒遇到過,主從數(shù)據(jù)庫(kù)不一致?

昨天聊了《數(shù)據(jù)庫(kù)與緩存一致性問題》，今天聊聊數(shù)據(jù)庫(kù)主庫(kù)與從庫(kù)的一致性問題。?問：常見的數(shù)據(jù)庫(kù)集群架構(gòu)如何？一主多從，主從同步，讀寫分離。如上圖：（1）一個(gè)主庫(kù)提供寫服務(wù)；（2）多個(gè)從庫(kù)提供讀服務(wù)，可以增加從庫(kù)提升讀性能；（3）主從之間同步數(shù)據(jù)；畫外音：任何方案不要忘了本心，加從庫(kù)的本心，是提升讀性能。
問：為什么會(huì)出現(xiàn)不一致？主從同步有時(shí)延，這個(gè)時(shí)延期間讀從庫(kù)，可能讀到不一致的數(shù)據(jù)。如上圖：（1）服務(wù)發(fā)起了一個(gè)寫請(qǐng)求；（2）服務(wù)又發(fā)起了一個(gè)讀請(qǐng)求，此時(shí)同步未完成，讀到一個(gè)不一致的臟數(shù)據(jù)；（3）數(shù)據(jù)庫(kù)主從同步最后才完成；畫外音：任何數(shù)據(jù)冗余，必將引發(fā)一致性問題。?問：如何避免這種主從延時(shí)導(dǎo)致的不一致？常見的方法有這么幾種。?方案一：忽略。任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓，絕大部分業(yè)務(wù)，例如：百度搜索，淘寶訂單，QQ消息，58帖子都允許短時(shí)間不一致。畫外音：如果業(yè)務(wù)能接受，最推崇此法。
如果業(yè)務(wù)能夠接受，別把系統(tǒng)架構(gòu)搞得太復(fù)雜。?方案二：強(qiáng)制讀主。如上圖：（1）使用一個(gè)高可用主庫(kù)提供數(shù)據(jù)庫(kù)服務(wù)；（2）讀和寫都落到主庫(kù)上；（3）采用緩存來提升系統(tǒng)讀性能；這是很常見的微服務(wù)架構(gòu)，可以避免數(shù)據(jù)庫(kù)主從一致性問題。?方案三：選擇性讀主。強(qiáng)制讀主過于粗暴，畢竟只有少量寫請(qǐng)求，很短時(shí)間，可能讀取到臟數(shù)據(jù)。
有沒有可能實(shí)現(xiàn)，只有這一段時(shí)間，可能讀到從庫(kù)臟數(shù)據(jù)的讀請(qǐng)求讀主，平時(shí)讀從呢？?可以利用一個(gè)緩存記錄必須讀主的數(shù)據(jù)。如上圖，當(dāng)寫請(qǐng)求發(fā)生時(shí)：（1）寫主庫(kù)；（2）將哪個(gè)庫(kù)，哪個(gè)表，哪個(gè)主鍵三個(gè)信息拼裝一個(gè)key設(shè)置到cache里，這條記錄的超時(shí)時(shí)間，設(shè)置為“主從同步時(shí)延”；畫外音：key的格式為“db:table:PK”，假設(shè)主從延時(shí)為1s，這個(gè)key的cache超時(shí)時(shí)間也為1s。?如上圖，當(dāng)讀請(qǐng)求發(fā)生時(shí)：這是要讀哪個(gè)庫(kù)，哪個(gè)表，哪個(gè)主鍵的數(shù)據(jù)呢，也將這三個(gè)信息拼裝一個(gè)key，到cache里去查詢，如果，（1）cache里有這個(gè)key，說明1s內(nèi)剛發(fā)生過寫請(qǐng)求，數(shù)據(jù)庫(kù)主從同步可能還沒有完成，此時(shí)就應(yīng)該去主庫(kù)查詢；（2）cache里沒有這個(gè)key，說明最近沒有發(fā)生過寫請(qǐng)求，此時(shí)就可以去從庫(kù)查詢；以此，保證讀到的一定不是不一致的臟數(shù)據(jù)。?總結(jié)數(shù)據(jù)庫(kù)主庫(kù)和從庫(kù)不一致，常見有這么幾種優(yōu)化方案：（1）業(yè)務(wù)可以接受，系統(tǒng)不優(yōu)化；（2）強(qiáng)制讀主，高可用主庫(kù)，用緩存提高讀性能；（3）在cache里記錄哪些記錄發(fā)生過寫請(qǐng)求，來路由讀主還是讀從；?文字很短，希望能給大家一些啟示。架構(gòu)師之路-分享可落地的技術(shù)文章相關(guān)文章：《架構(gòu)師之路，20年干貨精選》
有更好的方案，歡迎交流，謝轉(zhuǎn)。