主機與備機之間的物理延遲是不可控的，也是無法避免的。但是如果僅僅需要滿足這種強一致性，是相對簡單的事：只需要在主機寫入時，確認更新已經同步到備機之後，再返回寫操作成功即可。主流資料庫均支援這種完全的同步模式。已經有人提到mysql的semi-sync功能（從mysql5.6開始官方支援，此前的版本可以考慮google出的非官方補丁），就是基於這種原理。
不過，一般不建議使用這種同步模式。顯而易見，如果寫操作必須等待更新同步完成，肯定會極大地影響效能，除非你不在乎效能。
問題的關鍵在於，主從架構是一種用於資料容錯的高可用性解決方案，而不是一種處理高併發壓力的解決方案。它的目的是主機當機以後備機可以馬上頂上，而不是讓備機來分擔併發壓力。完全同步機制也只是用於保證主機當機以後資料不會丟失，而不是保證從備機讀取資料時的一致性。因此，我根本也不主張你使用從備機讀取資料以分擔併發壓力這種方式。
解決方式是，不要試圖在資料庫層解決併發的讀操作問題，至少不要在主從架構的資料庫層解決。要在資料庫層之上架構乙個redis這樣的分布式快取來解決，它是專門幹這個的。其效能肯定遠高於從備機讀取資料。
分布式快取也存在著一些限制，例如不能完全支援事務處理。這取決於你的應用場景。對於一般的網際網路應用，併發壓力大但不要求支援事務，可以考慮分布式快取。對於銀行這樣嚴格要求強一致性的應用，對於寫入延遲一般沒什麼要求（延遲幾個小時都可以接受，資料不出錯就行），可以適用完全同步的模式。
另外，不建議你使用「通過版本庫判斷最新版本再分別路由到主機或備機」的山寨版解決方案。這會對應用層的**造成嚴重汙染。
解決主從資料庫同步延遲問題
場景 需要在主機寫入之後，保證在備機一定能夠讀取到已經寫入的資料，也就是需要主從架構下的強一致性。主機與備機之間的物理延遲是不可控的，也是無法避免的。但是如果僅僅需要滿足這種強一致性，是相對簡單的事情 只需要在主機寫入時，確認更新已經同步到備機之後，再返回寫操作成功即可。主從資料庫支援這種完全的同步...
100 解決Mysql主從同步延遲問題
強制讀主過於粗暴，畢竟只有少量寫請求，很短時間，可能讀取到髒資料。有沒有可能實現，只有這一段時間，可能讀到從庫髒資料的讀請求讀主，平時讀從呢？可以利用乙個快取記錄必須讀主的資料。如上圖，當寫請求發生時 1 寫主庫 2 將哪個庫，哪個表，哪個主鍵三個資訊拼裝乙個key設定到cache裡，這條記錄的超時...
主從資料庫 主從同步理論
主從資料庫資料同步原理 mysql的 replication 是乙個非同步的複製過程，從乙個 mysql instace 我們稱之為 主庫 複製到另乙個 mysqlinstance 我們稱之 從庫 在 主庫 與 從庫 之間的實現整個複製過程主要由三個執行緒來完成，其中兩個執行緒 sql執行緒和io執...