分布式架构入门：一文轻松搞懂晦涩的CAP理论！( 二 ) _可用性

3、CAP关注的粒度是数据，而不是整个系统
CAP 理论的定义和解释中，用的都是、 node 这类系统级的概念，这就给很多人造成了很大的误导，认为我们在进行架构设计时，整个系统要么选择 CP，要么选择 AP 。但在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择CP，有的数据必须选择 AP 。而如果我们做设计时，从整个系统的角度去选择CP还是AP，就会发现顾此失彼，无论怎么做都是有问题的。
【分布式架构入门：一文轻松搞懂晦涩的CAP理论！】一个电商网站核心模块包括会员，订单，商品，支付，促销管理等等，不同的模块数据特点不同，因此适用不同的CAP架构。
会员模块包括登录，个人设置，个人订单，购物车，收藏夹等功能，这些模块只要保证AP，即对用户的及时响应，数据短时间不一致不大会影响使用。订单模块的下单付款扣减库存操作是整个系统的核心，CA都需要保证，在极端情况下牺牲P是可以的。商品模块的商品上下架保证CP即可，因为后端操作可以允许一定的时延；促销模块短时间的数据不一致，结果就是优惠信息看不到，但是已有的优惠保证可用，所以保证AP也可以。
现在大部分电商网站对于支付是独立的系统，C是必须要保证的，AP中A相对更重要，不能因为分区导致所有人都不能支付。
4、CAP是忽略网络延迟的

文章插图
这是一个非常隐含的假设，布鲁尔在定义一致性时，并没有将延迟考虑进去。也就是说，当事务提交时，数据能够瞬间复制到所有节点。但实际情况下，从节点 A 复制数据到节点 B,总是需要花费一定时间的。这就意味着，CAP理论中的 C 在实践中是不可能完美实现的，在数据复制的过程中，节点 A 和节点 B 的数据并不一致。对于严苛的业务场景。
例如和金钱相关的用户余额、和抢购相关的商品库存，技术上是无法做到分布式场景下完美的一致性的。而业务上必须要求一致性，因此单个用户的余额、单个商品的库存，理论上要求选择 CP 而实际上 CP都做不到，只能选择 CA 。也就是说，只能单点写入，其他节点做备份，无法做到分布式情况下多点写入，这是符合实际情况的。
5、CAP的AP和CP不是绝对的
CAP理论告诉我们三者只能取两个，需要牺牲另外一个，这里的牺牲有一定误导作用，因为牺牲让很多人理解成什么都不做，实际上，CAP理论的牺牲只是说分区过程无法保证C或者A，但不意味着什么都不做，因为在系统整个运行周期中，大部分时间都是正常的，发生分区现象的时间并不长，分区期间放弃C或A，并不意味着永远放弃，可以在分区期间进行一些操作，比如记录日志，从而让分区故障解决后，系统能够重新达到CA的状态。
比如用户账号数据，假设选择了CP，则分区发生后，节点1可以继续注册新用户，节点2无法注册新用户，此时节点1可以记录新增日志，当分区恢复后，节点2读取节点1的日志就可以让节点1和节点2同时满足CA的状态。
6、CAP的可用性与高可用有区别
HBASE、属于CP架构，、属于AP系统，但我们能说后者比前者更高可用么？应该不是。CAP中的高可用，是指在某一次读操作中，即使发现不一致，也要返回响应，即在合理时间返回合理响应。我们常说的高可用，是指部分实例挂了，能自动摘除，并由其它实例继续提供服务，关键是冗余。
7、CAP的网络分区有明确定义
网络故障、节点应用出现问题导致超时，属于网络分区，节点宕机或硬件故障，则不属于。因此如果有人说机器挂了怎么样，这种情况不属于CAP理论适用的范围，CAP关注的是分区时的可用性和一致性，不是说保证整个集群不挂。