在本地事务这篇文章里我们讲到了数据库事务必须保证ACID,在2PC这篇文章里,我们探讨了跨数据库事务是如何保证ACID的。
当数据量越来越大的时候,我们会对将大数据库拆分成若干小库,随着数据库数量越来越多,2PC(及XA)就显得有些捉襟见肘了:
CAP理论是Eric Brewer教授针对分布式数据库所提出的一套理论,他认为在实现分布式数据库,需要考虑3个需求:
CAP理论指出,当每个节点都工作正常的时候,C、A、P是可以都满足的,当出现节点故障时,我们只能3选2。
如果我们不想因为数据库的某个节点出现故障就让数据库停止服务,那么我们必定选择P,那么我们就只能在C和A之间做选择。如果选择C:后续的读都将失败。如果选择A:会读到不一致的结果。
Basically Available, Soft state, Eventually consistent,简称BASE。
BASE和ACID相反,ACID是悲观的,它要求所有操作都必须保证一致性,而BASE是乐观的,它接受数据库的一致性在不断变化当中。同时,BASE对于CAP中的C做出了一定的妥协——接受临时的不一致,采用最终一致性。最终一致性,听上去怪怪的,一些开发人员觉得这是个坏东西。不过我们真的要时时刻刻保证一致性吗?BASE认为我们可以做一些妥协,因此如果我们按照BASE设计系统的话就能够保证:
举个例子,现在我们有3条insert要执行(至于是否是3个不同的表、数据库不重要),那么只要保证下面几点就能够满足BASE:
正确地使用BASE模式也不是那么容易,比如消费业务,我们要保证“检查余额”和“扣款、记录消费日志”这两组动作不会产生交叉,否则就会因为高并发场景而发生透支,在这个例子里我们可以对“扣款、记录消费日志”做最终一致性,但是如何保证下达“扣款、记录消费日志”这两个指令肯定不会产生透支的情况则不是BASE解决的问题了。
所以总结一下BASE的特点就是:
关于BASE可以详见这篇文章BASE: An Acid Alternative。