之前一篇文章討論了redis原生如何保證主從一致。
這是redis為我們提供的方法，但是初次之外我們還可以使用一些工具來增強一致性
不一致性的根本原因是主從同步需要一定的時間，如果此時有讀操作落在從伺服器上就會造成不一致的情況。那解決這個問題最簡單的思路就是使用半同步複製。
半同步複製就是，如果有乙個寫操作落在主伺服器上，那麼這個操作必須要等待主從同步完成之後才能返回。這個方法用一種類似於鎖的機制，增強一致性，但缺點就是寫操作的耗時會加大，降低吞吐量
所有資料庫請求都會落在中介軟體上，然後由中介軟體進行路由到伺服器上。如果乙個寫操作到達，那麼中介軟體會將其路由到主伺服器上，同時記錄這次寫操作，並設定乙個時間，這個時間的設定要以系統完成主從同步的平均時間作為參考，比如說系統主從同步完成時間平均是300ms，那麼這個時間設為350ms，在這個時間視窗內，如果有對應的查詢操作到達中介軟體，那麼就會把這次查詢操作路由到主伺服器中，這樣接近到達強一致性。
優點：一致性很強
缺點：引入了資料庫中介軟體，成本較高，而且無法完全達到讀寫分離的目的，增大主伺服器壓力
資料庫中介軟體的成本較高，使用快取可以降低成本，思路也差不多。
當寫操作落在主伺服器上，此時要在快取中設定對應的key，並且同樣根據主從同步平均事件設定乙個合適的過期時間，讀操作會先落在快取上，如果快取命中了，讀操作就去主伺服器上進行，否則，就繼續讀寫分離，落在從伺服器上
Mysql 如何保證主從資料一致
要知道，mysql 的主從使用的是 binlog 那樣簡單的 日誌傳輸方式，來完成從庫對主庫的複製，雖然提高了效率，但是主庫和從庫之間並沒有 raft 那樣的協議來保證 主從一致。有時候主庫宕機，但是 binlog 還沒有發出去，如果直接將從庫切換為主庫，那麼將會主備不一致。並且從庫是單純告訴主庫，...
DB主從一致性架構優化幾種方法
大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。這種架構的乙個潛在缺點是，業務方有可能讀取到並不是最新的舊資料 1 系統先對db master進行了乙個寫操作，寫主庫 2 很短的時...
DB主從一致性架構優化4種方法
需求緣起 大部分網際網路的業務都是 讀多寫少 的場景，資料庫層面，讀效能往往成為瓶頸。如下圖 業界通常採用 一主多從，讀寫分離，冗餘多個讀庫 的資料庫架構來提公升資料庫的讀效能。系統先對 db master 進行了乙個寫操作，寫主庫 2 很短的時間內併發進行了乙個讀操作，讀從庫，此時主從同步沒有完成...