分布式事务前看懂CAP、BASE
CAP、BASE跟后面要看的分布式事務有直接的關系，但是這兩個分布式的理論對我們研究分布式系統(tǒng)里面的一些技術和方案都是作為基礎的知識需要掌握的
?
這個CAP這個東西啊，也是個在研究分布式相關的問題中，比較經典的這么一個理論，大家在學習下面的知識之前，最好是先有相關知識的一個積累，這樣下面學習起來才會比較輕松一些
?
CAP，就是Consistency、Availability、Partition Tolerence的簡稱，簡單來說，就是一致性、可用性、分區(qū)容忍性，所以這個CAP理論講的就是這么個東西，但是這里的話呢，其實大家覺得很虛，虛的不行，簡直是虛頭巴腦啊
?
所以網上很多類似的什么CAP理論的文章和博客，都是這么講解的，大家看了就覺得心里涼涼的，不知道是啥玩意兒
?
（1）一致性
?
先說說C，就是一致性吧，這個其實很好理解，就是說一個分布式系統(tǒng)中，一旦你做了一個數(shù)據(jù)的修改，那么這個操作成功的時候，就必須是分布式系統(tǒng)的各個節(jié)點都是一樣的，
?
能說，客戶端發(fā)起一個數(shù)據(jù)修改的請求，然后服務器告訴他成功了，結果去查的時候，從某個節(jié)點上查詢數(shù)據(jù)，發(fā)現(xiàn)這個數(shù)據(jù)不對啊，這樣的話就成了數(shù)據(jù)不一致了，就是分布式系統(tǒng)的各個節(jié)點上的數(shù)據(jù)是不一樣的，就是不一致
?
這個所謂一致性還分成幾種：
?
啥叫強一致性呢，就是說上面講的那種就是強一致性；弱一致性呢，就是你更新個數(shù)據(jù)，鬼知道能不能讓各個節(jié)點都更新成功；最終一致性，就是可能更新過后，一段時間內，數(shù)據(jù)不一致，最后過了一段時間成功了
?
最終一致性，應該是分布式系統(tǒng)中非常常見的這么一個東西，redis主從同步，你可以做成主從異步同步的，主節(jié)點同步數(shù)據(jù)到從節(jié)點上去的時候，異步，最終一致性的體現(xiàn)。
?
你的一個客戶端往redis主節(jié)點里面寫入了一條數(shù)據(jù)，在一段時間內，你客戶端如果從redis從節(jié)點去查詢數(shù)據(jù)，此時可能是查不到的，但是redis主從機制給你保證的是，過了一段時間之后，你再查，一定是可以從redis從節(jié)點里查到的
?
（2）可用性
?
這個A，就是可用性，其實也很好理解，就是你的分布式系統(tǒng)必須是可用的啊，說句不好聽的，要是一會兒訪問你是成功，一會兒訪問你失敗，那失敗的時候就是不可用，有不可用的情況存在，就導致可用性降低了
?
什么叫做可用？客戶端往分布式系統(tǒng)的各個節(jié)點發(fā)送請求，都是可以獲取到響應的，要不是可以寫入成功，要不是可以查詢成功；什么叫做不可用呢？客戶端往分布式系統(tǒng)中的各個節(jié)點發(fā)送請求的時候，獲取不到響應結果，這個時候，系統(tǒng)就是不可用了，寫入失敗，人家不讓你寫入，不接受你的請求
?
可用性分成好多級別，比如99%，99.9%，99.99%，99.999%
?
99%，一年中只能有80小時左右是可以允許訪問失敗的
99.9%，一年中大概有8小時左右是可以訪問失敗
99.99%，一年中有大概不到1小時是可以訪問失敗的
99.999%，一年中有大概不到5分鐘是可以訪問失敗的
99.9999%，一年中只能有大概不到1分鐘可以訪問失敗
?
那一般來說，就我個人觀察，很多行業(yè)大部分的系統(tǒng)，其實99%可用性都沒到，或者可能大概就在99%是一個很正常的水平，每年總得故障幾次。能做到99.9%的系統(tǒng)就算是比較牛的了，也算很不錯了，畢竟一年內就幾個小時不可用
?
一般做到99.99%，也就是所謂的4個9，那就是比較高的水平了。而至于說99.999%，五個9，那是行業(yè)內的頂尖水平
?
（3）分區(qū)容忍性
?
分區(qū)，partition，network partition，網絡分區(qū) => 分布式系統(tǒng)之間的網絡環(huán)境出了故障，分布式系統(tǒng)的各個節(jié)點之間現(xiàn)在已經無法進行通信了
?
分區(qū)容忍性，你的分布式系統(tǒng)可以容忍網絡分區(qū)的故障，出現(xiàn)上面說的那種網絡分區(qū)的故障之后，分布式系統(tǒng)的各個節(jié)點之間無法進行通信，無所謂，整套分布式系統(tǒng)各個節(jié)點，各自為戰(zhàn)，該干嘛干嘛，只不過互相之間無法通信而已
?
分布式系統(tǒng)還是在運轉著，你分別給各個節(jié)點發(fā)送請求，人家還是可以給你一些響應結果的，這個就是實現(xiàn)了分區(qū)容忍性
?
這玩意兒搞的稀奇古怪的，啥東西啊，其實說白了，就是一個分布式的系統(tǒng)，如果遇到了網絡分區(qū)的故障，也就是說，分布式系統(tǒng)互相之間無法聯(lián)通了，這個時候咋整呢，有點兒惡心啊，這里要求的是，遇到網絡分區(qū)故障，也類似于傳說中的腦裂吧，然后系統(tǒng)還是可以正常對外提供服務的
?
如果不具備分區(qū)容忍性，那會怎么樣呢？那就是說一旦網絡故障，整套系統(tǒng)崩潰，你哪怕給各個節(jié)點發(fā)送消息，全部失敗，清一色失敗，整套系統(tǒng)甚至會宕機，不再運轉了
?
（4）CAP => CP or AP
?
不可能CAP三者兼得的，CAP理論里面，最最重要的一點，就是說，不可能一個分布式系統(tǒng)同時兼?zhèn)湟恢滦浴⒖捎眯浴⒎謪^(qū)容忍性，要么幾句是CP（一致性 + 分區(qū)容忍性），要么就是AP（可用性 + 分區(qū)容忍性）
?
基于這套理論，redis、mongodb、hbase什么什么的分布式系統(tǒng)，都是參照著CAP理論來設計的，有些系統(tǒng)是CP，有些系統(tǒng)是AP
?
（4）CP
?
一般來說，CAP要么同時滿足AP，要么同時滿足CP，不可能同時滿足CAP的，啥意思呢
?
如果實現(xiàn)CP的時候，為什么就無法同時滿足AP了？為什么有了一致性，就不能有可用性了？CAP里面，為什么要們是CP，要么是AP？為什么一定要有P？分區(qū)容忍性，分布式系統(tǒng)，如果一旦出現(xiàn)了一些網絡分區(qū)的故障之后，保證整套系統(tǒng)繼續(xù)運轉是非常重要的一點，所以很多分布式系統(tǒng)es，都設計了防止腦裂的機制
?
P是一定要有，CP，AP，CA（不存在的）
?
CP，為什么就沒有A了呢？
?
假設，出現(xiàn)了網絡分區(qū)的故障，但是因為有P，所以分布式系統(tǒng)繼續(xù)運轉，但是此時分布式系統(tǒng)的節(jié)點之間無法進行通信，也就無法同步數(shù)據(jù)了
?
此時客戶端要來查詢數(shù)據(jù)，也就是那個key1的數(shù)據(jù)了，此時系統(tǒng)實際上是處于一個不一致的狀態(tài)，因為各個節(jié)點之間的數(shù)據(jù)是不一樣的，如果客戶端來查詢key1這條數(shù)據(jù)，你要是要保證CP的話，就得返回一個特殊的結果（異常）給客戶端
?
任何一個節(jié)點此時不接收任何查詢的請求，返回一個異常（系統(tǒng)當前處于不一致的狀態(tài)，無法查詢），這樣的話呢，客戶端是看不到不一致的數(shù)據(jù)的
?
此時對客戶端而言，要么查到的是一致性的數(shù)據(jù)，要么如果數(shù)據(jù)不一致什么都查不到，不讓你看到不一致的數(shù)據(jù)，這就保證了CAP里的C，一致性，分布式系統(tǒng)本身處于不一致的時候，讓你看不到不一致的數(shù)據(jù)，就保證了一致性，保證了CP
?
但是此時的話，就犧牲掉了A，可用性，因為此時不讓你看到不一致的數(shù)據(jù)，所以你發(fā)送請求過來是返回異常的，請求失敗了，此時分布式系統(tǒng)就暫時處于不可用的狀態(tài)下，也就是保證了CP，就沒有了A
?
弄個分布式系統(tǒng)給大家演示一下，就倆節(jié)點，假設現(xiàn)在發(fā)生了網絡分區(qū)故障，好了，那么P起碼要保證吧，就是網絡分區(qū)的時候，系統(tǒng)還是要正常可以運行的，所以P先保證了，對吧，然后呢，因為網絡分區(qū)，導致倆節(jié)點互相不能通信了
?
現(xiàn)在呢，你寫入一條數(shù)據(jù)到其中一個節(jié)點，好了，結果這個節(jié)點沒法同步數(shù)據(jù)到其他的節(jié)點上去啊，咋整呢，尷尬啊尷尬，倆節(jié)點上數(shù)據(jù)不一致了
?
所以這個時候，如果你要滿足C，也就是一致性，你覺得應該怎么辦，你要是繼續(xù)讓所有人訪問兩個節(jié)點，那數(shù)據(jù)100%不一致，一會兒數(shù)據(jù)這樣，一會兒數(shù)據(jù)那樣，這個時候，你就只能犧牲掉A了
?
也就是說，在這種情況下，你的系統(tǒng)直接對外不再提供服務，人家查詢直接返回異常，不讓查到不一致的數(shù)據(jù)，不就可以保證一致性了，呵呵，但是你就犧牲了可用性了，因為這個時候你的系統(tǒng)是不可用的
?
經典的就是一些分布式存儲，比如說zookeeper、mongodb、hbase等等，跟他們都是CP的，也就是說數(shù)據(jù)100%一致，但是有可能有些時候你請求是失敗的，不讓你請求到不一致的數(shù)據(jù)，這就是CP
?
如果要保證CP的話，C，保證說你在任何情況下寫入一條數(shù)據(jù)，接著從任何一個節(jié)點去查都可以看到一致的數(shù)據(jù)，不可能讓你一會兒看到舊數(shù)據(jù)，一會兒看到的是新數(shù)據(jù)，這樣就保證了一致性
?
有些特殊的情況下，確實數(shù)據(jù)就是沒法同步，沒法一致性，此時可能就得犧牲A了，可能短暫的情況下，你發(fā)送請求過去人家返回異常給你，此時就是短暫不可用的，讓你過段時間在重試查詢
?
（5）AP
?
如果網絡故障，數(shù)據(jù)沒同步，數(shù)據(jù)處于不一致的狀態(tài)下，要保證A，可用性，你兩個節(jié)點都要允許任何客戶端來查詢，都可以查到，這樣的話呢，整個系統(tǒng)就處于可用的狀態(tài)下，但是此時就犧牲掉了C
?
一會兒可以查到key1的數(shù)據(jù)，一會兒從另外一個節(jié)點去查又查不到了，這就是對客戶端而言，看到了不一致的數(shù)據(jù)
?
在各種分布式系統(tǒng)里面，CAP不可能同時兼得，指的主要是什么呢，就是發(fā)生網絡故障的時候，可能一些數(shù)據(jù)沒有同步一致性，此時要么就是CP，要么就是AP
?
那如果要保證AP呢，也就是可用性必須保證，人家過來查必須給人查，那就犧牲掉一致性咯，隨便查，要怎么查怎么查，但是查到的數(shù)據(jù)不一致，那我不管了，反正就這么回事兒了，哈哈哈。。。起碼我可用性保證了，一致性就沒了
?
對于12306、電商系統(tǒng)，這種業(yè)務類系統(tǒng)，一般都是AP，也就是說，你可能看到的商品庫存或者火車票的庫存，是錯的，有可能是舊的啊，那么數(shù)據(jù)很可能看到的都是不一致的，但是呢，你買東西或者買票的時候，一定會檢查庫存，就可以了
?
但是保證了可用性就ok，任何時候都要響應結果，不能動不動就失敗
?
12306買票，AP，C其實是沒保證的。很多人同時在訂票，每次訂票之后這個車票的庫存就會扣減，但是車票庫存扣減之后，可能不能及時的被你的12306網站展示出來，可能你查詢的車票的庫存，是從另外一個庫里去查的，最新的庫存數(shù)據(jù)還沒同步過來，此時數(shù)據(jù)是不一致的
?
所以你看到的是不一致的數(shù)據(jù)，C，但是AP，可用性是保證的，時時刻刻都讓你可以看到數(shù)據(jù)，可以買票，可以查詢，但是呢可能你看到的車票還剩5張，但是你發(fā)起訂票的時候，人家一檢查最新的庫存，判斷已經是0張了，就不讓你買了唄
?
（6）BASE理論
?
所謂的BASE，Basicly Available、Soft State、Eventual Consistency，也就是基本可用、軟狀態(tài)、最終一致性
?
BASE希望的是，CAP里面基本都可以同時實現(xiàn)，但是不要求同時全部100%完美的實現(xiàn)，CAP三者同時基本實現(xiàn)，BASE，基本可用、最終一致性
?
此時要保證基本可用性，應該怎么辦呢？兩個節(jié)點都可以查詢的，但是這個時候你會發(fā)現(xiàn)說有的節(jié)點可以返回數(shù)據(jù)，有的節(jié)點無法返回數(shù)據(jù)，會看到不一致的狀態(tài)，這個不一致的狀態(tài)，就是指的是BASE中的S，soft state，軟狀態(tài)
?
基本可用，降級，正常情況下，是查詢可以負載均衡到各個節(jié)點去查的，也就是可以多節(jié)點抗高并發(fā)查詢，但是此時如果你要降級的話，可以降級為，所有客戶端強制查詢主節(jié)點，這樣看到的數(shù)據(jù)暫時而言都是一樣的，都是從主節(jié)點去查
?
但是因為客戶端訪問量太大了，同時用一個主節(jié)點來支撐很坑，扛不住，怎么辦呢，主節(jié)點做限流降級，也就是說如果流量太大了，直接返回一個空，讓你稍后再來查詢
?
如果你這樣子來降級了，保證的就是所謂的基本可用，降級的措施在里面了，跟正常的可用是不一樣的，比正常的可用要差一些，但是還是基本可以用的
?
最終一致性，一旦故障或者延遲解決了，數(shù)據(jù)過了一段時間最終一定是可以同步到其他節(jié)點的，數(shù)據(jù)最終一定是可以處于一致性的
?
這個基本可用的意思，就是說可以適當進行降級，比如說某些系統(tǒng)是可以進行降級的，在故障的時候，直接引導到降級的一些功能里去，舉個例子吧，本來商品詳情頁可以是個極度華麗的頁面，但是如果降級的話，那么就變成一個比較簡陋的頁面，里面包含少量數(shù)據(jù)
?
軟狀態(tài)意思就是說，可以存在中間的數(shù)據(jù)狀態(tài)，就是比如多個節(jié)點在同步數(shù)據(jù)，在一段時間內，可能每個節(jié)點數(shù)據(jù)不一致，正在同步過程中，這個就是軟狀態(tài)
?
最終一致性，就是說，雖然存在軟狀態(tài)，但是最終還是會變成一致的
?
所以說，CAP和BASE是倆理論，是倆基礎理論，你在設計分布式系統(tǒng)的話，可以用CAP中的CP或者AP，也可以采用BASE理論，有一些不一樣，也有一些關系
總結
以上是生活随笔為你收集整理的分布式事务前看懂CAP、BASE的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ubuntu下进行流量监控软件netho
- 下一篇： React（7）—— SPA应用 - R