【分布式】CAP 和 BASE理论简介及应用_cap base理论及其应用

目录

一、理论简介

1. CAP理论

2. BASE理论

二、应用

1. 服务注册中心

2.分布式锁

3.分布式事务

---

一、理论简介

1. CAP理论

CAP = Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）

• 一致性 : 所有节点访问同一份最新的数据副本
• 可用性: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
• 分区容错性 : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

CAP定理，又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式系统来说，不可能同时满足以上三点，只能满足三项中的两项。

实际上，在分布式系统中，由于我们必须要实现分区容错性（Partition Tolerance），因此只能选择 CP 或者 AP 架构。

问题：为什么不能选择CA架构?

如果我们选择CA架构，则会出现这样的情况：如果分布式系统出现网络分区，当某个节点在进行写操作时，

• 为了保证 C（一致性）， 必须禁止其他节点的读写操作，这就和 A（可用性）发生冲突了。
• 为了 A（可用性），其他节点的读写操作正常的话，那就和 C（一致性）发生冲突了。

2. BASE理论

BASE = Basically Available（基本可用） 、Soft-state（软状态） 、Eventually Consistent（最终一致性）

• 基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性（如：响应时间变慢、系统部分非核心功能无法使用）。
• 软状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

二、应用

1. 服务注册中心

常用的注册中心有Zookeeper、Eureka、Nacos、Consul和ETCD。其中Zookeeper、Consul、ETCD选择CP架构，Eureka选择AP架构，Nacos既支持CP架构也支持AP架构。

问题：服务注册应该选择AP还是CP？

对于服务注册来说，针对同一个服务，即使注册中心的不同节点保存的服务注册信息不相同，也并不会造成灾难性的后果。对于服务消费者来说，能消费才是最重要的，就算拿到的数据不是最新的数据，消费者本身也可以进行尝试失败重试。总比为了追求数据的一致性而获取不到实例信息整个服务不可用要好。

所以，对于服务注册来说，可用性比一致性更加的重要，选择AP架构，即 Eureka 和 Nacos。那么Eureka和Nacos如何选择？哪个让我做的事少，我就选择哪个，显然 Nacos 帮我们做了更多的事。

2.分布式锁

目前分布式锁的实现方式主要包括三种，其中基于Redis实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存操作，而基于数据库实现分布式锁和基于zookeeper实现分布式锁都会涉及到磁盘文件IO，效率相对低下。

• 基于数据库实现分布式锁

利用数据库的唯一索引来实现。当进行加锁时，进行insert操作，数据库成功插入则认为加锁成功，当数据库报出 Duplicate entry 则表示无法获取该锁。

不过这种方式对于单主却无法自动切换主从的MySQL来说，基本就无法现实现P（分区容错性），（MySQL自动主从切换在目前并没有十分完美的解决方案）。可以说这种方式强依赖于数据库的可用性，数据库写操作是一个单点，一旦数据库挂掉，就导致锁的不可用。这种方式基本不在CAP的一个讨论范围。

• 基于Redis实现分布式锁

利用Redis的setXX指令来实现，并设置一个超时时间，过期自动释放锁。Redisson是Redis官网推荐实现分布式锁的一个第三方类库。它提供了 watch dog 自动延时机制，通过开启另一个服务，后台进程定时检查持有锁的线程是否继续持有锁，使在 Redisson 实例被关闭前，不断的延长锁的有效期。

Redis分布式锁采用了AP架构。如果在社交发帖等不需要非常强的事务一致性的场景下，Redis分布式锁是非常适合的；但如果是交易类型等对数据一致性非常敏感的场景下，我们可能要寻在一种更加适合的 CP 架构的分布式锁。

• 基于ZooKeeper实现分布式锁

多个节点同时在一个指定的节点下申请创建有序的临时节点，判断自己是否为序号最小的节点，如果是，则获取锁，否则就会监听序号比自己小的节点，一旦序号比自己小的节点被删除了，就再次判断自己是否是最小节点。

ZooKeeper分布式锁采用了CP架构。当ZooKeeper分布式锁提供给我们进行访问的时候，在zk集群中能确保这把锁在zk的每一个节点都存在。ZooKeeper分布式锁要比Redis分布式锁可靠很多，但它繁琐的实现机制导致了它的性能不如Redis，而且zk会随着集群的扩大而性能更加下降。

3.分布式事务

分布式事务跟ACID原则的数据库事务有点不一样，它是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一致性。

在分布式系统中，要实现分布式事务，常见的解决方案如下：

• 两阶段提交（2PC）：事务的提交分为两个阶段：准备阶段和提交执行方案。
• 补偿事务（TCC）：采用了补偿机制，核心思想是针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。
• 本地消息表：核心思想就是将分布式事务拆分成本地事务进行处理。
• 最大努力通知：实现最大努力通知，可以采用MQ的ACK机制。
• Saga事务：核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

以上分布式事务的解决方案各有不同，不过其实都是遵循BASE理论，是最终一致性模型。业界目前使用本地消息表这种方案是比较多的。