zookeeper和eureka的區別

zookeeper和eureka的區別：

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：國際域名空間、虛擬主機、營銷軟件、網站建設、平羅網站維護、網站推廣。

CAP 原則又稱 CAP 定理，1998年，加州大學的計算機科學家 Eric Brewer 提出的，指的是在一個分布式系統中，Consistency（一致性）、?Availability（可用性）、Partition tolerance（分區容錯性），三者不可兼得（我們常說的魚和熊掌不可兼得）。CAP 原則也是 NoSQL 數據庫的基石。

1、一致性（Consistency，C）：

在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同于所有節點訪問同一份最新的數據副本）。

2、可用性（Availability，A）：

在一個分布式系統的集群中一部分節點故障后，該集群是否還能夠正常響應客戶端的讀寫請求。（對數據更新具備高可用性）。

3、分區容錯性（Partition tolerance，P）：

大多數的分布式系統都分布在多個子網絡中，而每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。

比如阿里巴巴的服務器，一臺服務器放在上海，另一臺服務器放在北京，這就是兩個區，它們之間可能存在無法通信的情況。在一個分布式系統中一般分區容錯是無法避免的，因此可以認為 CAP 中的 P 總是成立的。CAP 理論告訴我們，在 C 和 A 之間是無法同時做到。

zookeeper和eureka的區別：

Spring Cloud Eureka? - AP

Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則。Eureka Server 也可以運行多個實例來構建集群，解決單點問題，但不同于 ZooKeeper 的選舉 leader 的過程，Eureka Server 采用的是Peer to Peer 對等通信。

這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點通過彼此互相注冊來提高可用性，每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。

在集群環境中如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的服務器重新恢復后，Eureka 會再次將其納入到服務器集群管理之中。

當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制操作，將請求復制到該 Eureka Server 當前所知的其它所有節點中。

當一個新的 Eureka Server 節點啟動后，會首先嘗試從鄰近節點獲取所有注冊列表信息，并完成初始化。Eureka Server 通過 getEurekaServiceUrls方法獲取所有的節點，并且會通過心跳契約的方式定期更新。

默認情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務實例的心跳，Eureka Server 將會注銷該實例。當 Eureka Server 節點在短時間內丟失過多的心跳時，那么這個節點就會進入自我保護模式。

Apache Zookeeper - CP

與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。

從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上服務器節點不可用，那么將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。

當然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。

但是對于服務發現來說，情況就不太一樣了，針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也并不會造成災難性的后果。

因為對于服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務實例信息后嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好

CAP原則的與NoSQL的關系

傳統的關系型數據庫在功能支持上通常很寬泛，從簡單的鍵值查詢，到復雜的多表聯合查詢再到事務機制的支持。而與之不同的是，NoSQL系統通常注重性能和擴展性，而非事務機制（事務就是強一致性的體現） 。傳統的SQL數據庫的事務通常都是支持ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要么事務中的操作全部執行，要么一個都不執行;C代表一致性，即保證進行事務的過程中整個數據加的狀態是一致的，不會出現數據花掉的情況;I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等;D表示持久化，即事務一量完成，那么數據應該是被寫到安全的，持久化存儲的設備上（比如磁盤）。NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行的時候是會串行的執行，保證了每一個Key-Value對不會被破壞。

什么是CAP原理

分布式領域CAP理論，

Consistency(一致性), 數據一致更新，所有數據變動都是同步的

Availability(可用性), 好的響應性能

Partition tolerance(分區容錯性) 可靠性

定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。

忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取舍。

關系數據庫的ACID模型擁有 高一致性 + 可用性 很難進行分區：

Atomicity原子性：一個事務中所有操作都必須全部完成，要么全部不完成。

Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。

Isolation隔離層. 事務將假定只有它自己在操作數據庫，彼此不知曉。

Durability. 一旦事務完成，就不能返回。

跨數據庫事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支持2PC。因為2PC是反模式，盡量不要使用2PC，使用BASE來回避。

BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性：

Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分數據庫)

Soft state軟狀態 狀態可以有一段時間不同步，異步。

Eventually consistent最終一致，最終數據是一致的就可以了，而不是時時高一致。

BASE思想的主要實現有

1.按功能劃分數據庫

2.sharding碎片

BASE思想主要強調基本的可用性，如果你需要High 可用性，也就是純粹的高性能，那么就要以一致性或容錯性為犧牲，BASE思想的方案在性能上還是有潛力可挖的。

現在NoSQL運動豐富了拓展了BASE思想，可按照具體情況定制特別方案，比如忽視一致性，獲得高可用性等等，NOSQL應該有下面兩個流派：

1. Key-Value存儲，如Amaze Dynamo等，可根據CAP三原則靈活選擇不同傾向的數據庫產品。

2. 領域模型 + 分布式緩存 + 存儲 （Qi4j和NoSQL運動），可根據CAP三原則結合自己項目定制靈活的分布式方案，難度高。

這兩者共同點：都是關系數據庫SQL以外的可選方案，邏輯隨著數據分布，任何模型都可以自己持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲可以是異步或同步，取決于對一致性的要求程度。

不同點：NOSQL之類的Key-Value存儲產品是和關系數據庫頭碰頭的產品BOX，可以適合非Java如PHP RUBY等領域，是一種可以拿來就用的產品，而領域模型 + 分布式緩存 + 存儲是一種復雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

關于NewSQL數據庫對于CAP的再解釋

作者 石默研

關于CAP的討論已經很多，包括作者的另一篇文章“對CAP的初步解釋”，基本已經即定思維的理解就是：分布式系統必須遵循CAP，一個分布式系統的設計只能同時滿足其中兩個，不可能同時滿足；傳統關系數據庫選擇A與C，代表了互聯網新興技術的NoSQL數據庫則選擇A與P（或者C與P，雖然這種情況其實需要詳細討論）。

但是，近年來，新興的NewSQL數據庫（TiDB或者OceanBase），則是一種在分布式環境下，保證的ACID強事務特征的強一致性數據庫，并且很顯然，它同時也滿足了高可用性與優秀的分區可容忍性（很好的可擴展特性便是其一個層面的證明），似乎看起來，C、A、P都同時保證了，這不是違反了已經經過嚴格證明的CAP理論嗎？

這個問題初看起來，似乎是比較神奇，但仔細分析，其實答案是很明顯的。

首先，需要讀者區分“分布式”與CAP中所提到的分區可容忍性Paritition Tolerance并不是一回事。分區可容忍性P是指以下兩種分布式的情況：

. 同一份數據的多個副本的可分布性

. 有相互關聯的數據的可分布性（操作中表現為保證ACID的強分布式事務）

即使是分庫分表，如果不存在以上兩種情況，只是獨立數據在同一個節點上的情況，雖然也是分布式，但跟CAP中的P沒有半毛錢關系。

那么，還是回到上面的問題，NewSQL數據庫，確實也是在保證了同一份數據多副本的強讀寫一致性、以及強分布式事務特性這樣的C的情況下，同時保證了A與P呀！事實確實如此，但這還是要仔細分析：

無論是TiDB，還是OceanBase，其在保證數據多副本的強一致性時，都采用了Paxos協議或者Raft，它們簡單來講就是多數選舉的原則，即寫不需要全部副本都完成，就能保證讀的強一致性，反過來也是一樣。因此，其在分布式情況下，保證數據讀寫強一致性的效率還是很高的，就是說，在同一個數據中心的網絡環境下，雖然這種分布可容忍性的滿足理論上講也會比單節點多一點點效率損失，但實際上是可以忽略不計的。但需要指出的是，在跨數據中心、跨城市的分布式情況下，如果要保證數據多副本的強一致性，即保證分區可容忍性，對效率（實際上是可用性A）的影響那還是不可忽略的。因此，在這種情況下，CAP理論依然成立。

再來看相互關聯數據的可分布性，這就涉及到了分布式事務?，F有的NewSQL數據庫，即使在同一數據中心，為了保證強的分布式事務，對效率的折衷都是不可忽略的，所謂的樂觀事務，只是因為客觀問題本身沖突就少，并不改變沖突很多時效率明顯受影響的現實。因此，NewSQL數據庫雖然提供強分布式事務的能力，但在現實應用中，都是提倡盡量避免大量的分布式事務出現。如果你所遇到的應用場景是確實需要大量的分布式事務執行，又不做應用優化全交給數據庫執行，那么，現有的NewSQL分布式數據庫，依然會遇到明顯的性能問題，其實就是可用性A降低了。同學仔細去研究應用中的實際情況就會發現，很多互聯網應用，當其所需要的QPS很高很高，而對讀寫一致性與強分布式事務的要求又不那很高時候，其實，NewSQL數據庫還是不能滿足他們的需求的，他們仍然需要根據自己的情況改造或者選用NoSQL數據庫，這也是CAP理論并沒有被NewSQL打破的現實證明。

因此，總結來講，NewSQL數據庫，也是遵循CAP理論的，只不過，在同中心數據多副本情況下，保證P的同時對A的影響微乎其微；而在分布式事務的情況下，又采用了與應用特性相關的策略（其實樂觀、悲觀事務本質上就有根本應用特性區分的意思）來保證性能而已。當然，隨著網絡與計算機性能的提高，CAP三個特征中，保證其中兩個，折衷另外一個，所帶來的影響也會逐漸變小，但其理論依然是正確的。

什么是NoSQL數據庫？

2. 什么是NoSQL？

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，

泛指非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。

（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 關系型數據庫與NoSQL的區別？

3.1 RDBMS

高度組織化結構化數據

結構化查詢語言（SQL）

數據和關系都存儲在單獨的表中。

數據操縱語言，數據定義語言

嚴格的一致性

基礎事務

ACID

關系型數據庫遵循ACID規則

事務在英文中是transaction，和現實世界中的交易很類似，它有如下四個特性：

A (Atomicity) 原子性

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

C (Consistency) 一致性

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

I (Isolation) 獨立性

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

D (Durability) 持久性

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

3.2 NoSQL

代表著不僅僅是SQL

沒有聲明性查詢語言

沒有預定義的模式

鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫

最終一致性，而非ACID屬性

非結構化和不可預知的數據

CAP定理

高性能，高可用性和可伸縮性

分布式數據庫中的CAP原理(了解)

CAP定理：

Consistency(一致性), 數據一致更新，所有數據變動都是同步的

Availability(可用性), 好的響應性能

Partition tolerance(分區容錯性) 可靠性

P: 系統中任意信息的丟失或失敗不會影響系統的繼續運作。

定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。

CAP理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，

因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：

CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。

CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。

AP - 滿足可用性，分區容忍性的系統，通?？赡軐σ恢滦砸蟮鸵恍?。

CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。

而由于當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。

所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

說明：C：強一致性 A：高可用性 P：分布式容忍性

舉例：

CA：傳統Oracle數據庫

AP：大多數網站架構的選擇

CP：Redis、Mongodb

注意：分布式架構的時候必須做出取舍。

一致性和可用性之間取一個平衡。多余大多數web應用，其實并不需要強一致性。

因此犧牲C換取P，這是目前分布式數據庫產品的方向。

4. 當下NoSQL的經典應用

當下的應用是 SQL 與 NoSQL 一起使用的。

代表項目：阿里巴巴商品信息的存放。

去 IOE 化。

ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一臺；O 是指 Oracle 數據庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設備，也很貴的。

難點：

數據類型多樣性。

數據源多樣性和變化重構。

數據源改造而服務平臺不需要大面積重構。

如何正確理解CAP理論

常見的理解及分析

目前流行的、對CAP理論解釋的情形是從同一數據在網絡環境中的多個副本出發的。為了保證數據不會丟失，在企業級的數據管理方案中，一般必須考慮數據的冗余存儲問題，而這應該是通過在網絡上的其他獨立物理存儲節點上保留另一份、或多份數據副本來實現的（如附圖所示）。因為在同一個存儲節點上的數據冗余明顯不能解決單點故障問題，這與通過多節點集群來提供更好的計算可用性的道理是相同的。

附圖 CAP理論示意圖

其實，不用做嚴格的證明也可以想見，如附圖的情況，數據在節點A、B、C上保留了三份，如果對節點A上的數據進行了修改，然后再讓客戶端通過網絡對該數據進行讀取。那么，客戶端的讀取操作什么時候返回呢？

有這樣兩種情況：一種情況是要求節點A、B、C的三份數據完全一致后返回。也就是說，這時從任何一個網絡節點讀取的數據都是一樣的，這就是所謂的強一致性讀。很明顯，這時數據讀取的Latency要高一些（因為要等數據在網絡中的復制），同時A、B、C三個節點中任何一個宕機，都會導致數據不可用。也就是說，要保證強一致性，網絡中的副本越多，數據的可用性就越差；

另一種情況是，允許讀操作立即返回，容忍B節點的讀取與A節點的讀取不一致的情況發生。這樣一來，可用性顯然得到了提高，網絡中的副本也可以多一些，唯一得不到保證的是數據一致性。當然，對寫操作同樣也有多個節點一致性的情況，在此不再贅述。

可以看出，上述對CAP理論的解釋主要是從網絡上多個節點之間的讀寫一致性出發考慮問題的。而這一點，對于關系型數據庫意味著什么呢？當然主要是指通常所說的Standby（關于分布式事務，涉及到更多考慮，隨后討論）情況。對此，在實踐中我們大多已經采取了弱一致性的異步延時同步方案，以提高可用性。這種情況并不存在關系型數據庫為保證C、A而放棄P的情況；而對海量數據管理的需求，關系型數據庫擴展過程中所遇到的性能瓶頸，似乎也并不是CAP理論中所描述的那種原因造成的。那么，上述流行的說法中所描述的關系型數據庫為保證C、A而犧牲P到底是在指什么呢？

因此，如果根據現有的大多數資料對CAP理論的如上解釋，即只將其當作分布式系統中多個數據副本之間的讀寫一致性問題的通用理論對待，那么就可以得出結論：CAP既適用于NoSQL數據庫，也適用于關系型數據庫。它是NoSQL數據庫、關系型數據庫，乃至一切分布式系統在設計數據多個副本之間讀寫一致性問題時需要遵循的共同原則。

更深入的探究：兩種重要的分布式場景

在本文中我們要說的重點與核心是：關于對CAP理論中一致性C的理解，除了上述數據副本之間的讀寫一致性以外，分布式環境中還有兩種非常重要的場景，如果不對它們進行認識與討論，就永遠無法全面地理解CAP，當然也就無法根據CAP做出正確的解釋。但可惜的是，目前為止卻很少有人提及這兩種場景：那就是事務與關聯。

先來看看分布式環境中的事務場景。我們知道，在關系型數據庫的事務操作遵循ACID原則，其中的一致性C，主要是指一個事務中相關聯的數據在事務操作結束后是一致的。所謂ACID原則，是指在寫入/異動資料的過程中，為保證交易正確可靠所必須具備的四個特性：即原子性（Atomicity，或稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）和持久性（Durability）。

例如銀行的一個存款交易事務，將導致交易流水表增加一條記錄。同時，必須導致賬戶表余額發生變化，這兩個操作必須是一個事務中全部完成，保證相關數據的一致性。而前文解釋的CAP理論中的C是指對一個數據多個備份的讀寫一致性。表面上看，這兩者不是一回事，但實際上，卻是本質基本相同的事物：數據請求會等待多個相關數據操作全部完成才返回。對分布式系統來講，這就是我們通常所說的分布式事務問題。

眾所周知，分布式事務一般采用兩階段提交策略來實現，這是一個非常耗時的復雜過程，會嚴重影響系統效率，在實踐中我們盡量避免使用它。在實踐過程中，如果我們為了擴展數據容量將數據分布式存儲，而事務的要求又完全不能降低。那么，系統的可用性一定會大大降低，在現實中我們一般都采用對這些數據不分散存儲的策略。

當然，我們也可以說，最常使用的關系型數據庫，因為這個原因，擴展性（分區可容忍性P）受到了限制，這是完全符合CAP理論的。但同時我們應該意識到，這對NoSQL數據庫也是一樣的。如果NoSQL數據庫也要求嚴格的分布式事務功能，情況并不會比關系型數據庫好多少。只是在NoSQL的設計中，我們往往會弱化甚至去除事務的功能，該問題才表現得不那么明顯而已。

因此，在擴展性問題上，如果要說關系型數據庫是為了保證C、A而犧牲P，在盡量避免分布式事務這一點上來看，應該是正確的。也就是說：關系型數據庫應該具有強大的事務功能，如果分區擴展，可用性就會降低；而NoSQL數據庫干脆弱化甚至去除了事務功能，因此，分區的可擴展性就大大增加了。

再來看看分布式環境中的關聯場景。初看起來，關系型數據庫中常用的多表關聯操作與CAP理論就更加不沾邊了。但仔細考慮，也可以用它來解釋數據庫分區擴展對關聯所帶來的影響。對一個數據庫來講，采用了分區擴展策略來擴充容量，數據分散存儲了，很顯然多表關聯的性能就會下降，因為我們必須在網絡上進行大量的數據遷移操作，這與CAP理論中數據副本之間的同步操作本質上也是相同的。

因此，如果要保證系統的高可用性，需要同時實現強大的多表關系操作的關系型數據庫在分區可擴展性上就遇到了極大的限制（即使是那些采用了各種優秀解決方案的MPP架構的關系型數據庫，如TeraData，Netezza等，其水平可擴展性也是遠遠不如NoSQL數據庫的），而NoSQL數據庫則干脆在設計上弱化甚至去除了多表關聯操作。那么，從這一點上來理解“NoSQL數據庫是為了保證A與P，而犧牲C”的說法，也是可以講得通的。當然，我們應該理解，關聯問題在很多情況下不是并行處理的優點所在，這在很大程度上與Amdahl定律相符合。

所以，從事務與關聯的角度來關系型數據庫的分區可擴展性為什么受限的原因是最為清楚的。而NoSQL數據庫也正是因為弱化，甚至去除了像事務與關聯（全面地講，其實還有索引等特性）等在分布式環境中會嚴重影響系統可用性的功能，才獲得了更好的水平可擴展性。

那么，如果將事務與關聯也納入CAP理論中一致性C的范疇的話，問題就很清楚了：關于“關系型數據庫為了保證一致性C與可用性A，而不得不犧牲分區可容忍性P”的說法便是正確的了。但關于“NoSQL選擇了C與P，或者A與P”的說法則是錯誤的，所有的NoSQL數據庫在設計策略的大方向上都是選擇了A與P（雖然對同一數據多個副本的讀寫一致性問題的設計各有不同），從來沒有完全選擇C與P的情況存在。

結論

現在看來，如果理解CAP理論只是指多個數據副本之間讀寫一致性的問題，那么它對關系型數據庫與NoSQL數據庫來講是完全一樣的，它只是運行在分布式環境中的數據管理設施在設計讀寫一致性問題時需要遵循的一個原則而已，卻并不是NoSQL數據庫具有優秀的水平可擴展性的真正原因。而如果將CAP理論中的一致性C理解為讀寫一致性、事務與關聯操作的綜合，則可以認為關系型數據庫選擇了C與A，而NoSQL數據庫則全都是選擇了A與P，但并沒有選擇C與P的情況存在。這才是用CAP理論來支持NoSQL數據庫設計正確認識。

其實，這種認識正好與被廣泛認同的NoSQL的另一個理論基礎相吻合，即與ACID對著干的BASE（基本可用性、軟狀態與最終一致性）。因為BASE的含義正好是指“NoSQL數據庫設計可以通過犧牲一定的數據一致性和容錯性來換取高性能的保持甚至提高”，即NoSQL數據庫都應該是犧牲C來換取P，而不是犧牲A?？捎眯訟正好是所有NoSQL數據庫都普遍追求的特性。

本文題目：nosqlcap原則,nosql cap理論
標題URL：http://m.newbst.com/article8/dssgoip.html

成都網站建設公司_創新互聯，為您提供網站收錄、靜態網站、商城網站、企業建站、響應式網站、動態網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯