BASE

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 无法企及的更高级别的可伸缩性。

基本可用

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

软状态

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

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

最终一致性

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

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