首先我們要知道 mysql 的預寫日誌 wtite ahead log (wal)機制，在mysql中redo日誌相當於wal，即客戶端操作命令先寫入 redo 日誌，然後再寫入記憶體緩衝區，返回客戶端， 最後再由作業系統寫入硬碟。這樣的好處是能保證事物。
當寫入 redo 日誌時伺服器宕機，重啟伺服器時，則mysql會執行redo日誌，這樣就會保質和客戶端得到的返回結果一致。
當然還有undo日誌，事物回滾時使用。當重啟伺服器時，發現
當然高可用是由 binlog 實現的，那麼binlog和事物日誌的順序是怎麼樣的呢
下面來看 mysql 各種日誌的順序
undo日誌（記錄事物未執行之前資料庫值）
將多個事物操作語句按順序寫入redo
biglog日誌 （整個一次寫入，所以當開啟binlog時會對效能有點影響）
事物commit
返回使用者
其中在mysql 5.5之前，寫入binlog之後是非同步寫入 mysql 從機的，那麼這時候如果主庫宕機，binlog還未寫入從庫，就會造成主從資料不一致。這時候如果要將從庫公升級為主庫，則需要恢復主庫後，使用pt-table-checksum等一致性檢測工具檢測主從一致性，並使用pt-table-sync恢復一致性
為了解決這個問題，mysql5.5後增加了半同步複製，binlog寫入後，會同步等待從庫返回，從庫返滬後才返回給使用者。
但 mongodb 副本集 已經解決了 腦裂 問題（有待考證） 使用 bully共識演算法
raft協議也解決了腦裂問題 raft演算法
關於mongodb是如何解決一致性的可以參見這篇文章 mongodb丟資料問題
經驗 對於支付等系統，在使用mysql半同步複製時，超時請使用無限長，避免退化成非同步複製，當所有從庫都沒有響應時，就會提交失敗，這樣就避免了資料不一致的現象。
mysql 強一致性 Mysql高一致高可用方案
一句話總結 使用官方mysql innodb cluster集群方案實現mysql冗餘備份，無單點故障的高可用性。專案背景 1 對資料可用性要求高，要求多節點冗餘備份，mysql單點故障後可以切換到其他節點 2 對資料準確性要求高，對mysql寫資料時，需要強一致性備份，不能是非同步的備份 3 併發...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
一致性雜湊演算法分析
一致性雜湊演算法在1997年由麻省理工學院提出的一種分布式雜湊 dht 實現演算法，設計目標是為了解決網際網路中的熱點 hot spot 問題，初衷和carp十分類似。一致性雜湊修正了carp使用的簡 單雜湊演算法帶來的問題，使得分布式雜湊 dht 可以在p2p環境中真正得到應用。一致性hash演算...