BASE

BASE 模型是 eBay 工程师提出大规模分布式系统的实践总结，其理念在于随着时间的迁移，不同节点的数据总是向同一个方向有一个相同的变化。在多数互联网应用情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性理论 BASE，BASE 是指基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）

• 基本可用（Basically Available）：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。譬如音频直播或是做活动时，当业务量非常大的时候可以降级。做游戏也是，在战斗的时候最关心数值的增长，看了多少人都无所谓，缓解核心内容的压力。
• 软状态（Soft State）：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。在写代码、编程业务的设计上，必须容忍有一定的临时数据同步。
• 最终一致性（Eventual Consistency）：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充；CAP 理论是忽略延时的，而实际应用中延时是无法避免的。BASE 方案在分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。BASE 与 ACID 截然相反，ACID 比较悲观,在每个操作结束时都强制保持一致性；而 BASE 比较乐观，接受数据库的一致性处于一种动荡不定的状态。虽然听起来很难应付，实际上这相当好管理，并且可带来 ACID 无法企及的更高级别的可伸缩性。

许多的 NoSQL 是按照 BASE 理论进行设计的，典型的例子包括：Dynamo、Cassandra、CouchDB。

基本可用

BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。譬如如果用户分区在 5 个数据库服务器上，则当一个用户数据库的故障只影响这台特定主机那 20% 的用户。

软状态

考虑到全局锁和数据多版本的对比，把各个节点的相关数据都上锁，这是一个悲观锁，一旦写任务，其他人都能改我的数据，这是比较悲观的心态。

而数据多版本，类似于乐观锁，导致其他人和我方数据冲突的机会并不是那么多，只要在提交的时候发现版本不一样，更新一下，汇总数据就可以了。做好业务上的隔离，多数情况都属于多版本，技术都能解决，不一定要把所有的东西都锁死。允许有一定的临时数据。最终一致性，在临时上的数据不一样，数据同步也是要花时间的。

最终一致性

最终一致性，即允许窗口期数据不一致，互相关联的数据要同步。序列一致性，全局按照序列顺序来做。线性一致性，每一个时间的时钟要同步，时间序列是严格的，按顺序的。最后是强一致性，一个时间只能实行一个任务。

最终一致性的关键词是一定时间和最终，一定时间和数据的特性是强关联的，不同业务不同数据能够容忍的不一致时间是不同的。例如支付类业务是要求秒级别内达到一致，因为用户时时关注；用户发的最新微博，可以容忍 30 分钟内达到一致的状态，因为用户短时间看不到明星发的微博是无感知的。而最终的含义就是不管多长时间，最终还是要达到一致性的状态。