共計 2706 個字符，預計需要花費 7 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章給大家分享的是有關 redis 中傳統的 ACID 分別指的是什么的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。

傳統的 ACID 分別是什么

A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 獨立性
D (Durability) 持久性
關系型數據庫遵循 ACID 規則，事務在英文中是 transaction，和現實世界中的交易很類似，它有如下四個特性：

1、A (Atomicity) 原子性

??原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從 A 賬戶轉 100 元至 B 賬戶，分為兩個步驟：1）從 A 賬戶取 100 元；2）存入 100 元至 B 賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了 100 元。

2、C (Consistency) 一致性

??一致性也比較容易理解，也就是說數據庫要一直處于一致的狀態，事務的運行不會改變數據庫原本的一致性約束。

3、I (Isolation) 獨立性

??所謂的獨立性是指并發的事務之間不會互相影響，如果一個事務要訪問的數據正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從 A 賬戶轉 100 元至 B 賬戶，在這個交易還未完成的情況下，如果此時 B 查詢自己的賬戶，是看不到新增加的 100 元的

4、D (Durability) 持久性

持久性是指一旦事務提交后，它所做的修改將會永久的保存在數據庫上，即使出現宕機也不會丟失。

CAP

C:Consistency（強一致性）
A:Availability（可用性）
P:Partition tolerance（分區容錯性）或分布式容忍性
CAP 理論就是說在分布式存儲系統中，最多只能實現上面的兩點。
強一致性：比如數據上是什么就是什么。在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同于所有節點訪問同一份最新的數據副本）
可用性：比如淘寶雙十一不可能用不了。在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
分區容錯性：以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在 C 和 A 之間做出選擇。
舉例子：比如淘寶的包包
對于強一致性，我們要求這個包包的點贊數是 141，絕對不能錯。必須精確的指導，但是在高并發的時候很難保證數據的統一
對于高可用性：可以有弱一致性，比如允許點贊數，瀏覽數的錯誤，但不能導致網站癱瘓。
所以大部分網站架構都使用 AP。弱一致性 + 高可用性

Nosql 來說，分區容忍性是必須實現的，分布式系統可能不在同城，比如淘寶，內容分發是離你最近的。淘寶服務器可能有服務器放在杭州，有在上海和蘇州。
而由于當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有 NoSQL 系統能同時保證這三點。

CA 傳統 Oracle 數據庫
AP 大多數網站架構的選擇
CP Redis、Mongodb
注意：分布式架構的時候必須做出取舍。

一致性和可用性之間取一個平衡。多余大多數 web 應用，其實并不需要強一致性。因此犧牲 C 換取 P，這是目前分布式數據庫產品的方向。

一致性與可用性的決擇
??對于 web2.0 網站來說，關系數據庫的很多主要特性卻往往無用武之地
數據庫事務一致性需求
??很多 web 實時系統并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求并不高。允許實現最終一致性。
數據庫的寫實時性和讀實時性需求
??對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對于很多 web 應用來說，并不要求這么高的實時性，比方說在微博發一條消息之后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。
對復雜的 SQL 查詢，特別是多表關聯查詢的需求
??任何大數據量的 web 系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是 SNS 類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL 的功能被極大的弱化了。

經典 CAP 圖

CAP 理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多只能同時較好的滿足兩個。
因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：

CA – 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
CP – 滿足一致性，分區容忍必的系統，通常性能不是特別高。
AP – 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。

BASE

BASE 就是為了解決關系數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。

??BASE 其實是下面三個術語的縮寫：

??基本可用（Basically Available）
??軟狀態（Soft state）
??最終一致（Eventually consistent）
它的思想是通過讓系統放松對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。為什么這么說呢，緣由就在于大型系統往往由于地域分布和極高性能的要求，不可能采用分布式事務來完成這些指標，要想獲得這些指標，我們必須采用另外一種方式來完成，這里 BASE 就是解決這個問題的辦法

分布式 + 集群簡介

分布式系統（distributed system）
由多臺計算機和通信的軟件組件通過計算機網絡連接（本地網絡或廣域網）組成。分布式系統是建立在網絡之上的軟件系統。正是因為軟件的特性，所以分布式系統具有高度的內聚性和透明性。因此，網絡和分布式系統之間的區別更多的在于高層軟件（特別是操作系統），而不是硬件。分布式系統可以應用在在不同的平臺上如：PC、工作站、局域網和廣域網上等。
簡單來講：
分布式：不同的多臺服務器上面部署不同的服務模塊（工程），他們之間通過 RPC/RMI 之間通信和調用，對外提供服務和組內協作。
集群：不同的多臺服務器上面部署相同的服務模塊，通過分布式調度軟件進行統一的調度，對外提供服務和訪問。

感謝各位的閱讀！關于“redis 中傳統的 ACID 分別指的是什么”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！