从0开始学架构_24_23_想成为架构师你必须掌握的CAP细节
你好，我是华仔。
今天我和你分享的主题是CAP的细节，以及与ACID base的对比。
理论的优点在于清晰、简洁、易于理解，但缺点就是高度抽象化，省略了很多细节导致。
在将理论应用到实践时，由于各种复杂情况可能出现误解和偏差，CAP理论也不例外。
如果我们没有意识到这些关键的细节点，那么在实践中应用CAP理论时，就可能发现方案很难落地。
而且当谈到数据一致性时，CAPACID base难免会被我们拿出来讨论，原因在于这三者都是和数据一致性相关的理论。
如果不仔细理解三者之间的差别，则可能会陷入一头雾水的状态，不知道应该用哪个才好。
今天我来讲讲CAP的具体细节，简单对比一下ACID base几个概念的关键区别点。
埃里克布鲁尔在CAP理论十二年回顾规则变的一文中，详细的阐述了理解和应用。
Cap的一些细节点。
可能是由于作者写作风格的原因，对于一些非常关键的细节点，一句话就带过了。
这里呢我特别提炼出来，重点阐述第一个细节。
Cap关注的力度是数据，而不是整个系统。
原文就只有一句话，c与a之间的取舍可以在同一系统内以非常细小的力度反复发生。
而每一次的决策，可能因为具体的操作，乃至因为牵涉到特定的数据或用户而有所不同。
但这句话呢是理解和应用CAP理论非常关键的一点。
Cap理论的定义和解释中用的都是system node这类系统级的概念。
这就给很多人造成了很大的误导，认为我们在进行架构设计时，整个系统要么选择CP,要么选择AP.但在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据。
有的数据必须选择CP.有的数据必须选择AP,而如果我们做设计时，从整个系统的角度去选择CP,还是AP,就会发现顾此失彼，无论怎么做都是有问题的。
以一个最简单的用户管理系统为例，用户管理系统包含用户账号数据、用户信息数据。
通常情况下呢，用户账号数据会选择CP,而用户信息数据会选择AP.如果限定整个系统为CP,则不符合用户信息数据的应用场景。
如果限定整个系统为AP,则又不符合用户账号数据的应用场景。
所以在CAP理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类。
每类数据选择不同的策略，而不是直接限定整个系统，所有数据都是同一策略。
第二个细节，CAP是忽略网络延迟的这是一个非常隐含的假设，布鲁尔在定义一致性时并没有将延迟考虑进去。
也就是说，当事务提交时，数据能瞬间复制到所有节点，但实际情况下，从节点a复制数据到节点b总是需要花费一定时间的。
如果是相同机房，消耗时间可能是几毫秒。
如果是跨地域的机房，例如北京机房同步到广州机房，耗费的时间就可能是几十毫秒。
这就意味着CAP理论中的c在实践中是不可能完美实现的。
在数据复制的过程中，节点a和节点b的数据并不一致。
不要小看了这几毫秒或者几十毫秒都不一致。
对于某些苛刻的业务场景，例如和金钱相关的用户余额或者抢购相关的商品库存技术上是无法做到分布式场景下完美一致性的，而业务上必须要求一致性。
因此，单个用户的余额，单个商品的库存理论上要求选择CP,而实际上CP都做不到，只能选择CA.也就是说，只能单点写入其他节点做备份，无法做到分布式情况下多点写入。
需要注意的是，这并不意味着这类系统无法应用分布式架构，只是说单个用户余额，单个商品库存无法做分布式，但系统整体还是可以应用分布式架构的。
例如文稿中的架构图是常见的将用户分区的分布式架构。
我们可以将用户ID为零到一百的数据存储，在node一上将用户ID为一百零一到两百的数据存储在node二上client.根据用户ID来决定访问哪个node.对于单个用户来说，读写操作都只能在某个节点上进行。
对所有用户来说，有一部分用户的读写操作在node一上，有一部分用户的读写操作，在node二上这样的设计有一个很明显的问题，就是某个节点故障时，这个节点上对用户就无法进行读写操作了。
但站在整体上来看呢，这种设计可以降低节点故障时，受影响的用户的数量和范围。
毕竟只影响百分之二十的用户，肯定要比影响所有用户要好。
这也是为什么挖掘机挖断光缆后，支付宝只有一部分用户会出现业务异常，而不是所有用户业务异常的原因。
第三个细节，正常运行情况下，不存在CP和AP的选择，可以同时满足CA. Cap理论告诉我们，分布式系统只能选择CP或者AP.但其实这里的前提是系统发生了分区现象。
如果系统没有发生分区现象，也就是说p不存在的时候，我们没有必要放弃c或者a应该c和a都可以保证。
这就要求架构设计的时候，既要考虑分区发生时选择CP还是AP,也要考虑分区没有发生时如何保证CA.同样，以用户管理系统为例，即使是实现CA,不同的数据实现方式也可能不一样。
用户账号数据可以采用消息队列的方式来实现CA.因为消息队列可以比较好的控制实时性，但实现起来就复杂一些。
而用户信息数据可以采用数据库同步的方式来实现CA.因为数据库的方式虽然在某些场景下可能延迟较高，但使用起来简单。
第四个细节放弃，并不等于什么都不做，需要为分区恢复后做准备。
Cap理论告诉我们，三者只能取两个需要牺牲。
另外一个这里的牺牲是有一定误导作用的，因为牺牲让很多人理解成什么都不做。
实际上呢CAP理论的牺牲只是说在分区过程中，我们无法保证c或者a但并不意味着什么都不做。
例为在系统整个运行周期中，大部分时间都是正常的。
发生分区现象的时间并不长，例如百分之九十九点九九可用性的系统，一年运行下来不可用的时间只有五十分钟。
百分之九十九点九九九可用性的系统，一年运行下来不可用的时间只有五分钟。
分区期间放弃c或者a并不意味着永远放弃c和a我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到CA的状态。
最典型的就是在分区期间记录一些日志。
当分区故障解决后，系统根据日志进行数据恢复，使得重新达到CA状态。
同样以用户管理系统为例，对于用户账号数据，假设我们选择了CP则分区发生后节点，一、可以继续注册新用户节点。
二、无法注册新用户。
此时节点一可以将新注册，但未同步到节点二的用户记录到日志中。
当分区恢复后节点一读取日志中的记录同步给节点。
二、当同步完成后，节点一和节点二就达到了同时满足CA的状态。
而对于用户信息数据，假设我们选择了AP则分区发生后节点一和节点二都可以修改用户信息，但两边可能修改不一样。
例如用户在节点一中将爱好改为旅游美食跑步。
然后用户在节点二中将爱好改为美食游戏节点一和节点二都记录了未同步的爱好数据。
当分区恢复后，系统按照某个规则来合并数据，例如按照最后修改优先规则，将用户爱好修改为美食游戏。
按照字数最多优先规则，则将用户爱好修改为旅游美食跑步也可以完全将数据冲突报告出来。
由人工来选择，具体应该采用哪一条。
接下来看看ACID和base, ACID是数据库管理系统为了保证事物的正确性而提出来的一个理论。
Acid包含四个约束。
下面我来解释一下。
一、atomic ity原子星，一个事物中的所有操作，要么全部完成，要么全部不完成，不会在中间某个环节结束。
事物在执行过程中发生错误，会被回滚到事物开始前的状态，就像这个事物从来没有执行过一样。
二、consistency一致性在事务开始之前和事务结束以后，数据库的完整性没有被破坏。
三、isolation隔离性数据库允许多个并发事务，同时对数据进行读写和修改的能力。
隔离性可以防止多个事物并发执行时由于交叉执行而导致数据的不一致。
事物隔离分为不同级别，包括读、未提交读、提交可重复读和串行化。
四、durability持久性失误。
处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失，可以看到ACID中的a和CAP中的a意义完全不同。
而ACID中的c和CAP中的c名称虽然都是一致性，但含义也完全不一样。
Acid中的c是指数据库的数据完整性，而CAP中的c是指分布式节点中的数据一致性，再结合ACID的应用场景是数据库事务，CAP关注的是分布式系统数据读写。
这个差异点来看，其实CAP和ACID的对比就类似关公战秦琼。
虽然关公和秦琼都是武将，但其实没有太多可比性。
Base是指基本可用软状态最终一致性。
核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性。
一、基本可用分布式系统在出现故障时允许损失部分可用性及保证核心可用。
这里的关键词是部分和核心，具体不择哪些作为可损失的业务，哪些是必须保证的。
业务是一项有挑战的工作。
例如，对于一个用户管理系统来说，登录是核心功能，而注册可以算作非核心功能。
因为未注册的用户本来就还没有使用系统的业务，注册不了，最多就是流失一部分用户。
而且这部分用户户数量较少。
如果用户已经注册，但无法登录，那就意味着用户无法使用系统。
例如，充了钱的游戏不能玩了，云存储不能用了，这些会对用户造成较大损失。
而且登录用户数量远远大于新注册，用户影响范围更大二软状态允许系统存在中间状态，而该中间状态不会影响整体系统可用性。
这里的中间状态就是CAP理论中的数据不一致。
三、最终一致性系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
这里的关联词是一定时间和最终一定时间和数据的特性是强关联的，不同的数据能够容忍的不一致时间是不同的。
举一个微博系统的例子，用户账号数据最好能在一分钟内就达到一致状态。
因为用户在a节点注册或者登录后一分钟内不太可能立刻切换到另外一个节点，但十分钟后可能就重新登录到另外一个节点了。
而用户发布的最新微博可以容忍三十分钟内达到一致状态。
因为对于用户来说，看不到某个明星发布的最新微博，用户是无感知的，会认为明星没有发布微博最终的含义就是不管多长时间，最终还是要达到一致性的状态。
贝斯理论本质上是对CAP的延伸和补充。
更具体的说，是对CAP中AP方案的一个补充。
前面在剖析CAP理论时，提到了其实和斯相关的两点。
第一，CAP理论是忽略延时的，而实际应用中延时是无法避免的这一点，就意味着完美的CP场景是不存在的。
即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合CP要求的。
因此，CAP中的CP方案实际上也是实现了最终一致性，只是一定时间是指几毫秒而已。
第二，AP方案中，牺牲一致性只是指分区期间，而不是永远放弃一致性。
这一点呢其实就是贝斯理论延伸的地方。
分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。
综合上面的分析，ACID是数据库失误完整性的理论，CAP是分布式系统设计理论base是CAP理论中AP方案的延伸。
今天呢我为你讲了深入理解CAP理论所需要特别关注的细节点，以及ACID和base两个相似的术语。
这些技术细节在架构设计中非常关键，希望对你有所帮助，这就是今天的全部内容。
雷达思考题给你吧？假如你来设计电商网站的高可用系统，按照CAP理论的要求，你会如何设计呢？欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。