關於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理論依然成立。
再來看相互關聯資料的可分布性，這就涉及到了分布式事務。現有的newsql
資料庫，即使在同一資料中心，為了保證強的分布式事務，對效率的折衷都是不可忽略的，所謂的樂觀事務，只是因為客觀問題本身衝突就少，並不改變衝突很多時效率明顯受影響的現實。因此，newsql資料庫雖然提供強分布式事務的能力，但在現實應用中，都是提倡盡量避免大量的分布式事務出現。如果你所遇到的應用場景是確實需要大量的分布式事務執行，又不做應用優化全交給資料庫執行，那麼，現有的newsql分布式資料庫，依然會遇到明顯的效能問題，其實就是可用性a降低了。同學仔細去研究應用中的實際情況就會發現，很多網際網路應用，當其所需要的qps很高很高，而對讀寫一致性與強分布式事務的要求又不那很高時候，其實，newsql資料庫還是不能滿足他們的需求的，他們仍然需要根據自己的情況改造或者選用nosql資料庫，這也是cap理論並沒有被newsql打破的現實證明。
因此，總結來講，newsql資料庫，也是遵循cap理論的，只不過，在同中心資料多副本情況下，保證p的同時對a的影響微乎其微；而在分布式事務的情況下，又採用了與應用特性相關的策略（其實樂觀、悲觀事務本質上就有根本應用特性區分的意思）來保證效能而已。當然，隨著網路與計算機效能的提高，cap三個特徵中，保證其中兩個，折衷另外乙個，所帶來的影響也會逐漸變小，但其理論依然是正確的。
NewSQL 常用NewSQL資料庫梳理
很多企業都需要處理來自多個資料來源的複雜資料，因此需要利用資料庫管理系統來儲存和管理資料。現在，有很多不同型別的資料庫系統，而找到乙個正確的資料庫不是一件容易的事。這需要考慮業務需求，以便選擇正確的資料庫管理系統。企業使用關聯式資料庫管理系統 rdbms 來儲存和管理他們的資料。然而，這些系統無法處...
NewSQL資料庫壓力測試工具系列 TPCC
前兩篇文章向大家介紹了sysbench和ycsb兩個開源效能基準測試工具，這兩個工具著重於對資料庫進行產品級基本的 與業務和應用無關的壓力測試。在這篇文章中將向大家介紹在傳統關係型資料庫領域中存在的以假想的零售業務為基礎的tpc c效能測，並介紹基於sysbench的乙個開源工具sysbench t...
java canal對於資料庫配置
現場部署專案時候出現問題，排查時候發現是canal啟動失敗 2019 03 15 11 47 38.486 destination example address 127.0.0.1 3306 eventparser error c.a.o.c.p.inbound.mysql.rds.rdsbinl...