一、雙主保證高可用
mysql資料庫集群常使用一主多從，主從同步，讀寫分離的方式來擴充資料庫的讀效能，保證讀庫的高可用，但此時寫庫仍然是單點。
在乙個mysql資料庫集群中可以設定兩個主庫，並設定雙向同步，以冗餘寫庫的方式來保證寫庫的高可用。
二、併發引發不一致
資料冗餘會引發資料的一致性問題，因為資料的同步有乙個時間差，併發的寫入可能導致資料同步失敗，引起資料丟失：
如上圖所述，假設主庫使用了auto increment來作為自增主鍵：
三、相同步長免衝突
能否保證兩個主庫生成的主鍵一定不衝突呢？
回答：
就能夠做到。
如上圖所示：
如上圖所示，兩個主庫最終都將包含1/2/3/4/5/6/7/8所有資料，即使有乙個主庫掛了，另乙個主庫也能夠保證寫庫的高可用。
四、上游生成id避衝突
換乙個思路，為何要依賴於資料庫的自增id，來保證資料的一致性呢？
完全可以由業務上游，使用統一的id生成器，來保證id的生成不衝突：
如上圖所示，呼叫方插入資料時，帶入全域性唯一id，而不依賴於資料庫的auto increment，也能解決這個問題。
至於如何生成全域性唯一，趨勢遞增的id，參見文章《分布式id生成演算法》。
五、消除雙寫不治本
使用auto increment兩個主庫併發寫可能導致資料不一致，只使用乙個主庫提供服務，另乙個主庫作為shadow-master，只用來保證高可用，能否避免一致性問題呢？
如上圖所示：
這個切換由於虛ip沒有變化，所以切換過程對呼叫方是透明的，但在極限的情況下，也可能引發資料的不一致：
如上圖所示：
六、內網dns探測
虛ip漂移，雙主同步延時導致的資料不一致，本質上，需要在雙主同步完資料之後，再實施虛ip偏移，使用內網dns探測，可以實現shadow master延時高可用：
七、總結
主庫高可用，主庫一致性，一些小技巧：
網際網路一致性架構設計 DB雙主一致性
網際網路一致性架構設計 db雙主一致性 mysql資料庫集群常使用一主多從，主從同步，讀寫分離的方式來擴充資料庫的讀效能，保證讀庫的高可用，但此時寫庫仍然是單點。解決方法 在乙個mysql資料庫集群中可以設定兩個主庫，並設定雙向同步，以冗餘寫庫的方式來保證寫庫的高可用。需求分析 資料冗餘會引發資料的...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
redis 雙寫一致性
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。於...