BASE 理论

BASE 理论是基于 CAP 理论逐步演化而来，是对 CAP 中一致性和可用性权衡的结果。其核心思想是强调可用性，即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。主要是三点：

软状态：是一种过渡状态，软状态描述的是实现服务可用性的时候系统数据的一种过渡状态，即不同节点间，数据副本存在短暂的不一致。

实现基本可用

当系统节点出现大规模故障的时候，可以通过服务降级，限流，削峰，过载保护等措施，牺牲部分功能的可用性，延时响应部分请求，保障系统的核心功能可用。

基本可用在本质上是一种妥协，也就是在出现节点故障或系统过载的时候，通过牺牲非核心功能的可用性，保障核心功能的稳定运行。

最终的一致

系统中所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。

也就是说，在数据一致性上，存在一个短暂的延迟。

实现最终一致性的方式：

读时修复：在读取数据时，检测数据的不一致，进行修复。如在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
写时修复：在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。
异步修复：这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。

写时修复不需要做数据一致性对比，性能消耗比较低，对系统运行影响也不大，所以我推荐你在实现最终一致性时优先实现这种方式。

而读时修复和异步修复因为需要做数据的一致性对比，性能消耗比较多，在开发实际系统时，你要尽量优化一致性对比的算法，降低性能消耗，避免对系统运行造成影响。

BASE 理论在很大程度上，解决了事务型系统在性能、容错、可用性等方面痛点。BASE 理论在 NoSQL 中应用广泛，是 NoSQL 系统设计的事实上的理论支撑。

自定义写一致性级别：All、Quorum、One、Any，

我们可以通过写时修复和异步修复实现最终一致性。另外，还实现自定义写一致性级别，支持 All、Quorum、One、Any 4 种写一致性级别，用户在写数据的时候，可以根据业务数据的特点，设置不同的写一致性级别。

推荐阅读