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