NoSQL與CAP理論的知識點有哪些

本篇內容主要講解“NoSQL與CAP理論的知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“NoSQL與CAP理論的知識點有哪些”吧!

一種新技術的出現是需求推動的，那么對數據庫的什么需求推動了 NoSQL 的出現呢？看看傳統數據庫在使用時的一些問題：

（1）大數據量情況下吞吐率達不到要求，有單點瓶頸。

（2）事務的ACID特性要求太高，很多應用場景不需要這個約束。

（3）具有單點故障，機器宕機后就沒法用了，雖然可以做主從，但是還需要人為干預，有一段時間不可用。

（4）單節點存不下全部數據。

（5）數據容易丟失，不做主備的話數據只有一份，磁盤壞掉數據就丟了。

因此，傳統數據庫一般應用于銀行系統、醫療系統這些對操作的要求比較高或者數據量不大的場景。而一些需要高可用性的應用，如Facebook、淘寶、亞馬遜等，傳統數據庫就無法滿足要求。

于是，人們希望拋棄傳統數據庫的思想，構建分布式 NoSQL 數據庫，這種數據庫有下面幾個目標：

（1）每個節點都可以提供讀寫服務，提高系統吞吐率，可動態增刪節點，集群的吞吐率隨著節點的增加而線性增長。

（2）去掉了事務，只提供比較簡單的讀寫接口。

（3）避免單點故障，由多個節點組成的集群，一個節點壞了其他節點還能提供服務。

（4）所有節點的磁盤都可以用來存儲數據，提供分布式存儲能力。

（5）為保證數據不丟失，采用副本機制，一個數據存多份，分別放在不同節點。

（6）為了控制數據的存儲位置，還提出了數據分區的概念。

在構建 NoSQL 數據庫時，往往需要在很多方面做平衡。Brewer 在2000年左右提出了 CAP 理論， Consistency、Availability、Partition Tolerance 的首字母縮寫。

CAP理論：一個分布式系統不可能同時滿足一致性、可用性和分區容錯性，最多只能同時滿足其中的兩個。

這個分布式系統一般是指在異步網絡中的，異步網絡中沒有全局時鐘，節點只能根據接收到的消息和本地計算做決策。

有的對 CAP 的誤解也來源于對這三個性質的具體含義不清，下面我們先看看這三個性質分別指什么。

CAP 的一致性與傳統關系數據庫中 ACID 的 C 不一樣。ACID 中的 C 關心的是數據庫中的約束，有對單個數據值的約束，也有對多個數據之間值的約束。而CAP 的一致性關心的是一個數據項不同副本的值是否相同。

在 NoSQL 數據庫中，由于數據有多個副本，一個寫操作需要更新所有副本，由于存在節點間通訊的延遲，可能有的節點的副本被更新了，有的還是舊值，這時讀取不同的副本返回的值就會不一致。因此，CAP 中的一致性指的是副本一致性，或者相互一致性（mutual Consistency），他們和一個瞬時狀態有關，這個狀態叫相互一致：

相互一致：如果系統中每個數據項的所有副本的值都相同，那么系統處于相互一致的狀態。在某一時刻，這個狀態只有滿足或不滿足兩種情況。

我們可以認為 NoSQL 數據庫僅提供簡單的對單個數據項的讀寫操作，如 write(a)，read(b)，write(b)等，在這種情況下，一致性的表現就和不同節點間讀寫操作的順序有關了。因此，很多一致性級別在規定讀寫操作的順序和結果。

CAP中的一致性指的是強一致性：當更新事務提交時，所有副本處于相互一致的狀態。

從操作的角度看：所有操作必須存在一個全局唯一順序，使每個操作看起來好像是在一個瞬間完成的。在這種情況下，在一個寫操作之后的讀操作可以讀到這個寫的值。

所有節點都可以讀到已經更新的結果，看起來就像是一個單機數據庫，而且操作是串行的，和ACID隔離性中的可串行化隔離級別一樣。

CAP 中的可用性指的是系統每個節點都能處理請求（接收請求并返回結果）。

而一般傳統數據庫的可用性是指系統做為一個整體能否對外提供服務，只要有一個節點或多數節點能提供響應就可以稱為可用。

分區就是網絡分區，即一個集群被分割成了多個分區，每個分區內部的節點可以通信，而無法跨分區交流，而且這個分區要假設是可能永久存在的。網路分區是分布式系統中逃不掉的。

而分區容忍性則是說在出現網絡分區時，系統能否正常對外提供服務。

這張圖是CAP里比較經典的圖了。由于沒有NoSQL同時滿足三個，因此只能二選一。

傳統數據庫由于只有一個節點，沒有網絡分區問題，正常情況下可以實現強一致性和可用性。而傳統數據庫的主備技術則是犧牲了可用性來保證一致性。

由于 NoSQL 數據庫中網絡分區是不可避免的，當出現網絡分區時，如下圖左圖，當接收到一個寫操作 A=2（這個寫請求只會被發送到一個節點上），我們假設每個節點執行操作需要得到另外兩個節點的認可才能執行并返回結果。這時只能在一致性和可用性里二選一。

如果保證一致性，那么任何接收到請求的節點都無法收到全部節點的認同，所以這個操作會被懸掛，最終返回超時或執行錯誤。

如果保證可用性，可能有一個網絡分區接收到這個寫請求，并在當前分區內同步寫請求，這是就會與另一個分區數據不一致。這個分區是隨機的，可能是上圖所示的 N3，也可能是 N1 和 N2。

到此，相信大家對“NoSQL與CAP理論的知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！