分布式數據庫的設計遵循CAP理論，即一個分布式系統不能同時滿足Consistency（一致性）、Availability（可用性）和Partition Tolerance（分區容忍性）這三個基本需求。
一致性指的是更新操作成功并返回客戶端后，分布式集群中每個節點都返回相同的、最新的數據。
對于一致性，可以從客戶端和服務端兩個不同的視角來看：
從客戶端來看，一致性主要指的是多并發訪問時更新過的數據如何獲取的問題；
從服務端來看，則是更新如何復制到整個分布式系統，以保證數據的最終一致性。
在多進程并發訪問時，根據獲取更新過的數據的不同策略，一致性又分為強一致性、弱一致性和最終一致性。
對于關系型數據庫，要求更新過的數據能被后續的訪問都能看到，這是強一致性。
如果能容忍后續的部分或者全部訪問不到，則是弱一致性。
如果經過一段時間后要求能訪問到更新后的數據，則是最終一致性。
可用性指的是系統服務一直可用，在合理的時間內返回讀寫請求的響應。
對于一個可用的分布式系統，衡量系統可用性的時候，一般通過停機時間來計算的。
通常說金融核心業務系統的可用性水平達到5個9，即全年停機時間不超過 (1-0.99999) * 365 * 24 * 60 = 5.256 min，這是一個極高的要求。
分布式數據庫原理？分區容忍性指的是分布式系統在網絡分區出現故障時，仍然能夠對外提供滿足一致性和可用性的服務。
在分布式數據庫系統中，分區容忍性和擴展性緊密關聯，一個好的分區容忍性能夠保證當其中幾臺機器故障或者網絡異常后，能夠快速的進行故障隔離不影響其它機器的正常運行；也能夠保證系統擴展性，節點的新增和刪除做到對業務無感知。
根據CAP理論，無法同時滿足一致性、可用性和分區容忍性。但是在分布式數據庫系統中，分區容忍性是必須的，分區是始終會存在的，因此需要在一致性和可用性之間進行權衡。
CP without A：分布式系統容許系統停機或者長時間無響應，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之后再讓用戶訪問系統。傳統的分布式數據庫事務都屬于這種模式，對于金融行業的分布式數據庫產品而言，優先保證數據的一致性。
AP without C：分布式系統中允許數據不一致，一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。現在眾多的NoSQL都屬于此類。
在實際的分布式數據庫系統中，基于分片解決擴展性問題并可以實現負載均衡，當某個分片服務不可用時，只會影響部分業務，即服務降級。同時基于多副本構成集群架構，提升系統的高可用。
cap原理和分布式事務。ACID指的是數據庫系統中事務所具有的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。
原子性：一個事務中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
一致性：在事務開始之前和事務結束以后，數據庫的完整性限制沒有被破壞。
隔離性：當兩個或者多個事務并發訪問數據庫的同一數據時所表現出的相互關系。
分布式事務。持久性：在事務完成以后，該事務對數據庫所作的更改便持久地保存在數據庫之中，并且是完全的。
在分布式系統中，每一個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗，但卻無法直接獲取到其他分布式節點的操作結果。因此，當一個事務操作需要跨越多個分布式節點的時候，為了保持事務處理的ACID特性，就需要引入一個稱為"協調者"的組件來統一調度所有分布式節點的執行邏輯，這些被調度的分布式節點則被稱為"參與者"。協調者負責調度參與者的行為，并最終決定這些參與者是否要把事務真正進行提交。基于以上原則，分布式事務一致性算法主要包括2PC、3PC、Paxos和Raft。
二階段提交2PC是一致性協議算法，可以保證數據的強一致性，該算法能夠解決很多臨時性系統故障（包括進程、網絡節點、通信等故障），被廣泛地使用于關系型數據庫系統中。2PC協議中系統分為協調者和參與者，整個過程分為兩個階段：
階段1：請求階段
在請求階段，協調者將通知事務參與者準備提交或取消事務，然后進入表決過程。在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
階段2：提交階段
在該階段，協調者將基于第一個階段的投票結果進行決策：提交或取消。當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。參與者在接收到協調者發來的消息后將執行響應的操作。
需要層次理論、2PC協議的優點是原理簡單、實現方便，但也有以下缺點：
同步阻塞：在二階段提交的執行過程中，所有參與該事務操作的邏輯都處于阻塞狀態，也就是說，各個參與者在等待其他參與者響應的過程中，將無法進行其他任何操作。
單點問題：協調者的角色在整個二階段提交協議中起到了非常重要的作用。一旦協調者出現問題，那么整個二階段提交流程將無法運轉，更為嚴重的是，如果協調者是在階段二中出現問題的話，那么其他參與者將會一直處于鎖定事務資源的狀態中，而無法繼續完成事務操作。
數據不一致：在階段二時，當協調者向所有的參與者發送Commit請求之后，發生了局部網絡異常或者是協調者尚未發送完Commit請求之前自身發生了崩潰，導致最終只有部分參與者收到了Commit請求。于是，這部分收到了Commit請求的參與者就會進行事務的提交，而其他沒有收到Commit請求的參與者則無法進行事務提交，于是整個分布式系統便出現了數據不一致現象。
太過保守：二階段提交協議沒有設計較為完善的容錯機制，任何一個節點的失敗都會導致整個事務的失敗。
理論、3PC協議在協調者和參與者中都引入超時機制，并且把兩階段提交協議的第一個階段拆分成了兩步：詢問，然后再鎖資源，最后真正提交，包括CanCommit、PreCommit和doCommit三個階段。
1）CanCommit階段
3PC的CanCommit階段和2PC的準備階段很像。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
2）PreCommit階段
分布式？協調者根據參與者的反應情況來決定是否可以繼續事務的PreCommit操作。根據響應情況，有以下兩種可能。
3）DoCommit階段
該階段進行真正的事務提交，也可以分為以下兩種情況:
發送提交請求。協調者接收到參與者發送的ACK響應，那么他將從預提交狀態進入到提交狀態。并向所有參與者發送doCommit請求。
赫茨伯格雙因素理論？事務提交。參與者接收到doCommit請求之后，執行正式的事務提交。并在完成事務提交之后釋放所有事務資源。
響應反饋。事務提交完之后，向協調者發送ACK響應。
完成事務。協調者接收到所有參與者的ACK響應之后，完成事務。
3PC協議降低了參與者阻塞范圍，并能夠在出現單點故障后繼續達成一致。缺點是引入 preCommit階段，在這個階段如果出現網絡分區，協調者無法與參與者正常通信，參與者依然會進行事務提交，造成數據不一致。
分布式數據庫原理及應用、2PC/3PC用于保證多個數據分片上操作的原子性，這些數據分片可能存在于不同的服務器上，2PC/3PC保證這些操作要么全部成功，要么全部失敗。Paxos和Raft則是用于保證同一個數據分片的多個數據副本之間的數據一致性。
Paxos算法屬于多數派算法，主要解決數據分片的單點問題，目的是讓整個集群對某個值的變更達成一致。集群中的任何一個節點都可以提出要修改某個數據的提案，是否通過這個提案取決于這個集群中是否有超過半數的節點同意，所以Paxos算法建議集群中的節點為奇數。
Raft算法是簡化版的Paxos， Raft劃分成三個子問題：一是Leader Election；二是Log Replication；三是Safety。Raft 定義了三種角色Leader、Follower、Candidate，最開始大家都是Follower，當Follower監聽不到Leader，就可以自己成為Candidate，發起投票，選出新的leader。
1PC協議階段就是從應用程序向數據庫發出提交請求到數據庫完成提交或回滾之后，將結果返回給應用程序的過程。一階段提交不需要“協調者”角色，各結點之間不存在協調操作，因此其事務執行時間比兩階段提交要短，但是提交的“危險期”是每一個事務的實際提交時間，相比于兩階段提交，一階段提交出現在“不一致”的概率就變大了。
分布式和集群，在分布式系統中如果存在跨分片的分布式事務，1PC提交并不能保證數據的一致性。像GoldenDB分布式數據庫就是通過1PC協議+全局活躍事務ID（GTID）來實現分布式事務。
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
