mysql如何保證一致性
事務的產生,其實是為了當應用程式訪問資料庫的時候,事務能夠簡化我們的程式設計模型,不需要我們去考慮各種各樣的潛在錯誤和併發問題.可以想一下當我們使用事務時,要麼提交,要麼回滾,我們不會去考慮網路異常了,伺服器宕機了,同時更改乙個資料怎麼辦對吧?因此事務本質上是為了應用層服務的.而不是伴隨著資料庫系統天生就有的。
acid裡的aid都是資料庫的特徵,也就是依賴資料庫的具體實現.而唯獨這個c,實際上它依賴於應用層,也就是依賴於開發者.這裡的一致性是指系統從乙個正確的狀態,遷移到另乙個正確的狀態.什麼叫正確的狀態呢?就是當前的狀態滿足預定的約束就叫做正確的狀態.而事務具備acid裡c的特性是說通過事務的aid來保證我們的一致性.
一致性就是:應用系統從乙個正確的狀態到另乙個正確的狀態.而acid就是說事務能夠通過aid來保證這個c的過程.c是目的,aid都是手段
以上 from
事務的四個屬性：acid
1.原子性(automic)：乙個動作要麼做完，要麼不做。
2.一致性(consistency)：保證資料處於一致性的狀態，我理解就是保證資料有意義的。
3.隔離性(isolation)：多個事務並行的結果，應該和多個事務序列的結果一致。
4.永續性(duration)：乙個事務一旦成功提交，對資料改變是永久性的。
這個四個屬性中，最重要的是一致性，也就是說其他的三個屬性都是為了保證一致性而存在。
在使用mysql的時候，有兩種常用的儲存引擎：myisam和innodb
innodb的效能不如myisam高，因為innodb提供事務支援以及外部鍵等高階資料庫功能
事務有什麼用？
銀行轉賬，a轉給b賬戶100元，需要保證a賬戶減少100元的同時b賬戶增加100元，如果a賬戶減少100元之後，系統crash，b賬戶並未增加100元，這樣是沒有資料保證一致性的。所以，如果兩個動作是同乙個事務，那麼此時a操作需要回滾，保證資料一致性。
如何回滾？
原子性如何保證？
這個就需要說到mysql的log，mysql有許多種類的log，例如：二進位制日誌(binlog)，錯誤日誌，慢查詢日誌等等。這裡需要引入的是undo log。這是mysql的write-ahead-logging機制。
例如：資料庫中a=1，現在需要update a=3
那麼整個步驟如下：
1.事務開始
2.記錄a=1到undo log
3.修改a=3
4.將undo log寫入磁碟
5.將a=3資料寫入磁碟
6.事務提交
但是，這樣每個操作都會進行磁碟io的寫入，頻繁的磁碟io對效能是很大的降低。
引入redo log實現永續性，這個時候就在考慮如果只需要將日誌寫入磁碟，將資料快取在記憶體中，一定時間後再進行更新。
例如：資料庫中a=1,b=2,需要update a=3,b=4
1.事務開始
2.記錄a=1到undo log
3.修改a=3
4.記錄a=3到redo log
5.記錄b=2到undo log
6.修改b=4
7.記錄b=4到redo log
8.將redo log順序寫入磁碟
9.事務提交
如果整個事務執行的過程系統崩潰或者斷電了，在系統重啟的時候，恢復機制會將redo log中已提交的事務重做，保證事務的永續性；而undo log中未提交的事務進行回滾，保證事務的原子性。
mysql通過預寫式日誌，保證了原子性和永續性。那麼在多個事務並行的情況下，是否還能保證資料的一致性？如果a事務能夠訪問b事務正在提交的資料，然後b事務又做出了回滾，這樣是不是就讓資料亂套了。所以事務並行的情況下，這樣是不夠的。
隔離性：引入鎖機制來保證。那麼是什麼情況下不鎖，什麼情況下鎖呢？還有讀寫分離需要實現嗎？這就需要去說說四種級別的隔離性。
1.未提交讀：a事務可以讀取b事務正在修改的資料，但是會出現b事務如果回滾，這樣資料前後不一致，會造成髒讀的現象。
2.已提交讀：a事務只能讀取b事務已提交的資料。b事務修改資料，a事務進行讀取，資料未改，當b事務提交資料後，a事務讀取資料不一致。這是幻讀現象，因為同乙個事務，我讀取兩次相同的資料返回的是不同的，這樣並未保證一致性。
3.可重複讀：利用mvcc併發版本控制，b事務修改資料，a事務進行讀取，資料未改，當b事務提交後，a事務讀取資料，這個時候會返回a資料之前讀的版本。
4.序列化：簡單粗暴，讀鎖和寫鎖都是排它鎖，不管讀操作還是寫操作都是會對資料上鎖。這樣粗暴造成效能下降很多。
大多數資料庫預設使用已提交讀的隔離級別，mysql中innodb預設使用可重複讀的隔離級別。
總結
mysql的innodb保證事務性，最重要是保證資料的一致性。
通過預寫式日誌，undo log保證原子性，redo log保證永續性，設定隔離級別，保證併發事務進行的時候，保證資料一致性。
保證一致性嗎 Kafka的一致性保證
魚和熊掌不可兼得。系統設計需要根據具體的應用場景做出權衡。系統設計者可以通過配置kafka，來得到不同程度的需求滿足。每個kafka主題 topic 都分為多個分割槽 partitions 每個分割槽可以具有多個副本 replica 其中乙個副本是主分割槽 leader 所有讀寫請求都由主分割槽提供...
如何保證Session一致性
session同步法 多台web server互相同步資料，缺點是水平擴充套件受限，因為每台web server都是儲存所有的session 客戶端儲存法 session儲存到瀏覽器cookie中，每個客戶端只要儲存乙個使用者的資料了。缺點是占用外網頻寬 大小受限 因為cookie有大小限制 反向 ...
dubbo如何保證事務一致性
目前比較多的解決方案有幾個 一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決方案 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 t...