BASE理论
为什么需要BASE理论
强一致性的分布式系统或者事务性的分布式系统使用起来非常方便，不需要考虑太多，就像单机系统一样。但是，根据CAP理论，强一致性必然会影响可用性。一个可用性为 99.7% 的集群每月宕机约 129.6 分钟，这是非常严重的问题。所以，设计系统时优先选择可用性优先的 AP 方案。
BASE理论是什么
BASE理论是CAP理论中的AP方案的延伸，追求的是可用性。它包括基本可用、软状态和最终一致性。
基本可用
基本可用：当分布式系统出现故障时，允许损失部分功能的可用性，保障核心功能的可用性。实现基本可用的4板斧为：
- 流量削峰：将访问请求错开，削弱请求的峰值。
- 延迟响应：对请求进行排队
- 体验降级：例如显示时降低图片的清晰度和大小，以提升系统的处理能力。
- 过载保护：对请求进行排队，如果队列已满，则清除队列中一定数量的请求。
- 对关键服务做好限流：防止瞬时打进大量流量。
- 利用MQ削峰填谷：对流量进行整形，使系统以一种平稳的状态运行。
- 熔断降级
软状态
软状态：系统数据的一种过渡状态，即允许不同数据副本存在短暂的不一致。
最终一致性
最终一致性：经过一段时间的同步后，系统中的所有数据副本最终能够达到一致。
一致性的选择
几乎所有的互联网后台系统选择的都是最终一致性，如果不是必须的话，不推荐实现事务和强一致性，鼓励可用性和性能优先。
- 如果业务的某个功能可以容忍数据短暂的不一致，就考虑使用最终一致性；
- 如果业务的某个功能无法容忍数据的延迟，就考虑使用强一致性；
- 如果是金融系统的数据，就考虑使用事务。
以哪个数据为准
要实现最终一致性，首先要知道以哪个数据为准，这是实现最终一致性的关键。一般来说，有两种方式：
- 以第一次写入的数据为准。如果你不希望存储的数据被更改，可以以它为准。
- 以最新写入的数据为准。例如 AP 模型的 KV 存储采用的就是这种方式
实现方式
常用的有几种：
- 读时修复：在读取数据时，系统如果检测到不同节点间的数据不一致，就自动进行修复。
- 写时修复：在写入数据时，系统如果检测到不同节点间的数据不一致，就自动进行修复。例如节点 A 向节点 B，如果写失败了，节点 A 就将数据缓存下来，然后定时重传，修复数据的不一致。
- 异步修复：通过定时检测数据的一致性并修复。这是最常用的方式。
因为写时修复不需要做数据一致性对比，性能消耗比较低，对系统运行影响也不大，所以我推荐你在实现最终一致性时优先实现这种方式。
在实现最终一致性的时候，我推荐同时实现自定义写一致性级别（All、Quorum、One、Any）， 让用户可以自主选择相应的一致性级别，比如可以通过设置一致性级别为 All，来实现强一致性。
如何使用BASE理论
待续。
