雷獸的數據庫CAP亂談之（一）闡述

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

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

所謂CAP理論，即：

Cosistency?????? 數據的一致性

Availability????? 高可用性

Tolerance to newowrk Partitions??? 分區容忍性

?

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

CA? 滿足數據的一致性和高可用性，但沒有可擴展性，如傳統的關系型數據，基本上滿足是這個解決方案，如ORACLE , MYSQL 的單節點，滿足數據的一致性和高可用性。

CP? 滿足數據的一致性和分區性，如Oracle RAC ，Sybase 集群。雖然Oracle RAC具備一點的擴展性，但當節點達到一定數目時，性能（也即可用性）就會下降很快，并且節點之間的網絡開銷很在在，需要實時同步各節點之間的數據。

AP 在性能和可擴展性方面表現不錯，但在數據一致性方面會用犧牲，各節點的之間數據同步沒有哪么快，但能保存數據的最終一致性。當前熱炒的NOSQL大多類是典型的AP類型數據庫。

以上是原文內容；

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

我跟這個所謂數據庫的魯棒性，就是比如在同一個實例同一個庫的數據庫，不管你是單表還是多表join，想怎么讀怎么寫都不是問題，我認為說這是可用性，很是牽強，因為

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

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

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

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

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

轉載于:https://www.cnblogs.com/sfissw/p/6081867.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。