雷獸的數(shù)據(jù)庫CAP亂談之（一）闡述

今天有人問我cap，找了https://my.oschina.net/lilw/blog/169776這片文字，

下面是cap那篇文字的解釋：

所謂CAP理論，即：

Cosistency?????? 數(shù)據(jù)的一致性

Availability????? 高可用性

Tolerance to newowrk Partitions??? 分區(qū)容忍性

?

一個數(shù)據(jù)存儲系統(tǒng)不可能同時滿足上述三個特性，只能同時滿足其兩個特性，也就是： CA,CP,AP。可以這么說，當(dāng)前所有的數(shù)據(jù)存儲解決方案，都可以歸類的上述三種類型。

CA? 滿足數(shù)據(jù)的一致性和高可用性，但沒有可擴(kuò)展性，如傳統(tǒng)的關(guān)系型數(shù)據(jù)，基本上滿足是這個解決方案，如ORACLE , MYSQL 的單節(jié)點(diǎn)，滿足數(shù)據(jù)的一致性和高可用性。

CP? 滿足數(shù)據(jù)的一致性和分區(qū)性，如Oracle RAC ，Sybase 集群。雖然Oracle RAC具備一點(diǎn)的擴(kuò)展性，但當(dāng)節(jié)點(diǎn)達(dá)到一定數(shù)目時，性能（也即可用性）就會下降很快，并且節(jié)點(diǎn)之間的網(wǎng)絡(luò)開銷很在在，需要實(shí)時同步各節(jié)點(diǎn)之間的數(shù)據(jù)。

AP 在性能和可擴(kuò)展性方面表現(xiàn)不錯，但在數(shù)據(jù)一致性方面會用犧牲，各節(jié)點(diǎn)的之間數(shù)據(jù)同步?jīng)]有哪么快，但能保存數(shù)據(jù)的最終一致性。當(dāng)前熱炒的NOSQL大多類是典型的AP類型數(shù)據(jù)庫。

以上是原文內(nèi)容；

我卻覺這解釋有點(diǎn)不完全敢茍同，按照這篇文字第一條ca組合下的描述，這個高可用性我認(rèn)為應(yīng)該是魯棒性，

我跟這個所謂數(shù)據(jù)庫的魯棒性，就是比如在同一個實(shí)例同一個庫的數(shù)據(jù)庫，不管你是單表還是多表join，想怎么讀怎么寫都不是問題，我認(rèn)為說這是可用性，很是牽強(qiáng)，因?yàn)?/p>

?cap百度百科的解釋如下：

分布式系統(tǒng)的CAP理論：理論首先把分布式系統(tǒng)中的三個特性進(jìn)行了如下歸納：
● 一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本） ● 可用性（A）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性） ● 分區(qū)容錯性（P）：以實(shí)際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。 在那篇文字里提到ca只有單節(jié)點(diǎn)如何，很明顯單節(jié)點(diǎn)根本不可能保證故障后還可讀寫，所以可用性是分布式的可用性，不是各種都支持的可用性，也就是我說的魯棒性；很多人不知道在數(shù)據(jù)分片以后哪些能做哪些不能做，這就是分布式下相對于單實(shí)例數(shù)據(jù)庫有諸多魯棒性的限制； 下面闡述我個人理解的正文： cap??是數(shù)據(jù)分散存儲?不在同一個實(shí)例里的時候的?產(chǎn)生的問題
我這里說的cap既可能是sql下所謂的?可以叫?偽分布式集群的cap，當(dāng)然還包括nosql集群的cap，
讓后其實(shí)還講到了在大的分布式意義下 某個小規(guī)模下的非分布式 ?也就是分片節(jié)點(diǎn)本身??數(shù)據(jù)100%冗余?全庫冗余的情況下 ?也就是只有一個分片；
首先 在上面說的這種整個集群單一分片的情況下 ?分多種情況 ?比如包括 ?主從?主備??多主
主從就是線上備份???從默認(rèn)不能寫??但是主掛了不自動切換??原始的各種數(shù)據(jù)庫同步技術(shù)就是這種了??你是否利用從庫來做讀的加速?是你自己處理
主備?是主從加上了自動切換??
多主 差不多相當(dāng)于是把主備的方式反過來??同時也讓備同步到主 雙向考慮
這里還有個問題就是?同步復(fù)制還是異步復(fù)制

異步復(fù)制以及同步復(fù)制發(fā)送延遲過大造成了本質(zhì)上的異步的瞬間問題點(diǎn)的時候
簡單的可以認(rèn)為是分布式數(shù)據(jù)存儲時候的最簡單最基本的靜態(tài)狀態(tài)下，這是我自己的話，也就是指整個數(shù)據(jù)庫集群 就只有一個分片 ?每個節(jié)點(diǎn)100%數(shù)據(jù)冗余的情況，暫且把這種情況叫做靜態(tài)的分布式數(shù)據(jù)庫集群模式
在這種靜態(tài)中的cap?（以下字母我就不分了?反正?內(nèi)容就是那三個：數(shù)據(jù)一致性，高可用，分區(qū)容忍性）

數(shù)據(jù)一致性?應(yīng)該是同內(nèi)容的鏡像分片之間的數(shù)據(jù)一致與否的問題?就是異步復(fù)制?和?同步復(fù)制延時過大???這個問題在很多事務(wù)級同步的sql方案里不存在了??但是并非100%不會出現(xiàn)
高可用??這個分布式里的數(shù)據(jù)還是容器都一樣??跟上面那個一樣同一份數(shù)據(jù)或者同一個功能節(jié)點(diǎn)是否有冗余?是否高可用自動切換??這里為了魯棒性??其實(shí)應(yīng)該默認(rèn)和數(shù)據(jù)一致性同在??只有主備節(jié)點(diǎn)數(shù)據(jù)實(shí)時同步??并不會有數(shù)據(jù)一致性問題???才真正有高可用的意義，其實(shí)目前很多高可用方案?其實(shí)并非如此??具體技術(shù)??就要自己去了解
分區(qū)容忍性?這個在靜態(tài)角度看好像并不存在
魯棒性 ?在這種靜態(tài)情況下 ?能夠做到最接近單一節(jié)點(diǎn)的魯棒性

然后動態(tài)來看??就是數(shù)據(jù)不在一個物理分片上了??就是認(rèn)為??基本做不了高性能的join的這種情況 或者說 模式
數(shù)據(jù)一致性??因?yàn)椴还馐侨珨?shù)據(jù)鏡像???還有同一個事務(wù)上下文在不同實(shí)例時候?因?yàn)槠胀ㄊ聞?wù)無法維系???而產(chǎn)生的問題通常?這個分布式數(shù)據(jù)系統(tǒng)都做不到?或者不能良好做到?比如mysql的?xa協(xié)議分布式事務(wù)??sqlserver的?基于dtc?分布式事務(wù)??這些性能?有限?隨擴(kuò)展后?性能下降更加明顯??而在nosql里?基本就壓根不支持跨節(jié)點(diǎn)事務(wù)??因?yàn)橹С至诉@個???節(jié)點(diǎn)擴(kuò)展?問題就非常嚴(yán)重了??也就是數(shù)據(jù)一致性降低了可分片的空間和意義
高可用?某個節(jié)點(diǎn)的可用性??還是要在一致性??也就是同步復(fù)制還是異步復(fù)制中尋找平衡???可以想象?你怎么在保證redis每秒20w?tps?（redis單線程set?有set就當(dāng)是tps吧）???然后再保證有一個從節(jié)點(diǎn)能100%的同步復(fù)制???不掉數(shù)據(jù)？理論上可行??但是很多現(xiàn)實(shí)情況下??做不到
分區(qū)容忍性??其實(shí)是分布式的基礎(chǔ)吧??這里我要說的是?oltp?olap?問題???分區(qū)容忍性其實(shí)幾乎100%的跟olap不合??至少挺難的??oltp簡單一些?歸結(jié)一點(diǎn)就是??單數(shù)據(jù)實(shí)例上各種操作的魯棒性?在分區(qū)情況下?接近完全喪失 魯棒性 在這種模式的情況下 魯棒性就大大降低了 ?不能跨節(jié)點(diǎn)join ?甚至做個排序分頁 都未必能簡單高效的完成 ?但是可以應(yīng)對設(shè)計(jì)良好的大吞吐 oltp 基本最高性能的只有單表查詢 或者按key查詢 所以 ?cap 還有魯棒性r（Robust，注意這里的魯棒性已經(jīng)不是Robust的原意，而是方便無腦不會出問題的意思）的認(rèn)識，加上對一種集群技術(shù)、方式方案組合都必須考慮清楚。 posted on 2016-11-19 23:37 雷獸 閱讀(...) 評論(...) 編輯 收藏

轉(zhuǎn)載于:https://www.cnblogs.com/sfissw/p/6081867.html

總結(jié)

以上是生活随笔為你收集整理的雷兽的数据库CAP乱谈之（一）阐述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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