事务 - BASE模式

事务 - BASE模式

github

ACID的局限

在本地事务这篇文章里咱们讲到了数据库事务必须保证ACID，在2PC这篇文章里，咱们探讨了跨数据库事务是如何保证ACID的。

当数据量愈来愈大的时候，咱们会对将大数据库拆分红若干小库，随着数据库数量愈来愈多，2PC（及XA）就显得有些捉襟见肘了：

1. 性能低下，2PC协议是阻塞式的。当协调的数据库愈来愈多时，性能没法接受。
2. 没法水平扩展以提高性能，只能靠垂直扩展（提高硬件）——更快的CPU、更快更大的硬盘、更大更快的内存——可是这样很贵，而且很容易遇到极限。

CAP理论

CAP理论是Eric Brewer教授针对分布式数据库所提出的一套理论，他认为在实现分布式数据库，须要考虑3个需求：

• Consistency：当写发生时，每一个节点的数据必须都被更新到。当查询发生时，若是还未所有更新到则返回error或timeout；若是所有更新到了，则直接返回结果。
• Availability：当查询发生时，不用考虑上一次写是否更新到了每一个节点，直接提供当下的数据做为结果。
• Partition-tolerance：除非全部节点都挂，它都应该能继续提供服务。

CAP理论指出，当每一个节点都工做正常的时候，C、A、P是能够都知足的，当出现节点故障时，咱们只能3选2。

若是咱们不想由于数据库的某个节点出现故障就让数据库中止服务，那么咱们一定选择P，那么咱们就只能在C和A之间作选择。若是选择C：后续的读都将失败。若是选择A：会读到不一致的结果。

BASE模式

Basically Available, Soft state, Eventually consistent，简称BASE。

BASE和ACID相反，ACID是悲观的，它要求全部操做都必须保证一致性，而BASE是乐观的，它接受数据库的一致性在不断变化当中。同时，BASE对于CAP中的C作出了必定的妥协——接受临时的不一致，采用最终一致性。最终一致性，听上去怪怪的，一些开发人员以为这是个坏东西。不过咱们真的要时时刻刻保证一致性吗？BASE认为咱们能够作一些妥协，所以若是咱们按照BASE设计系统的话就可以保证：

1. ACID - A，不保证，一旦开始“写”则不可能回滚。
2. ACID - C，保证最终一致性。
3. ACID - I，不保证，是由于一个大事务是由多个小事务组成，每一个小事务都会独立提交。
4. ACID - D，保证，由于数据库保证D。
5. CAP - C，保证最终一致性。
6. CAP - A，保证基本可用。
7. CAP - P，保证。

举个例子，如今咱们有3条insert要执行（至因而否是3个不一样的表、数据库不重要），那么只要保证下面几点就可以知足BASE：

1. 最终都可以执行成功
2. 任何一条语句执行失败都会重试
3. 任意一条语句重复执行结果都同样——幂等

正确地使用BASE模式也不是那么容易，好比消费业务，咱们要保证“检查余额”和“扣款、记录消费日志”这两组动做不会产生交叉，不然就会由于高并发场景而发生透支，在这个例子里咱们能够对“扣款、记录消费日志”作最终一致性，可是如何保证下达“扣款、记录消费日志”这两个指令确定不会产生透支的状况则不是BASE解决的问题了。

因此总结一下BASE的特色就是：

1. 解决的是提交的问题
2. 2PC将提交动做放在数据库，而BASE将提交动做放在应用程序

关于BASE能够详见这篇文章BASE: An Acid Alternative。

参考资料

• Wiki - CAP Theorem
• Wiki - Eventual Consistency
• Article - BASE: An Acid Alternative
• Article - Better Explaining CAP Theorem