分佈式一致性解決分佈式一致性問題用二階段提交一個沒有高可用組件的數據庫不能依靠外部軟件來實現高可用

聊聊分佈式數據庫的那些事兒|InfoQ大咖說

https://v.qq.com/x/page/r03631pv2j3.html

 

 

數據庫須要支持事務，事務須要ACID
分佈式數據庫不必定須要支持事務，因此不必定支持ACID，只是提出了一個理論CAP，目前業界包括TiDB都廣泛支持C和P，分佈式數據庫是比較新的技術，目前業界尚未相應標準，好比TPCC性能壓測都是隻針對單機數據庫

分佈式數據庫裏的A和P沒什麼好說的，能夠討論的是C，一致性

單機一致性：寫入一條數據，再讀出的時候，能不能讀出剛纔寫入的最新那條數據

分佈式一致性：
一、強一致性 二、最終一致性
強一致性 ：TiDB支持強一致性，各個副本都是同步模式
最終一致性： 阿里的DRDS是最終一致性

解決分佈式一致性問題，用二階段提交，two-phase commit
隊列或者其餘技術自己都解決不了問題，只有兩階段提交是目前主流數據庫採用的方案，包括SQL Server，PGSQL
兩階段提交須要用分佈式事務管理器來拒絕單點

 

一個沒有高可用組件的數據庫，不能依靠外部軟件來實現高可用，比較MySQL主從依靠zookeeper來作故障切換
可是zookeeper只能知道master掛了，可是不知道主從數據是否一致！
本質上沒法解決問題

例如packmaker+corosync 作SQL Server的主從切換，SQL Server只能用共享存儲，不然也是沒法知道主從數據是否一致

 

tidb（AP和TP之間要作資源隔離，硬件級隔離）
https://cloud.tencent.com/developer/article/1496742
https://mp.weixin.qq.com/s/laRHOlCqtMnse2cA4lSlDw
這一套架構雖然很方便，可是一樣也存在一些問題，最顯而易見的就是AP和TP互相干擾，這在初期是HTAP系統沒法避免的問題。在18年的時候TiDB就提出了TiFlash的項目

f