BASC理论

1. BASE理论概述

  BASE理论源于eBay的架构师Dan Pritchett对大规模分布式系统的实践总结，BASE理论是对CAP理论的延伸，其核心思想是即使无法做到强一致性（CAP中的C），但应用可以采用合适的方式达到最终一致性。
   BASE是指基本可用、软状态和最终一致性。

BASE模式三元素：

• BA: Basically Available，基本可用。
• S: Soft State，软状态，状态可以在一段时间内不同步。（过渡状态）
• E: Eventually Consistent，最终一致，在一定的时间窗口内，最终数据达成一致即可。

  软状态是实现BASE思想的方法，基本可用和最终一致是目标。
  以BASE思想实现的系统由于不保证强一致性，所以系统在处理请求的过程中可以存在短暂的不一致，在短暂的不一致的时间窗口内，请求处理处于临时状态中，系统在进行每步操作时，通过记录每个临时状态，在系统出现故障时可以从这些中间状态继续处理未完成的请求或者退回到原始状态，最终达到一致状态。

2. 基本可用（Basically Available）

  基本可用的意义在于，当系统出现真正的故障时，可以提供一些降级的服务，而不是不提供服务。
  基本服务通常会在两方面有所损失：响应时间和功能。

• 响应时间：处理请求的相应时长会受到影响，会比正常的处理时间长。
  例如，用户正常进行搜索，可能在500ms内就可以返回结果，当服务处于基本可用状态时，可能在3s内返回结果。通常是因为某些节点不可用，或者等待超时触发柔性。
  例如，正常情况下后端即时返回搜索结果并发送给前端，当后端访问连接不上时，可能再选取其他节点测试，期间会增加处理时间。
• 功能：与正常情况下提供的功能不一致，通常是一种降级后的功能，保证用户基本功能可用。
  例如，在除夕抢红包时，要保证抢红包的体验是正常的。但是红包到账、查询资产等功能可能就不会及时生效，一般会给用户展示一个引导页，告知红包在一个小时内到账而不是像平时一样马上到账。

3. 软状态（Soft State）

  原子性要求多个节点的数据副本都是一致的，这是一种“硬状态”，与之对应的状态就是“软状态”。
  软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点中的数据副本存在数据延时。

4. 最终一致性（Eventually Consistent）

  最终一致性是指在软状态度过一段时间后，保证系统的所有副本最后都达到一致的状态。这个时间和网络延时、系统负载、数据复制等因素有关。最终一致性可以分为五种。

4.1 因果一致性（Causal Consistency）：

  因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。

4.2 读己之所写（Read your writes）

  读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

4.3 会话一致性（Session consistency）

  会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

  例如，有些分布式数据库的读、写有不同节点提供服务。在一次会话中，先修改了某个值，然后去读这个值，发现读到了旧值，值没有更新，如果还按旧值给用户使用，则导致用户体验不好。这时不去读数据库中的值，而是直接用会话上下文新增值为用户服务。使此时有其他会话修改了数据，也要保证本会话连贯，不更新最新值。

4.4 单调读一致性（Monotonic read consistency）

  单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
  该节点相当于中间逻辑层，缓存从数据层得到的数据。如果再读到旧的副本，则不使用旧数据，只用读到的最新版本的数据返回给前端进行处理。

4.5 单调写一致性（Monotonic write consistency）

  单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。

5. 再看BASC理论

5.1 什么时候需要用到BASC理论

  在之前的篇章中有讲解到CAP理论，其中CP系统强调的强一致性，意味着当出现网络分区，服务无法快速给出正确的反馈。

  例子，集群的可用性是每个节点可用性的乘积，比如，假设 3 个节点的集群，每个节点的可用性为 99.9％，那么整个集群的可用性为 99.7％，也就是说，每个月约宕机 129.6 分钟，这是非常严重的问题。 而解决可用性低的关键在于，根据实际场景，尽量采用可用性优先的 AP 模型。

  小结：当我们在设计AP系统的时候，可以使用BASE理论。

5.2 实现基本可以的4板斧

5.2.1 4板斧简述

  流量削峰、延迟响应、体验降级、过载保护。

5.2.2 再看基本可用

  基本可用是说，当分布式系统在出现不可预知的故障时，允许损失部分功能的可用性，保障核心功能的可用性。就像弹簧一样，遇到外界的压迫，它不是折断，而是变形伸缩，不断适应外力，实现基本的可用。
  我们可以把基本可用理解成，当系统节点出现大规模故障的时候，比如专线的光纤被挖断、突发流量导致系统过载（出现了突发事件，服务被大量访问），这个时候可以通过服务降级，牺牲部分功能的可用性，保障系统的核心功能可用。

5.2.3 实现的案例

• 流量削峰 —— 12306购票系统：出售不同区域的票，将访问请求错开，削弱请求峰值。比如，在春运期间，深圳出发的火车票在 8 点开售，北京出发的火车票在 9 点开售。
• 延迟响应 —— 12306购票系统：提交的购票请求，会在队列中排队等待处理，可能几分钟或十几分钟后，系统才开始处理，然后响应处理结果。
• 体验降级 —— 互联网系统：突然出现网络热点事件，大量用户涌进来，产生了海量的突发流量，系统过载了，大量图片因为网络超时无法显示，用小图片来替代原始图片，通过降低图片的清晰度和大小，提升系统的处理能力。
• 过载保护 —— 比如把接收到的请求放在指定的队列中排队处理，如果请求等待时间超时了（假设是 100ms），这个时候直接拒绝超时请求；再比如队列满了之后，就清除队列中一定数量的排队请求，保护系统不过载，实现系统的基本可用。—— 过载保护。

5.2.4 小结

  实现基本可用的4板斧：掌握流量削峰、延迟响应、体验降级、过载保护这 4 板斧。理解这 4 板斧背后的妥协折中，从而灵活地处理不可预知的突发问题。

5.3 BASC理论地位

  BASE 理论是 CAP 理论中的 AP 的延伸，是对互联网大规模分布式系统的实践总结，强调可用性。几乎所有的互联网后台分布式系统都有 BASE 的支持，这个理论很重要，地位也很高。一旦掌握它，你就能掌握绝大部分场景的分布式系统的架构技巧，设计出适合业务场景特点的、高可用性的分布式系统。

6. 总结

• BASE 理论是对 CAP 中一致性和可用性权衡的结果，它来源于对大规模互联网分布式系统实践的总结，是基于 CAP 定理逐步演化而来的。它的核心思想是，如果不是必须的话，不推荐实现事务或强一致性，鼓励可用性和性能优先，根据业务的场景特点，来实现非常弹性的基本可用，以及实现数据的最终一致性。
• BASE 理论主张通过牺牲部分功能的可用性，实现整体的基本可用，也就是说，通过服务降级的方式，努力保障极端情况下的系统可用性。
• ACID 理论是传统数据库常用的设计理念，追求强一致性模型。BASE 理论支持的是大型分布式系统，通过牺牲强一致性获得高可用性。BASE 理论在很大程度上，解决了事务型系统在性能、容错、可用性等方面痛点。另外我再多说一句，BASE 理论在 NoSQL 中应用广泛，是 NoSQL 系统设计的事实上的理论支撑。

参考：
《架构师修炼之道》
《分布式服务架构》
《极客时间——分布式协议与算法实战》