《HCIA-openGauss V1.0 培训教材》的教案中包含关于NOSQL数据库CAP的内容, 教材中也提到NOSQL数据库的CAP原则。对于教程和考试来说，这一页相对并不是重点的内容。但每次到这一页又不肯略过，但要解释清楚CAP各自的概念以及相互之间的联系，总是要花费一番功夫的。
书归正传，先简单说下NOSQL里面的NO，它不是“ NO”的意思，而是“NOT ONLY（不只是）的缩写”。NOSQL和传统关系型数据库相比，最大的差异是数据以文档（非结构化或半结构化）形式存储，对事务（ACID）特性不支持或者不严格支持，不支持SQL语句操作数据库或者仅部分支持SQL语句操作数据库。此外分布式也是NOSQL数据库的一个基本需求。
在分布式系统中，CAP是一个基本原则：指的是分区容错性（P）,一致性（C）以及可用性（A）不能同时满足，要么是AP，要么是CP，要么是CA。有点抽象和拗口是不是？
直到有一天在电视上看到了《三国演义》中的精彩桥段：虎牢关三英战吕布。
先上图为敬：
这张图深刻的说明了三兄弟在战吕布时候各自发挥作用的高低
回到CAP，按教材上讲：分布式数据库系统一致性（C）、可用性（A）和分区容错行（P）不能完全同时满足。
C一致性：
指的是DML操作成功，同时返回客户端操作完成后，各节点的数据在同一时间严格一致。在三英战吕布的场景中，则要求刘关张哥仨能够有效配合，该攻时攻，该守时守，同时对吕布使出杀招，同一时间内武力输出完全一致。
A可用性：
指的是系统可以随时响应客户端的数据存取需求。对于户端的请求，都回一个及时、非错的响应，但不一定保证请求的结果都是最新写入的数据。也就是说刘关张哥仨作为一个系统的分区节点，和吕布对战时，对于吕布发起的每个回合，响应的都要有正确的攻防动作，可以保证持续输出，虽然不一定每次输出都是最佳。
P分区容错性：
明系统在物理上有隔离，不会因为某个节点的失败导致整个系统的不可用。从这个角度上，此处的吕布吕温侯就不符合分区容错性，虽说号称“马中赤兔，人中吕布”，毛泽东主席也说“一吕二赵三典韦”的吕布，绝对三国第一将，但一个人“浑身是铁能打几个钉子”？一招不慎就被张飞挑了紫金冠，没有容错性。不过我仔细搜了演义原文，发现老罗（贯中）并没有提到是被张飞打败。
“这三个围住吕布。转灯儿般厮杀。八路人马，都看得呆了。吕布架隔遮拦不定，看着玄德面上，虚刺一戟，玄德急闪。吕布荡开阵角，倒拖画戟，飞马便回。”
看来三国第一战将，也无法应付刘、关、张合力发起的业务高峰，这也说明单节点即使再高配，也还是有性能天花板和可用性的短板，也不方便扩容，一旦遭遇挂机就KO了。
反观刘关张哥仨，则满足分布式。在不需要满足强一致性（武力输出值完全一致）的情况下，就可满足一直可用，持续有武力输出，让这吕布没法休息，即使玄德公就武力来说，这个明显短板。日常的互联网业务，比如刷微博，刷朋友圈，并不要求所有人刷到的都是最新的，刷到的都一样；某宝某多多某东上架了新货物，也不需要所有的人都能立即刷到，只要求最终都能刷到就行，这就是所谓的最终一致性。
如果要求强一致性，那么就不能满足可用性。比如说玄德公如果累了要休息，只好哥仨一起休息会儿，玄德公的武力是60，关张也要从100下降到60了，这就不能满足高可用性了。
对于分布式系统来说，如果节点间的数据同步没有完成，则各个节点的该数据就都不允许访问，不允许出现节点间不一致的情况，必然导致可用性出现问题。
对于分布式数据库系统来说，P分区容错，是天然必备的，所以需要在A和C之间进行选择和平衡。就像刘关张天然的是三个人，这是天然的，所以也只能从“一直打，尽管输出不一定相同”和“打一会儿休息，等玄德公恢复了在继续打”之间进行抉择。
PS：看演义原文，觉得玄德公就是起了放走吕布的作用，由于玄德公的存在，吕布找到了突破口。果然木桶最短的板决定了木桶的容量。
本文尝试以“三英战吕布”的三国桥段对NOSQL数据库的CAP进行解释和说明，以帮助大家对CAP进行理解。诚然CAP和三国对战也存在着很大的区别，如存在不当之处，欢迎指正！
本文作者
本文内容来自于数据库领域资深技术专家赵锋老师，希望我们的文章正好能解决你的问题。
欢迎技术交流~