目錄
1、分布式系統當中的CAP理論
1.1、CAP理論
1.2、Partitiontolerance
1.3、Consistency
1.4、Availability
2、Kafka中的CAP機制
C++軟件異常排查從入門到精通系列教程(核心精品專欄,訂閱量已達600多個,歡迎訂閱,持續更新...)https://blog.csdn.net/chenlycly/article/details/125529931C/C++實戰專欄(重點專欄,專欄文章已更新500多篇,訂閱量已達數百個,歡迎訂閱,持續更新中...)
https://blog.csdn.net/chenlycly/article/details/140824370C++ 軟件開發從入門到實戰(重點專欄,專欄文章已更新280多篇,歡迎訂閱,持續更新中...)
https://blog.csdn.net/chenlycly/category_12695902.htmlVC++常用功能開發匯總(專欄文章列表,歡迎訂閱,持續更新...)
https://blog.csdn.net/chenlycly/article/details/124272585C++軟件分析工具從入門到精通案例集錦(專欄文章,持續更新中...)
https://blog.csdn.net/chenlycly/article/details/131405795開源組件及數據庫技術(專欄文章,持續更新中...)
https://blog.csdn.net/chenlycly/category_12458859.html網絡編程與網絡問題分享(專欄文章,持續更新中...)
https://blog.csdn.net/chenlycly/category_2276111.html
1、分布式系統當中的CAP理論
1.1、CAP理論
分布式系統(distributed system)正變得越來越重要,大型網站幾乎都是分布式的。
分布式系統的最大難點,就是各個節點的狀態如何同步。
為了解決各個節點之間的狀態同步問題,在1998年,由加州大學的計算機科學家EricBrewer提出分布式系統的三個指標,分別是:
- Consistency:一致性
- Availability:可用性
- Partitiontolerance:分區容錯性
EricBrewer說,這三個指標不可能同時做到。最多只能同時滿足其中兩個條件,這個結論就叫做CAP定理。
CAP理論是指:分布式系統中,一致性、可用性和分區容忍性最多只能同時滿足兩個。
一致性:Consistency
- 通過某個節點的寫操作結果對后面通過其它節點的讀操作可見。
- 如果更新數據后,并發訪問情況下后續讀操作可立即感知該更新,稱為強一致性
- 如果允許之后部分或者全部感知不到該更新,稱為弱一致性。
- 若在之后的一段時間(通常該時間不固定)后,一定可以感知到該更新,稱為最終一致性。
可用性:Availability
任何一個沒有發生故障的節點必須在有限的時間內返回合理的結果。
分區容錯性:Partitiontolerance
- 部分節點宕機或者無法與其它節點通信時,各分區間還可保持分布式系統的功能
- 一般而言,都要求保證分區容忍性。所以在CAP理論下,更多的是需要在可用性和一致性之間做權衡。
1.2、Partitiontolerance
先看Partitiontolerance,中文叫做"分區容錯"。
大多數分布式系統都分布在多個子網絡。每個子網絡就叫做一個區(partition)。分區容錯的意思是,區間通信可能失敗。比如,一臺服務器放在中國,另一臺服務器放在美國,這就是兩個區,它們之間可能無法通信。
上圖中,G1和G2是兩臺跨區的服務器。G1向G2發送一條消息,G2可能無法收到。系統設計的時候,必須考慮到這種情況。
一般來說,分區容錯無法避免,因此可以認為CAP的P總是存在的。即永遠可能存在分區容錯這個問題。
? ? ? ?在這里,給大家重點推薦一下我的幾個熱門暢銷專欄,歡迎訂閱:(博客主頁還有其他專欄,可以去查看)
專欄1:(該精品技術專欄的訂閱量已達到600多個,專欄中包含大量項目實戰分析案例,有很強的實戰參考價值,廣受好評!專欄文章已經更新到200篇以上,持續更新中!歡迎訂閱!)
C++軟件調試與異常排查從入門到精通系列文章匯總(專欄文章,持續更新中...)https://blog.csdn.net/chenlycly/article/details/125529931
本專欄根據多年C++軟件異常排查的項目實踐,系統地總結了引發C++軟件異常的常見原因以及排查C++軟件異常的常用思路與方法,詳細講述了C++軟件的調試方法與手段,以圖文并茂的方式給出具體的項目問題實戰分析實例(很有實戰參考價值),帶領大家逐步掌握C++軟件調試與異常排查的相關技術,適合基礎進階和想做技術提升的相關C++開發人員!
考察一個開發人員的水平,一是看其編碼及設計能力,二是要看其軟件調試能力!所以軟件調試能力(排查軟件異常的能力)很重要,必須重視起來!能解決一般人解決不了的問題,既能提升個人能力及價值,也能體現對團隊及公司的貢獻!
專欄中的文章都是通過項目實戰總結出來的,包含大量項目問題實戰分析案例,有很強的實戰參考價值!專欄文章還在持續更新中,預計文章篇數能更新到200篇以上!
專欄2:(本專欄涵蓋了C++多方面的內容,是當前重點打造的專欄,訂閱量已達300多個,專欄文章已經更新到500多篇,持續更新中!歡迎訂閱!)
C/C++實戰進階(專欄文章,持續更新中...)https://blog.csdn.net/chenlycly/category_11931267.html
以多年的開發實戰為基礎,總結并講解一些的C/C++基礎與項目實戰進階內容,以圖文并茂的方式對相關知識點進行詳細地展開與闡述!專欄涉及了C/C++領域多個方面的內容,包括C++基礎及編程要點(模版泛型編程、STL容器及算法函數的使用等)、數據結構與算法、C++11及以上新特性(不僅看開源代碼會用到,日常編碼中也會用到部分新特性,面試時也會涉及到)、常用C++開源庫的介紹與使用、代碼分享(調用系統API、使用開源庫)、常用編程技術(動態庫、多線程、多進程、數據庫及網絡編程等)、軟件UI編程(Win32/duilib/QT/MFC)、C++軟件調試技術(排查軟件異常的手段與方法、分析C++軟件異常的基礎知識、常用軟件分析工具使用、實戰問題分析案例等)、設計模式、網絡基礎知識與網絡問題分析進階內容等。
專欄3:??
C++常用軟件分析工具從入門到精通案例集錦匯總(專欄文章,持續更新中...)https://blog.csdn.net/chenlycly/article/details/131405795
常用的C++軟件輔助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等,本專欄詳細介紹如何使用這些工具去巧妙地分析和解決日常工作中遇到的問題,很有實戰參考價值!
專欄4:???
VC++常用功能開發匯總(專欄文章,持續更新中...)https://blog.csdn.net/chenlycly/article/details/124272585
將10多年C++開發實踐中常用的功能,以高質量的代碼展現出來。這些常用的高質量規范代碼,可以直接拿到項目中使用,能有效地解決軟件開發過程中遇到的問題。
專欄5:?(本專欄涵蓋了C++多方面的內容,是當前重點打造的專欄,專欄文章已經更新到300多篇,持續更新中!歡迎訂閱!)
C++ 軟件開發從入門到實戰(專欄文章,持續更新中...)https://blog.csdn.net/chenlycly/category_12695902.html
根據多年C++軟件開發實踐,詳細地總結了C/C++軟件開發相關技術實現細節,分享了大量的實戰案例,很有實戰參考價值。
1.3、Consistency
Consistency中文叫做"一致性"。意思是,寫操作之后的讀操作,必須返回該值。舉例來說,某條記錄是v0,用戶向G1發起一個寫操作,將其改為v1。接下來,用戶的讀操作就會得到v1。這就叫一致性。
問題是,用戶有可能向G2發起讀操作,由于G2的值沒有發生變化,因此返回的是v0。G1和G2讀操作的結果不一致,這就不滿足一致性了。
為了讓G2也能變為v1,就要在G1寫操作的時候,讓G1向G2發送一條消息,要求G2也改成v1
這樣的話,用戶向G2發起讀操作,也能得到v1。
1.4、Availability
Availability中文叫做"可用性",意思是只要收到用戶的請求,服務器就必須給出回應。用戶可以選擇向G1或G2發起讀操作。不管是哪臺服務器,只要收到請求,就必須告訴用戶,到底是v0還是v1,否則就不滿足可用性。
2、Kafka中的CAP機制
kafka是一個分布式的消息隊列系統,既然是一個分布式的系統,那么就一定滿足CAP定律,那么在kafka當中是如何遵循CAP定律的呢?kafka滿足CAP定律當中的哪兩個呢?
kafka滿足的是CAP定律當中的CA,其中Partitiontolerance通過的是一定的機制盡量的保證分區容錯性。
其中C表示的是數據一致性。A表示數據可用性。
kafka首先將數據寫入到不同的分區里面去,每個分區又可能有好多個副本,數據首先寫入到leader分區里面去,讀寫的操作都是與leader分區進行通信,保證了數據的一致性原則,也就是滿足了Consistency原則。
然后kafka通過分區副本機制,來保證了kafka當中數據的可用性。但是也存在另外一個問題,就是副本分區當中的數據與leader當中的數據存在差別的問題如何解決,這個就是Partitiontolerance的問題。
kafka為了解決Partitiontolerance的問題,使用了ISR的同步策略,來盡最大可能減少Partitiontolerance的問題。
每個leader會維護一個ISR(asetofin-syncreplicas,基本同步)列表。
ISR列表主要的作用就是決定哪些副本分區是可用的,也就是說可以將leader分區里面的數據同步到副本分區里面去,決定一個副本分區是否可用的條件有兩個:
- replica.lag.time.max.ms=10000副本分區與主分區心跳時間延遲
- replica.lag.max.messages=4000副本分區與主分區消息同步最大差
produce請求被認為完成時的確認值:request.required.acks=0。
- ack=0:producer不等待broker同步完成的確認,繼續發送下一條(批)信息。
- ack=1(默認):producer要等待leader成功收到數據并得到確認,才發送下一條message。
- ack=-1:producer得到follower確認,才發送下一條數據。
?