傳統(tǒng)關系型數(shù)據(jù)庫中事務有四個重要的特性，簡稱ACID，即

• 原子性?： 事務是一個不可分割的工作單位，事務中的操作要么都成功，如果有一個執(zhí)行失敗，所有的SQL將都被撤銷，恢復到事務開始的狀態(tài)
• 一致性?： 事務前后數(shù)據(jù)的完整性必須保持一致。 例如轉(zhuǎn)賬前AB兩賬戶金額之和是2000元，事務結(jié)束后，金額之和仍然是2000元
• 隔離性：當多個用戶并發(fā)的訪問數(shù)據(jù)庫時，數(shù)據(jù)庫為每一個用戶開啟的事務之間是隔離的，一個事務不能被其他事務的操作所干擾
• 持久性?： 持久性是指一個事務一旦被提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就是永久性的，接下來即使數(shù)據(jù)庫發(fā)生故障也不應該對其有任何影響 ， 即使發(fā)生系統(tǒng)崩潰，重新啟動數(shù)據(jù)庫系統(tǒng)后，數(shù)據(jù)庫還能恢復到事務成功結(jié)束時的狀態(tài)。

NoSql出現(xiàn)在關系型數(shù)據(jù)庫之后，主要是為了解決關系型數(shù)據(jù)庫的短板，我們先來看看隨著軟件行業(yè)的發(fā)展，關系型數(shù)據(jù)庫面臨了哪些挑戰(zhàn)：

????? 1、高并發(fā)

????? 一個最典型的就是電商網(wǎng)站，例如雙11，幾億大軍的點擊造成在某一時刻的并發(fā)量是很高的，傳統(tǒng)的關系型數(shù)據(jù)庫肯定已經(jīng)是不堪重負了，如Oracle的Session數(shù)量推薦的才只有500。

????? 2、高效率存儲海量數(shù)據(jù)

????? 大數(shù)據(jù)時代，數(shù)據(jù)量已經(jīng)不是用GB、TB來衡量了，而是EB、ZB了，面對這海量的數(shù)據(jù)，如何高效率的存儲這些數(shù)據(jù)，關系型數(shù)據(jù)庫無法解決這個問題，以Oracle為例，單機的物理擴展不僅成本高，而且難度也加大了。

????? 3、高可用&高擴展

????? Oracle即使RAC能擴展數(shù)臺機器，但數(shù)量也是有限。

????? NoSql的出現(xiàn)即是為了解決這些問題了，但是NoSql并不是用來替代關系型數(shù)據(jù)庫的，因為它本身也有著不可克服的缺陷（當然也不影響總有挑戰(zhàn)者，manggo就宣稱他們要替代關系型數(shù)據(jù)庫，但是在強一致的情況下是非常困難的）。

CAP理論是Brewer教授提出的：一個分布式系統(tǒng)不能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯性（Tolerance of network Partition）。

? ? ???一致性：任何一個讀操作總是能讀取到之前完成的寫操作結(jié)果，也就是在分布式環(huán)境中，多點的數(shù)據(jù)是一致的。

??????可用性：每一個操作總是能在確定的時間內(nèi)返回，也不是系統(tǒng)隨時都是可用的。

??????分區(qū)容錯性：在出現(xiàn)網(wǎng)絡分區(qū)（如斷網(wǎng)）的情況下，分離的系統(tǒng)也能正常運行。

? ? ?不能同時滿足CAP的原因是因為分布式系統(tǒng)中必須滿足P，也就是分區(qū)容錯性的原因，因為可能出現(xiàn)網(wǎng)絡通信失敗。假設此時分布式系統(tǒng)中有兩臺服務器N1 N2，假設N1和N2之間通信的時候網(wǎng)絡突然出現(xiàn)故障，有用戶向N1發(fā)送數(shù)據(jù)更新請求，那N1中的數(shù)據(jù)DB0將被更新為DB1，由于網(wǎng)絡是斷開的，N2中的數(shù)據(jù)庫仍舊是DB0；如果這個時候，有用戶向N2發(fā)送數(shù)據(jù)讀取請求，由于數(shù)據(jù)還沒有進行同步（一致性），應用程序沒辦法立即給用戶返回最新的數(shù)據(jù)DB1，怎么辦呢？有二種選擇，第一，犧牲數(shù)據(jù)一致性，響應舊的數(shù)據(jù)DB0給用戶；第二，犧牲可用性，阻塞等待，直到網(wǎng)絡連接恢復，數(shù)據(jù)更新操作完成之后，再給用戶響應最新的數(shù)據(jù)DB1。以上就是不能同時滿足CAP的原因

CAP的選擇策略

????而市場上的NoSql則以CAP理論為指導，大多選擇實現(xiàn)了CAP理論的兩點（如CA（關系型數(shù)據(jù)庫如mysql、AP(nosql數(shù)據(jù)庫manggo)、CP（如zk）），未實現(xiàn)的即其缺陷部分。所以我們經(jīng)常mysql很少看到分片集群，即使是做集群方案也會十分復雜，而nosql如manggo、es等往往是以集群形式存在，而cp相對來說較少。

常見NoSql的分類

類型	部分代表	特點
列存儲	Hbase Cassandra Hypertable	顧名思義，是按列存儲數(shù)據(jù)的。最大的特點是方便存儲結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，方便做數(shù)據(jù)壓縮，對針對某一列或者某幾列的查詢有非常大的IO優(yōu)勢。
文檔存儲	MongoDB CouchDB	文檔存儲一般用類似json的格式存儲，存儲的內(nèi)容是文檔型的。這樣也就有有機會對某些字段建立索引，實現(xiàn)關系數(shù)據(jù)庫的某些功能。
kv存儲	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis	可以通過key快速查詢到其value。一般來說，存儲不管value的格式，照單全收。（Redis包含了其他功能）
圖存儲	Neo4J FlockDB	圖形關系的最佳存儲。使用傳統(tǒng)關系數(shù)據(jù)庫來解決的話性能低下，而且設計使用不方便。
對象存儲	db4o Versant	通過類似面向?qū)ο笳Z言的語法操作數(shù)據(jù)庫，通過對象的方式存取數(shù)據(jù)。
xml數(shù)據(jù)庫	Berkeley DB XML	高效的存儲XML數(shù)據(jù)，并支持XML的內(nèi)部查詢語法，比如XQuery,Xpath。

妥協(xié)的藝術：最終一致性

為了解決關系型數(shù)據(jù)庫由于一致性導致的可用性降低的問題的解決方案,是基本可用，軟形態(tài)，最終一致性的縮寫，思路是放松對某一時刻一致性的要求來換取可用性和系統(tǒng)帶的性能，等該時刻過去之后，再保證最終數(shù)據(jù)一致性，例如淘寶雙11的瀏覽量，等等這些數(shù)據(jù)，在0點時刻不關注這些數(shù)據(jù)，盡可能為可用性服務，保證服務器不崩，等高峰期過后，比如說第二天，再將這些數(shù)據(jù)同步，完成最終一致性。

總結(jié)

以上是生活随笔為你收集整理的「数据库系列四」分布式数据库CAP理论与最终一致性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。