對于設(shè)計分布式系統(tǒng)的架構(gòu)師來說， CAP 是必須掌握的理論。
CAP 定理( CAP theorem )又被稱作布魯爾定理( Brewer’s theorem)，由加州大學(xué)伯克利分校(計算機領(lǐng)域神一樣的大學(xué))的計算機科學(xué)家埃里克·布魯爾在 2000 年的 ACM PODC 上提出的一個猜想。2002 年，麻省理工學(xué)院(另一所計算機領(lǐng)域神一樣的大學(xué)〉的賽斯·吉爾伯特和南希 ·林奇發(fā)表了布魯爾猜想的證明 ， 使之成為分布式計算領(lǐng)域公認的一個定理。
在我剛接觸大數(shù)據(jù)平臺的時候，第一次聽到了CAP的理論，然后公司的架構(gòu)師說hadoop屬于CP系統(tǒng)（Consistency and Partition tolerance），不明覺厲。后來雖然我大致知道了CAP是什么意思，但也是一知半解，比如我并不清楚CAP的適用范圍是什么，系統(tǒng)、數(shù)據(jù)還是應(yīng)用？
最近看到了李云華的一本書：《從零開始學(xué)架構(gòu)》，再一次接觸到了CAP理論，這本書對于CAP的詮釋還是比較通俗易懂的，在這本書的幫助下，再加上有ChatGPT的加持，自己終于對CAP理論有了全新的認識，現(xiàn)在再去理解分布式架構(gòu)就有一覽眾山小的感覺，在此把我的領(lǐng)悟分享給大家。
一、CAP理論的緣起
在分布式系統(tǒng)的設(shè)計重點需要解決兩個問題：橫向擴展和高可用性，橫向擴展是為了解決單點性能瓶頸問題，從而保證可用性，高可用是為了解決單點故障問題，進而保障部分節(jié)點故障時的可用性，由此可以看到，分布式系統(tǒng)的核心訴求就是可用性。這個可用性正是CAP中的A；用戶訪問系統(tǒng)時，可以在合理的時間內(nèi)得到合理的響應(yīng)。
為了保證可用性，一個分布式系統(tǒng)通常由多個節(jié)點組成，這些節(jié)點各自維護一份數(shù)據(jù)，但是不管用戶訪問哪個節(jié)點，原則上都應(yīng)該讀取到相同的數(shù)據(jù)。為了達到這個效果，一個節(jié)點收到寫入請求更新自己的數(shù)據(jù)后，必須將數(shù)據(jù)同步到其他節(jié)點，以保證各個節(jié)點的數(shù)據(jù)一致性，這個一致性正是CAP中的C：用戶訪問系統(tǒng)時，可以讀取到最近寫入的數(shù)據(jù)。
分布式系統(tǒng)中，節(jié)點之間數(shù)據(jù)的同步是基于網(wǎng)絡(luò)的，由于網(wǎng)絡(luò)本身的不可靠性，極端情況下會出現(xiàn)網(wǎng)絡(luò)不可用，從而將網(wǎng)絡(luò)兩端的節(jié)點孤立開來，這就是網(wǎng)絡(luò)分區(qū)的現(xiàn)象。發(fā)生網(wǎng)絡(luò)分區(qū)時，系統(tǒng)中多個節(jié)點數(shù)據(jù)一定是不一致的，但可以選擇對用戶表現(xiàn)出一致性，代價是犧牲可用性，將未能同步到新數(shù)據(jù)的部分節(jié)點設(shè)置為不可用，當然也可以選擇可用性，此時系統(tǒng)中各個節(jié)點都是可用的，只是返回給用戶的數(shù)據(jù)不一致，這里的選擇，就是CAP中的P。
以上就是CAP理論的背景，大家可以知其所以然。
二、CAP定義的辨析
有比較才有鑒別，CAP理論的定義有很多版本，通過比對這些版本的差異，讓我對CAP有了更深入的理解，這里挑選了了2個典型版本：
版本1：
對于一個分布式計算系統(tǒng)，不可能同時滿足一致性( Consistence)、可用性(AvAIlability)、分區(qū)容錯性( Partition Tolerance)三個設(shè)計約束。
一致性(Consistence)：所有節(jié)點在同一時刻都能看到相同的數(shù)據(jù)。
可用性(Availability)：每個請求都能得到成功或失敗的響應(yīng)。
分區(qū)容錯性( Partition Tolerance)：盡管出現(xiàn)消息丟失或分區(qū)錯誤，但系統(tǒng)能夠繼續(xù)運行。
版本2：
在一個分布式系統(tǒng) (指互相連接并共享數(shù)據(jù)的節(jié)點的集合)中，當涉及讀寫操作時，只能保證一致性( Consistence)、可用性( Availability)、分區(qū)容錯性( Partition Tolerance)三者中的兩個，另外一個必須被犧牲。
一致性(Consistence)：對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結(jié)果（A read is guaranteed to return the most recent write for a given client）。
可用性(Availability)：非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng) (不是錯誤和超時的響應(yīng)）。
分區(qū)容錯性( Partition Tolerance)：當出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù) “履行職責”。
我們來具體看看兩者的差異：
1、第二版強調(diào)了CAP 理論適用于哪種類型的分布式系統(tǒng)，第一，互相連接并共享數(shù)據(jù)的節(jié)點的集合，第二，關(guān)注的是對數(shù)據(jù)的讀寫操作，而不是分布式系統(tǒng)的所有功能。
2、在一致性上，第一版從節(jié)點 node 的角度描述，第二版從客戶端 client 的角度描述。第一版強調(diào)同一時刻擁有相同數(shù)據(jù)，第二版并沒有強調(diào)這點 。這就意味著實際上對于節(jié)點來說，可能同一時刻擁有不同數(shù)據(jù)，這和我們通常理解的一致性是有差異的。
3、在可用性上，第一版的“每個請求都能得到成功或失敗的響應(yīng)”定義比較模糊，因為無論是否符合CAP理論，我們都可以說請求成功和失敗，因為超時也算失敗，錯誤也算失敗，異常也算失敗，結(jié)果不正確也算失敗;即使是成功的響應(yīng)，也不一定是正確的。例如，本來應(yīng)該返回100，但實際上返回了90，這就是成功的響應(yīng)，但并沒有得到正確的結(jié)果。相比之下，第二版的解釋明確了不能超時，不能出錯，結(jié)果是合理的，注意沒有說“正確”的結(jié)果。例如，應(yīng)該返回100但實際上返回了90，肯定是不正確的結(jié)果，但可以是一個合理的結(jié)果。
4、在分區(qū)容錯性上，第一版用的是“繼續(xù)運行”，第二版用的是“履行職責”。只要系統(tǒng)不宕機，我們都可以說系統(tǒng)在運行，返回錯誤和拒絕服務(wù)都是運行，而“履行職責”表明發(fā)揮正常作用，這點和可用性是一脈相承的，相比之下更加明確。
三、CAP潛在的約束
理論的優(yōu)點在于清晰簡潔，易于理解，但缺點就是高度抽象化，省略了很多細節(jié)，導(dǎo)致在將理論應(yīng)用到實踐時，由于各種復(fù)雜情況，可能出現(xiàn)誤解和偏差， CAP 理論也不例外。
1、CAP有適用范圍
正如定義中所說，CAP是有適用范圍的，亂套用CAP往往謬以千里。
這里以一個電商網(wǎng)站訂單模塊的下單、付款、扣減庫存操作為例說明。在超時的情況下，訂單數(shù)據(jù)和庫存數(shù)據(jù)狀態(tài)會不一致，這屬不屬于CAP理論的適用范圍呢？答案是不適用。
大家不要一看到不一致就認為適用CAP理論。前面已經(jīng)講過，CAP的適用范圍只是針對共享、互聯(lián)的數(shù)據(jù)，訂單和庫存系統(tǒng)雖然是互聯(lián)的，但沒有共享的數(shù)據(jù)，超時情況下產(chǎn)生的不一致只能靠對賬和人工修復(fù)等方式解決。但如果針對的是各節(jié)點的庫存數(shù)據(jù)的一致性，則適用CAP理論，比如當用戶下單支付后，各節(jié)點的庫存數(shù)據(jù)需要立即更新，以保證所有查看該商品的用戶都能看到最新的庫存信息。
2、CAP理論中，P是必選項
雖然 CAP 理論定義是三個要素中只能取兩個，但放到分布式環(huán)境下來思考，我們會發(fā)現(xiàn)必須選擇 p (分區(qū)容忍)要素，因為網(wǎng)絡(luò)本身無法做到 100%可靠，有可能出故障，所以分區(qū)是一個必然的現(xiàn)象。如果我們選擇了 CA 而放棄了 P，那么當發(fā)生分區(qū)現(xiàn)象時，為了保證 C，系統(tǒng)需要禁止寫入，當有寫入請求時，系統(tǒng)返回 error (例如，當前系統(tǒng)不允許寫入)，這又和 A 沖突了 ，因為 A 要求返回 no error 和 no timeout。因此，分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu) ，只能選擇 CP 或 AP 架構(gòu)。
3、CAP關(guān)注的粒度是數(shù)據(jù)， 而不是整個系統(tǒng)
CAP 理論的定義和解釋中，用的都是 system、 node 這類系統(tǒng)級的概念，這就給很多人造成了很大的誤導(dǎo)，認為我們在進行架構(gòu)設(shè)計時，整個系統(tǒng)要么選擇 CP，要么選擇 AP。但在實際設(shè)計過程中，每個系統(tǒng)不可能只處理一種數(shù)據(jù)，而是包含多種類型的數(shù)據(jù)，有的數(shù)據(jù)必須選擇CP，有的數(shù)據(jù)必須選擇 AP。而如果我們做設(shè)計時，從整個系統(tǒng)的角度去選擇CP還是AP，就會發(fā)現(xiàn)顧此失彼，無論怎么做都是有問題的。
一個電商網(wǎng)站核心模塊包括會員，訂單，商品，支付，促銷管理等等，不同的模塊數(shù)據(jù)特點不同，因此適用不同的CAP架構(gòu)。
會員模塊包括登錄，個人設(shè)置，個人訂單，購物車，收藏夾等功能，這些模塊只要保證AP，即對用戶的及時響應(yīng)，數(shù)據(jù)短時間不一致不大會影響使用。訂單模塊的下單付款扣減庫存操作是整個系統(tǒng)的核心，CA都需要保證，在極端情況下犧牲P是可以的。商品模塊的商品上下架保證CP即可，因為后端操作可以允許一定的時延；促銷模塊短時間的數(shù)據(jù)不一致，結(jié)果就是優(yōu)惠信息看不到，但是已有的優(yōu)惠保證可用，所以保證AP也可以。
現(xiàn)在大部分電商網(wǎng)站對于支付是獨立的系統(tǒng)，C是必須要保證的，AP中A相對更重要，不能因為分區(qū)導(dǎo)致所有人都不能支付。
4、CAP是忽略網(wǎng)絡(luò)延遲的
這是一個非常隱含的假設(shè)，布魯爾在定義一致性時，并沒有將延遲考慮進去。也就是說，當事務(wù)提交時，數(shù)據(jù)能夠瞬間復(fù)制到所有節(jié)點。但實際情況下，從節(jié)點 A 復(fù)制數(shù)據(jù)到節(jié)點 B,總是需要花費一定時間的。這就意味著， CAP理論中的 C 在實踐中是不可能完美實現(xiàn)的，在數(shù)據(jù)復(fù)制的過程中，節(jié)點 A 和節(jié)點 B 的數(shù)據(jù)并不一致。對于嚴苛的業(yè)務(wù)場景。
例如和金錢相關(guān)的用戶余額、和搶購相關(guān)的商品庫存，技術(shù)上是無法做到分布式場景下完美的一致性的。而業(yè)務(wù)上必須要求一致性，因此單個用戶的余額、單個商品的庫存，理論上要求選擇 CP 而實際上 CP都做不到，只能選擇 CA。也就是說，只能單點寫入，其他節(jié)點做備份，無法做到分布式情況下多點寫入，這是符合實際情況的。
5、CAP的AP和CP不是絕對的
CAP理論告訴我們?nèi)咧荒苋蓚€，需要犧牲另外一個，這里的犧牲有一定誤導(dǎo)作用，因為犧牲讓很多人理解成什么都不做，實際上，CAP理論的犧牲只是說分區(qū)過程無法保證C或者A，但不意味著什么都不做，因為在系統(tǒng)整個運行周期中，大部分時間都是正常的，發(fā)生分區(qū)現(xiàn)象的時間并不長，分區(qū)期間放棄C或A，并不意味著永遠放棄，可以在分區(qū)期間進行一些操作，比如記錄日志，從而讓分區(qū)故障解決后，系統(tǒng)能夠重新達到CA的狀態(tài)。
比如用戶賬號數(shù)據(jù)，假設(shè)選擇了CP，則分區(qū)發(fā)生后，節(jié)點1可以繼續(xù)注冊新用戶，節(jié)點2無法注冊新用戶，此時節(jié)點1可以記錄新增日志，當分區(qū)恢復(fù)后，節(jié)點2讀取節(jié)點1的日志就可以讓節(jié)點1和節(jié)點2同時滿足CA的狀態(tài)。
6、CAP的可用性與高可用有區(qū)別
HBASE、MongoDB屬于CP架構(gòu)，Cassandra、CounchDB屬于AP系統(tǒng)，但我們能說后者比前者更高可用么？應(yīng)該不是。CAP中的高可用，是指在某一次讀操作中，即使發(fā)現(xiàn)不一致，也要返回響應(yīng)，即在合理時間返回合理響應(yīng)。我們常說的高可用，是指部分實例掛了，能自動摘除，并由其它實例繼續(xù)提供服務(wù)，關(guān)鍵是冗余。
7、CAP的網(wǎng)絡(luò)分區(qū)有明確定義
網(wǎng)絡(luò)故障、節(jié)點應(yīng)用出現(xiàn)問題導(dǎo)致超時，屬于網(wǎng)絡(luò)分區(qū)，節(jié)點宕機或硬件故障，則不屬于。因此如果有人說機器掛了怎么樣，這種情況不屬于CAP理論適用的范圍，CAP關(guān)注的是分區(qū)時的可用性和一致性，不是說保證整個集群不掛。
四、BASE是CAP的補償
為了解決CAP限制，出現(xiàn)了BASE理論，也就是基本可用（Basically Available）、軟狀態(tài)（Soft state）、最終一致性（Eventually Consistent）理論。BASE是對CAP中一致性和可用性權(quán)衡的結(jié)果，其通過犧牲強一致性來獲取高可用性。
1、基本可用（Basically Available）：指的是分布式系統(tǒng)在出現(xiàn)故障的情況下，仍然可以提供服務(wù)，盡管這個服務(wù)可能不完全，或者有降級，這里的關(guān)鍵是部分和核心。
以電商網(wǎng)站為例，假設(shè)一個電商網(wǎng)站有訂單服務(wù)、商品瀏覽服務(wù)、評論服務(wù)、搜索服務(wù)等多個服務(wù)。如果因為某種原因（如網(wǎng)絡(luò)分區(qū)、硬件故障等）導(dǎo)致評論服務(wù)暫時不可用，但是其他服務(wù)，如訂單服務(wù)、商品瀏覽服務(wù)、搜索服務(wù)等仍然可用。此時，用戶仍然可以瀏覽商品、下訂單和搜索，只是不能進行評論。也就是說，整個系統(tǒng)仍然是"基本可用"的。
2、軟狀態(tài)（Soft state）：允許系統(tǒng)中的數(shù)據(jù)存在一段時間的不一致。
例如，當你第一次訪問一個網(wǎng)站的時候，你的計算機會向DNS服務(wù)器查詢這個網(wǎng)站對應(yīng)的IP地址，然后DNS服務(wù)器會返回IP地址，這個IP地址會被你的計算機或者你的網(wǎng)絡(luò)設(shè)備緩存起來，以備下次訪問的時候使用，以節(jié)省查詢時間。但是，如果在這個緩存期間，網(wǎng)站服務(wù)器更換了IP地址，那么你的計算機或者網(wǎng)絡(luò)設(shè)備緩存的DNS解析結(jié)果就會過期，這就是一個"軟狀態(tài)"。
3、最終一致性（Eventually Consistent）：系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后，最終能夠達到一致的狀態(tài)。這里的關(guān)鍵詞是“一定時間”和“最終“，“一定時間”和數(shù)據(jù)的特性是強關(guān)聯(lián)的，不同的數(shù)據(jù)能夠容忍的不一致時間是不同的。
例如，在一個社交媒體網(wǎng)站上，當用戶發(fā)布一條新的狀態(tài)更新或者照片，他的朋友們可能不能立刻看到這個更新。這是因為這個新的狀態(tài)更新需要被復(fù)制到數(shù)據(jù)中心的各個節(jié)點，這個過程可能需要一些時間。在這個場景中，用戶通常能接受這種延遲，因此對于最終一致性的時間容忍度相對較大。但是，當用戶在電商網(wǎng)站購買商品時，庫存數(shù)據(jù)的對最終一致性的時間容忍度相對較小，因此，電商網(wǎng)站需要盡快地更新和傳播庫存變化，以確保所有的用戶都能看到準確的庫存信息。
前面講過，完美的CP是不存在的，即使是幾毫秒的數(shù)據(jù)復(fù)制延遲，在這幾毫秒的時間間隔內(nèi)，系統(tǒng)是不符合CP要求的，因此，CAP中的CP方案，實際上也是實現(xiàn)了最終一致性。AP方案中犧牲一致性，則只是在分區(qū)期間，而不是永遠放棄一致性，在分區(qū)故障恢復(fù)后，系統(tǒng)應(yīng)該達到最終一致性，因此，BASE是CAP理論的延伸。
五、CAP和ACID的辨析
CAP中的一致性有時會和ACID的一致性產(chǎn)生概念混淆，那么ACID的C到底跟CAP的C有什么區(qū)別呢？
ACID是指數(shù)據(jù)庫事務(wù)正確執(zhí)行的四個基本特性：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。在這里，一致性的定義是：數(shù)據(jù)庫的狀態(tài)應(yīng)該從一個一致的狀態(tài)轉(zhuǎn)移到另一個一致的狀態(tài)，即事務(wù)執(zhí)行前后都保持業(yè)務(wù)規(guī)則的一致性，如完整性約束等。
兩者的主要區(qū)別在于其應(yīng)用的范圍和關(guān)注點不同：
1、CAP中的一致性更多的是從分布式系統(tǒng)的角度考慮，關(guān)注的是分布式節(jié)點間的數(shù)據(jù)一致性問題，即所有節(jié)點看到的數(shù)據(jù)是否實時一致。
2、ACID中的一致性是從單個數(shù)據(jù)庫系統(tǒng)的角度考慮，主要關(guān)注的是數(shù)據(jù)庫在進行事務(wù)操作后，數(shù)據(jù)是否滿足預(yù)定義的業(yè)務(wù)規(guī)則和約束，保證數(shù)據(jù)的正確性。
舉個具體的例子來說明：
假設(shè)你有一個銀行應(yīng)用程序，這個程序有一個簡單的業(yè)務(wù)規(guī)則：客戶的賬戶余額不能小于0。在這個場景下，如果一個客戶想要從他們的賬戶中提取500美元，系統(tǒng)會首先檢查賬戶余額是否滿足這個要求。如果賬戶余額是600美元，那么提取操作是可以進行的，并且完成后，賬戶余額將是100美元。這是一個一致性狀態(tài)，因為它滿足了業(yè)務(wù)規(guī)則。
現(xiàn)在，假設(shè)在這個事務(wù)中，提取操作已經(jīng)完成，但是在更新余額時，系統(tǒng)突然崩潰了。在這種情況下，系統(tǒng)應(yīng)該能夠恢復(fù)并且完成余額更新，或者它應(yīng)該完全忽略這個事務(wù)，就好像它從未發(fā)生過一樣。在任何情況下，客戶的賬戶余額都不應(yīng)該被錯誤地減少，因為那將違反業(yè)務(wù)規(guī)則。
所以，ACID的一致性是關(guān)于在事務(wù)開始和結(jié)束時滿足特定業(yè)務(wù)規(guī)則和約束的，無論事務(wù)過程中是否發(fā)生了錯誤或者系統(tǒng)崩潰，數(shù)據(jù)庫都應(yīng)始終保持一致性狀態(tài)。
六、CAP的應(yīng)用案例
1、ZooKeeper
ZooKeeper（ZK）是一個分布式的、開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，由雅虎公司開發(fā)，并是Apache項目的一部分。ZooKeeper是一種典型的CP（Consistency/一致性, Partition tolerance/分區(qū)容錯性）系統(tǒng)。
ZooKeeper的設(shè)計就是這樣的。當網(wǎng)絡(luò)發(fā)生分裂，只有數(shù)量大于半數(shù)的節(jié)點（稱為“過半機制”）可以繼續(xù)提供服務(wù)，能夠保證數(shù)據(jù)的一致性。數(shù)量少于半數(shù)的節(jié)點會拒絕服務(wù)，以此來保證整個系統(tǒng)的一致性。這意味著在部分節(jié)點不可用或者網(wǎng)絡(luò)分區(qū)的情況下，ZooKeeper可能無法保證所有客戶端的可用性。
ZooKeeper主要被用于管理和協(xié)調(diào)分布式系統(tǒng)中的狀態(tài)信息，如配置信息，狀態(tài)同步，命名服務(wù)和分布式鎖等。數(shù)據(jù)的一致性在這些用途中是非常關(guān)鍵的，因此ZooKeeper選擇了犧牲一部分可用性以保證一致性。
2、Kafka
CAP定理告訴我們，在網(wǎng)絡(luò)分區(qū)的情況下，不可能同時保證一致性（Consistency）和可用（Availability） 。但這并不意味著我們不能在一致性和可用性之間找到適合自己的平衡點。
在Kafka中，例如，我們可以通過設(shè)置不同的"acks"（acknowledgements）和"min.insync.replicas"參數(shù)來權(quán)衡一致性和可用性。如果我們設(shè)置"acks"為"all"或者"-1"，并且將"min.insync.replicas"設(shè)置為一個大于1的數(shù)，那么我們就可以提高數(shù)據(jù)的一致性，但可能會降低系統(tǒng)的可用性，因為每次寫操作都需要等待所有的副本都確認。
反之，如果我們設(shè)置"acks"為"1"，那么寫操作只需要等待一個副本的確認，這就提高了系統(tǒng)的可用性，但可能降低數(shù)據(jù)的一致性，因為其他的副本可能還沒有完成數(shù)據(jù)的更新。
3、HBase
HBase的設(shè)計目標是提供高速的讀寫訪問大量數(shù)據(jù)，并保證強一致性。在HBase中，數(shù)據(jù)是自動分片的，每個分片（稱為region）由一個RegionServer來服務(wù)，每個行鍵只由一個RegionServer來服務(wù)，所以對單個行的讀寫都是強一致的。
當網(wǎng)絡(luò)分區(qū)發(fā)生時，HBase通常會選擇犧牲部分可用性以保持一致性和分區(qū)容錯性。比如說，如果一個RegionServer出現(xiàn)問題，HBase的主節(jié)點（HMaster）會將它上面的regions重新分配給其他健康的RegionServers，這個過程中涉及的regions會在短時間內(nèi)不可用，因此，HBASE屬于CP系統(tǒng)。
4、redis
Redis是一個開源的鍵值存儲系統(tǒng)，它通常用于作為數(shù)據(jù)庫、緩存和消息代理。Redis單實例是一個基于內(nèi)存的數(shù)據(jù)結(jié)構(gòu)存儲，并提供持久化機制。對于單實例的Redis，CAP理論并不適用，因為它并不是一個分布式系統(tǒng)。
在Redis的主從復(fù)制模式中，如果主節(jié)點故障，系統(tǒng)需要手動干預(yù)才能恢復(fù)寫服務(wù)（即升級一個從節(jié)點為新的主節(jié)點）。這意味著它不能自動處理網(wǎng)絡(luò)分區(qū)，因此在嚴格意義上，它也不能被歸類為CAP理論中的任何一類。
對于Redis Cluster，它是一個分布式的Redis解決方案，能夠在一定程度上處理網(wǎng)絡(luò)分區(qū)的問題。在出現(xiàn)網(wǎng)絡(luò)分區(qū)時，Redis Cluster會停止對分區(qū)節(jié)點的操作以保持數(shù)據(jù)的一致性，所以它更傾向于CP系統(tǒng)。
5、Cassandra
Apache Cassandra是一個開源的分布式NoSQL數(shù)據(jù)庫，它是為了滿足高可用性和擴展性的需求而設(shè)計的。
Cassandra使用了一種名為最終一致性（Eventual Consistency）的模型。在這個模型中，系統(tǒng)不保證在任何時刻所有的副本都是一致的，但保證在沒有新的更新操作的情況下，所有的副本最終會達到一致的狀態(tài)。
具體來說，當一個寫操作發(fā)生時，Cassandra只需要一部分（可以配置）副本確認就可以認為寫操作成功了。這樣可以提高系統(tǒng)的可用性和寫入性能。然而，這也意味著在某些情況下，讀操作可能會返回過時的數(shù)據(jù)，因為不一致的副本可能還沒有被更新。
所以，Cassandra是一個典型的AP系統(tǒng)。然而，通過調(diào)整配置，例如設(shè)置更嚴格的一致性級別，可以使Cassandra在一定程度上提供更強的一致性保證。
希望對你有所啟示。
