简介
BASE 是 Basically Available(基本可用) 、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于 CAP 定理逐步演化而来的,它大大降低了我们对系统的要求
BASE 理论三要素
基本可用
基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性。但是,这绝不等价于系统不可用。
什么叫允许损失部分可用性呢?
- 响应时间上的损失: 正常情况下,处理用户请求需要 0.5s 返回结果,但是由于系统出现故障,处理用户请求的时间变为 3 s。
- 系统功能上的损失:正常情况下,用户可以使用系统的全部功能,但是由于系统访问量突然剧增,系统的部分非核心功能无法使用。
软状态
软状态指允许系统中的数据存在中间状态(CAP 理论中的数据不一致),并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
分布式一致性的 3 种级别:
- 强一致性:系统写入了什么,读出来的就是什么。
- 弱一致性:不一定可以读取到最新写入的值,也不保证多少时间之后读取到的数据是最新的,只是会尽量保证某个时刻达到数据一致的状态。
- 最终一致性:弱一致性的升级版,系统会保证在一定时间内达到数据一致的状态。
业界比较推崇是最终一致性级别,但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。
那实现最终一致性的具体方式是什么呢? 《分布式协议与算法实战》 中是这样介绍:
- 读时修复 : 在读取数据时,检测数据的不一致,进行修复。比如 Cassandra 的 Read Repair 实现,具体来说,在向 Cassandra 系统查询数据的时候,如果检测到不同节点的副本数据不一致,系统就自动修复数据。
- 写时修复 : 在写入数据,检测数据的不一致时,进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说,Cassandra 集群的节点之间远程写数据的时候,如果写失败 就将数据缓存下来,然后定时重传,修复数据的不一致性。
- 异步修复 : 这个是最常用的方式,通过定时对账检测副本数据的一致性,并修复。
比较推荐 写时修复,这种方式对性能消耗比较低。
BASE 理论的核心思想
即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。
也就是牺牲数据的一致性来满足系统的高可用性,系统中一部分数据不可用或者不一致时,仍需要保持系统整体“主要可用”。
BASE 理论本质上是对 CAP 的延伸和补充,更具体地说,是对 CAP 中 AP 方案的一个补充。
为什么这样说呢?
CAP 理论这节我们也说过了:
如果系统没有发生“分区”的话,节点间的网络连接通信正常的话,也就不存在 P 了。这个时候,我们就可以同时保证 C 和 A 了。因此,如果系统发生“分区”,我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话,我们要思考如何保证 CA 。
因此,AP 方案只是在系统发生分区的时候放弃一致性,而不是永远放弃一致性。在分区故障恢复后,系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。
实际应用案例:电商购物车系统
基于BASE理论的电商购物车系统是一个典型的实际应用案例,它可以通过合理的设计来确保数据的最终一致性。
数据一致性保障机制:
在电商购物车系统中,用户可以将商品添加到购物车,然后可以进行结算和支付。这涉及到对购物车中商品数量、价格等数据的操作和更新。为了确保数据的最终一致性,可以采取以下措施:
- 基于异步通信:当用户操作购物车时,系统不需要立即更新数据,而是使用异步通信的方式将操作请求发送到消息队列中。这样可以保证用户操作的及时响应,并避免同步更新数据带来的性能瓶颈。
- 使用消息队列解耦:将购物车处理过程中的各个步骤解耦,例如将商品添加到购物车、删除购物车中的商品、更新购物车中的商品数量等操作分别存储为不同的消息。这样可以确保每个操作在消息队列中独立处理,从而提高系统的可伸缩性和灵活性。
- 最终一致性机制:由于BASE理论中接受最终一致性,可以采用以下方法来保证购物车数据的最终一致性:
- 使用分布式锁:在对购物车数据进行操作时,使用分布式锁来保证同一时刻只有一个线程可以修改购物车数据,以避免并发问题。
- 消息队列的消费者幂等性:消费消息的服务节点需要具备幂等性,确保相同消息在处理时只会产生一次结果。例如,当多次收到某个商品被添加到购物车的消息时,只执行一次添加操作。
- 定时任务的校正机制:定时任务可周期性检查消息队列中未被正确消费的消息,并进行校正。例如,如果某个操作消息没有被正确处理,则定时任务可以重新处理该消息,确保数据最终一致。
通过以上措施的综合应用,电商购物车系统可以在保证用户操作的实时响应性的同时,最终保证购物车数据的一致性。