這篇文章主要介紹“java分布式的CAP定理是什么”，在日常操作中，相信很多人在java分布式的CAP定理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”java分布式的CAP定理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
CAP定理又稱布魯爾定理，是計算機科學家 Eric brewer 提出的，是分布式系統領域的一個定理。若想設計一個分布式架構的系統，掌握這項定理不可或缺。
C是Consistency，也就是一致性，在CAP中的是強一致性。A是Availability ，可用性。P是Partition tolerance，分區容錯性。在分布式系統中三者不可兼得，只能選兩個。這就是CAP定理。例如你保證了一致性和分區容錯性就無法保證可用性。
這里的一致性是強一致性，強一致性的意思就是例如節點A更新了數據，節點B能同時更新，這樣客戶端在每次讀取獲得數據都是最近更新的。但是在定理中是忽略掉我們平日里的網絡延遲的?，F實情況網絡延遲在現在還是無法避免的，所以我們只能實現最終一致性，但是目標還是貼近強一致性，也就是盡力降低延時的時間。
可用性指的是非故障的節點需要在合理的時間返回合理的響應。合理的響應的意思也就是不能搞個報錯，不能是超時失敗。舉個例子比如說節點A更新了數據，同時要發布到節點B上，但是中間傳輸的電纜被挖掘機挖斷了，此時用戶去訪問節點B，此時節點B應該返回老的數據，而不應該報錯。這就是可用性。讓用戶感覺系統還是能用的。
分區容錯性，指的是當網絡分區了，系統還能正常的運行和響應。比如節點A和節點B無法通信，你要考慮這個時候系統如何應該。雖然網絡分區的概率低而且時間短但是這種情況是會發生的。所以理論上是犧牲C或者A，P是一定要達到的。
舉個例子，把P扔了。所以此時系統需要保證CA，然后此時發生了網絡分區，節點A和B無法通信了，此時客戶端想要往節點A寫入數據，但是因為此時無法同步數據至節點B。所以只有保證A不寫入因此才能保證一致性。那你不讓客戶端往A寫數據，你就只能報個錯返回給客戶端，說此時不能寫，那是不是違反了可用性了？
所以在分布式系統中P是一定要保證的。所以在分布式系統中是CP,AP這樣搭配的。
那CA呢？請注意，CAP所說的CAP三者只能存在兩者，所以CA是可以能搭配的。就是在系統沒有P的時候，CA搭配。也就是說當系統不存在分區情況的時候要滿足C和A，當系統出現分區情況的之后視情況拋棄C或者A。
CAP理論不是系統級別的，是數據級別的。啥意思呢？
也就是說當出現網絡分區的情況，你可以一部分數據遵守CP，一部分數據遵守AP。例如用戶注冊場景可以上CP，保證用戶注冊之后登錄的成功。而用戶更換頭像這種就上AP，畢竟用舊的數據影響也不會很大。
因此我們要根據不同的業務場景來選擇不同的應對方案。CAP是可以靈活搭配的。
到此，關于“java分布式的CAP定理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
