CAP 定理

作者：Legy
链接：https://zhuanlan.zhihu.com/p/688095404
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
 

https://book.douban.com/subject/30335935/

软件体系结构

架构定义：软件架构指软件系统的顶层结构

程序员最愿意画的方框框图、一层一层、一块块的...

目的

架构设计是为了解决软件复杂度

设计不当会带来的软件危机

软件危机最典型的例子莫过于 IBM 的 System/360 的操作系统开发。佛瑞德·布鲁克斯（Frederick P. Brooks, Jr.）作为项目主管，率领 2000 多个程序员夜以继日地工作，共计花费了 5000 人一年的工作量，写出将近 100 万行的源码，总共投入 5 亿美元，是美国的“曼哈顿”原子弹计划投入的 1/4。

IBM 的 System/360

尽管投入如此巨大，但项目进度却一再延迟，软件质量也得不到保障。布鲁克斯后来基于这个项目经验而总结的《人月神话》一书，成了畅销的软件工程书籍。

人月神话

为了解决诸多类似的问题，在 1968、1969 年连续召开两次著名的 NATO 会议，会议正式创造了“软件危机”一词，并提出了针对性的解决方法“软件工程”。现如今软件工程已经成为一个大学专业。

架构设计是为了解决软件复杂度，那么复杂度的来源又有什么？

1.追求高性能带来的复杂度：

单台计算机内部为了高性能带来的复杂度(缓存组建、算法的设计)；另一方面是多台计算机集群为了高性能带来的复杂度(分布式集群)

2.追求高可用带来的复杂度：

系统的高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用。

3.追求可扩展性

假设架构师经验非常丰富，目光非常敏锐，看问题非常准，所有的变化都能准确预测，是否意味着可扩展性就很容易实现了呢？也没那么理想！因为预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。即使预测很准确，如果方案不合适，则系统扩展一样很麻烦。

第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。也对应着设计模式中的 开 闭 原 则。

例如，如果系统需要支持 XML、JSON、ProtocolBuffer 三种接入方式，那么最终的架构就是上面图中的“形式 1”架构

对于哪些属于变化层，哪些属于稳定层，很多时候并不是像前面的示例（不同接口协议或者不同数据库）那样明确，不同的人有不同的理解，导致架构设计评审的时候可能吵翻天！！！从大的角度来开，对于跨部门一起实现一个系统，处于责任边界的变化层的往往也是争论的焦点。从小的角度来看，可能涉及到一个接口内参数的必要性讨论。

所以 去评估性能要求、可用要求以及可扩展性的要求，是在架构前必须要做的事情。尤其是第三点，区别于其他领域的要求

建筑上的桥梁设计，基本不会考虑未来的可扩展性。

三原则

合适原则“合适优于业界领先”

罗马不是一天建成的。

优秀的技术人员都有很强的技术情结，当他们做方案或者架构时，总想不断地挑战自己，想达到甚至优于业界领先水平是其中一个典型表现，因为这样才能够展现自己的优秀，才能在年终 KPI 绩效总结里面骄傲地写上“设计了 XX 方案，达到了和 Google 相同的技术水平”“XX 方案的性能测试结果大大优于阿里集团的YY 方案”。但现实是，大部分这样想和这样做的架构，最后可能都以失败告终！

简单原则“简单优于复杂”

less is more

苹果的设计风格以简洁为核心，尽量减少不必要的元素和干扰

避免结构上的复杂性，结构上的复杂性存在的第一个问题是，组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。这个概率可以算出来，假设组件的故障率是 10%（有 10% 的时间不可用），那么有 3 个组件的系统可用性是（1-10%）×（1-10%）×（1-10%）= 72.9%，有 5 个组件的系统可用性是（1-10%）×（1-10%）×（1-10%）×（1-10%）×（1-10%）=59%，两者的可用性相差 13%。

某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件。

演化原则 “演化优于一步到位”

生物要适应当时的环境。其次，生物需要不断地繁殖，将有利的基因传递下去，将不利的基因剔除或者修复。第三，当环境变化时，生物要能够快速改变以适应环境变化；如果生物无法调整就被自然淘汰；新的生物会保留一部分原来被淘汰生物的基因。

软件架构设计同样是类似的过程：首先，设计出来的架构要满足当时的业务需要。其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。

通用的架构流程【复杂度识别>方案备选>方案评估>详细设计】具体操作为【略】

CAP 理论

CAP 定理（CAP theorem）又被称作布鲁尔定理（Brewer's theorem），是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的ACM PODC 上提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。对于设计分布式系统的架构师来说，CAP 是必须掌握的理论。布鲁尔在提出 CAP 猜想的时候，并没有详细定义 Consistency、Availability、Partition Tolerance 三个单词的明确定义，因此如果初学者去查询 CAP 定义的时候会感到比较困惑，因为不同的资料对 CAP 的详细定义有一些细微的差别。

在此选的是公认较多的第二版定义

在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

一致性（Consistence）

A read is guaranteed to return the most recent write for a given client.简单翻译为：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。

可用性（Availability

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).简单翻译为：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。

分区容错性（Partition Tolerance）

The system will continue to function when network partitions occur.简单翻译为：当出现网络分区后，系统能够继续“履行职责”。

虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择CP 或者 AP 架构。

编辑于 2024-03-21 16:19