用太极拳讲分布式理论，真舒服！

作者： 悟空聊架构 2020-12-31 05:32:08

开发

前端

分布式 倚天屠龙记中赵敏郡主携带一帮高手围攻武当，武当派掌门张三丰被暗算，传了一套武功给张无忌用来对付赵敏的手下。这套武功就是太极拳。

为丰林等地区用户提供了全套网页设计制作服务，及丰林网站建设行业解决方案。主营业务为成都网站建设、成都做网站、丰林网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

[[361252]]

倚天屠龙记中赵敏郡主携带一帮高手围攻武当，武当派掌门张三丰被暗算，传了一套武功给张无忌用来对付赵敏的手下。这套武功就是太极拳。

张三丰：无忌，我教你的还记得多少?

张无忌：我全忘了!

张三丰：很好，你只要记住把玄冥二老打趴下就可以了。

[[361253]]

上篇用三国杀讲分布式中的拜占庭将军问题，还挺有意思的，这次我们用倚天屠龙记中的太极拳来聊下剩下的三大理论：

• CAP 理论
• ACID 理论
• BASE 理论

太极拳的精髓：以柔克刚，刚柔并进，四两拨千斤，无招胜有招。

我把 CAP 理论称作太极，ACID 理论称为阳或刚，BASE 理论称为阴或柔。ACID 理论追求一致性，BASE 理论本来就叫做柔性事务，追求的是可用性。那张无忌为什么会全忘了还打败了玄冥二老呢?因为太极拳的精髓是拳意，无招胜有招。

1、太极的两面

CAP 理论是对分布式系统的特性做了一个高度的抽象，变成了三大指标：

• 一致性(Consistency)
• 可用性(Availability)
• 分区容错性(Partition Tolerance)

分布式中的一致性，我们可以理解为客户端的每次读操作，不管访问的是哪个几点，要么读到的都是同一份最新写入的数据，要么读取失败。这就很刚了，不能说这种刚不好，在很多场景中，也确实需要保证高度的一致性。

为了帮助大家理解一致性，我举个倚天屠龙记的故事：六大派围攻光明顶。

[[361254]]

峨眉派灭绝师太作为统领，带领江湖六大派围攻光明顶，最开始的进攻策略是从北边进攻。灭绝师太发现从北边进攻不妙，于是飞鸽传书给武当派和少林派从南边进攻的命令，但是少林派的飞鸽被明教轻功绝顶的青翼蝠王韦一笑截获了，最后的结果是少林派从北边进攻，武当派从南边进攻，这不就乱套了吗?如下图所示：

围攻光明顶

1.1 理解分布式中的 CAP

CAP 放到分布式系统中该如何理解呢?下面举个例子帮助大家理解。

初始环境：客户端查询或更新节点 1 和 节点 2，两个节点存的值 A = 1。

初始环境

客户端更新节点 1 中 A 的值，设置 A = 5。

客户端更新节点 1

节点 1 将 A 的值更新为 5 后，返回更新成功给客户端。

节点 1 返回更新成功

客户端访问到了节点 2 ，请求获取 A 的值，结果返回 A = 1。这和节点 1 中存储的 A 的值就不一致了。

客户端访问到节点 2

那么怎么保证两个节点中的值都是 A = 5 呢?客户端将节点 1 更新后，节点 2 也需要更新，才能告诉客户端更新成功了。

节点 2 也需要更新

两个节点都更新成功后，客户端访问其中任意一个节点获取到的都是 A = 5。这个就叫做一致性。

两个节点都更新后

一致性强调的是数据正确，每次读取节点中的数据都是最新写入的数据。这个我称作刚。

但是我们生产的集群环境下如果发生分区故障时(节点失联，节点无法响应，节点无法写入数据)，客户端查询节点时，我们不能返回错误信息给客户端。比如说业务集群中的一些关键系统，如注册中心，不能因为某个节点失联了，就不响应最新的数据。那么相关的业务也获取不到正确的注册信息而导致系统瘫痪。

可用性就派上用场了，牺牲数据准确性，每个节点使用本地数据来响应客户端的请求。另外当节点不可用时，可以使用快速失败策略，至少不能让服务长时间不能响应。可用性强调的是服务可用，不保证数据正确。这个我称作柔。

如下图所示：节点 1 和节点 2 返回给客户端的值分别是 A = 5 和 A = 1，也就是节点 1 和 节点 2 并没有保证数据一致性，而是考虑了节点的可用性。

数据不一致

分区容错性的含义就是节点间出现任意数量的消息丢失或高延迟的时候，系统仍然在继续工作。分布式系统告诉客户端，我的内部不论出现什么样的数据同步问题，我会一直运行。强调的是集群堆分区故障的容错能力。

1.2 CAP 三角

那么这三个指标又有什么关系呢?这个就是我们经常听到的 CAP 理论。C 代表一致性(Consistency)，A 代表可用性(Availability)、P 代表分区容错性(Partition Tolerance)。

对于分布式系统，CAP 三个指标只能选择其中两个。

CA：保证一致性和可用性。当分布式系统正常运行时(大部分时候所处的状态)，这个时候不需要 P，那么 C 和 A 能够同时保证。只有在发生分区故障时，才需要 P，这个时候就只能在 C 和 A 之间做出选择。典型应用：单机版部署的 MySQL。

CP：保证数据的一致性和分区容错性，比如配置信息，必须保证每个节点存的都是最新的，正确的数据。比如 Raft 的强一致性系统，会导致无法执行读操作和写操作。典型应用：Etcd、Consul、Hbase。

AP：保证分布式系统的可用性和分区容错性。用户访问系统，都能得到相应数据，不会出现响应错误，但是可能会读到旧的数据。典型应用：Cassandra 和 DynamoDB。

2、太极的刚

2.1 ACID 的刚

最开始知道 ACID 是研究 SQL 数据库的时候，原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

这四个属性是针对事务而言的，而事务就是为单个工作单元而执行的一系列操作。如查询、修改数据、修改数据定义。

事务不仅仅只用在数据库上，还可以用在业务系统中，比如发券后扣减库存，这种业务场景可以定义为一个事务。单机场景我们可以通过加锁、时间序列等机制来保证单个节点上的 ACID 特性，但无法保证节点间操作的 ACID 特性。

那么分布式系统下该如何解决事务问题呢?这也是面试中经常遇到的题。分布式事务协议大家一定听过，比如二阶段提交协议和 TCC 协议，下面我还是用六大派围攻光明顶故事来讲解二阶段协议。

2.2 围攻光明顶

峨眉派想汇集少林派、武当派、昆仑派明天一起进攻光明顶。如果有一方不同意进攻，或者进攻时机不一致，则需要取消整个行动计划。少林派、武当派、昆仑派进攻光明顶这一组行动可以看成是一个分布式事务，要么全部执行、要么全部不执行。如下图所示：

那如何帮助灭绝师太解决这个协同问题?我们可以用二阶段提交协议来说明。

2.3 二阶段提交协议

在二阶段提交协议中，灭绝师太先给少林派发送进攻的消息，少林派作为协调者的身份，由少林派联系武当派和昆仑派是进攻还是撤退。

二阶段就是说有两个阶段，1.提交请求阶段(投票阶段)，2.提交执行阶段(完成阶段)。

阶段一：提交请求阶段：

第一步：少林派作为协调者分别给武当派和昆仑派发送消息：“明天进攻光明顶，可行?”

第二步：少林派、武当派、昆仑派分别评估明天是否能进攻光明顶，如果能，就预留时间并锁定，不再安排其他的进攻事项。

第三步：少林派得到全部的回复结果，包括少林派自己的评估结果。最后三方的结果都是可行。

如下图所示：

阶段一

阶段二：提交执行阶段：

第一步：少林派统计自己、昆仑派和武当派的消息，都是可以进攻，所以可以执行分布式事务，进攻光明顶。

第二步：少林派通知昆仑派和武当派进攻光明顶。

第三步：少林派、昆仑派、武当派召集手下弟子，进攻光明顶(执行事务)。

第四步：昆仑派、武当派将是否已发起进攻告诉少林派。

第五步：少林派汇总自己、昆仑派、武当派的进攻结果给灭绝师太。这样灭绝师太看到的就是统一的作战计划。

阶段二

注意：

• 可以将灭绝师太当做客户端。少林派、武当派、昆仑派当做分布式系统的三个节点。少林派作为协调者。
• 将评估是否能进攻光明顶以及预留时间可以理解为需要操作的对象和对象状态，是否已经准备好了，能否提交新的操作。
• 发送消息、飞鸽传书可以理解为网络消息。
• 第一个阶段中，每个参与者投票表决事务是放弃还是提交，一旦投票要求提交事务，那么就不允许放弃事务。
• 第二个阶段中，每个参与者执行最终统一的决定，提交事务或者放弃事务。这个就是 ACID 的原子性。
• 第一个阶段中，需要预留资源，预留期间，其他人不能操作这个资源。

2.4 二阶段协议带来的问题

ACID 特性是 CAP 中一致性的边界，可以称作最强的一致性，如果分布式系统中实现了一致性，必然会影响到可用性。如果一个节点失败，这个分布式事务的执行都是失败的。

绝大数场景中，对一致性要求没那么高，并不需要保证强一致性，短暂的不一致也能接收，最后能保证数据是正确的就OK。也就是说我们可以用最终一致性方案来保证数据的一致性。

另外要提到的就是 TCC 协议(三阶段提交协议)，他是针对二阶段提交中的：协调者故障，参与者长期锁定资源的痛点而出的协议。引入了询问阶段和超时机制，减少资源被长时间锁定。但是需要更多的消息进行协商，增加了系统负载和响应延迟，所以三阶段提交协议很少被使用。

3、太极的柔

3.1 BASE 的柔

讲了太极的刚，下面来讲太极的柔。谈到分布式事务的柔，一定会提到 BASE 理论，俗称柔性事务。BASE 理论是 CAP 理论中 AP 的扩展。大部分互联网分布式系统都强调可用性，都会考虑引入 BASE 支持。这个理论非常非常重要，我要告诉你的是，掌握了这个理论，设计出符合自己业务的分布式架构也会变得容易很多，而不是摸不着头脑。

BASE 的核心：基本可用 BA(Basically Available)、软状态 S(Soft state)、最终一致性 E(Eventually consistent)。

那为什么叫它柔性事务?其实它和 ACID 是相对的，不需要保证强一致性，比如一根橡皮筋被拉弯了，你放开橡皮筋后，它就会自行恢复，这个就是橡皮筋柔性的一面。

3.2 BASE 和太极拳有什么关系

太极拳每一招都不是直直的打出去的，每一招都讲求圆滑、画弧线，看起来软绵绵的，其实是柔中带刚。每一招的最后一下都是非常刚硬的抖动一下(这效果我用文字实在描述不出来，大家去看电视吧)。这最后一下就可以看成是刚的一面，也就是最终一致性。

[[361263]]

3.3 基本可用

怎么理解基本可用?重点是在这个基本，这个理论并没有告诉我们怎么定义基本，这是一个模糊的概念。其实就是要柔到什么程度。

在分布式系统中，我们可以把基本可用理解为保证核心功能可用，允许损失部分功能的可用性。基本可用可以用四种方案来实现。

流量削峰：比如多个秒杀场次，某东的 8 点秒杀场，12 点的秒杀场。

延迟响应：比如双 11 期间某商城创建的订单，会提示客户订单正在创建中，可能需要等个十几秒。

体验降级：比如某次比赛活动，有大量用户进活动页查看图片，这个时候，大量图片因为网络超时而无法显示，这个时候就可以考虑替换原有图片，返回清晰度没有那么高或图片比较小的图片。

过载保护：比如我们常用的消息队列占满了，可以考虑丢弃后来的请求，或清除队列中的一些请求，保护系统不过载，但这都需要结合自身的业务场景来设计。

3.4 最终一致性

最终一致性：系统中的所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。最终可以理解为一个短暂的延迟。

最终一致性在非常多的互联网业务中采用。但是跟钱打交道或金融系统会采用强一致性或事务。

前面提到了 ACID 的强一致性，而最终一致性和它是什么关系?

强一致性其实也是最终一致性的一种。那最终一致性怎么理解?强一致性可以看作不存在延迟的一致性。如果无法容忍延迟就用强一致性，否则就用最终一致性。

3.5 最终一致性和太极拳有什么关系

太极拳最神奇的一个地方就是卸力，当对方使出全力攻击你的时候，用太极的招式将对方使出的力量卸下来，使对方的攻击无效。卸力可以和我们之前讲到的流量削峰对应。另外卸完力之后，就是我们发动攻击的时候。

[[361264]]

4、无招胜有招

回到文章的开头，张三丰教给张无忌的太极拳，张无忌全忘了，还怎么能打败玄冥二老的呢?

因为太极拳重视的是拳意，而不是招式。所以张无忌领会了拳意，无招胜有招。

我们设计分布式系统的时候，也不要死记硬背三大理论，要真正懂得原理，然后才能一点一点迭代出最适合当前业务系统的分布式架构。

5、总结

• 太极拳分为阴和阳两方面，就如 CAP 中的 C 和 A。
• CAP 理论是分布式中基础理论，有三个重要指标：一致性、可用性、分区容错性。
• ACID 是传统数据库的设计理念，追求强一致性。四个指标：原子性、一致性、隔离性、持久性。是 CAP 中 CP 的延伸。
• BASE 理论是 CAP 中一致性和可用性权衡的结果。是 CAP 中的 AP 的延伸。注重可用性和性能优先，根据业务的场景特点，实现弹性的基本可用，然后实现数据的最终一致性。
• BASE 理论在很大程度上，解决了事务性系统在性能、容错、可用性等方面的通病。
• BASE 理论在 NoSQL 中应用广泛，是 NoSQL 系统设计的事实上的理论支撑。

文中也通过六大派围攻光明顶的案例给大家讲解了二阶段提交的核心原理，相信大家一定能看懂。

本文转载自微信公众号「悟空聊架构」，可以通过以下二维码关注。转载本文请联系悟空聊架构公众号。

新闻标题：用太极拳讲分布式理论，真舒服！
文章源于：http://www.gawzjz.com/qtweb/news39/182239.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联