5 年前，术语 NoSQL 才刚刚开始出现，那时很多 NoSQL 数据库的版本都还不到1.0，对于 CAP 理论来说，众多 NoSQL 数据库都选择了可用性要高于一致性的做法。 ACID 是一个沉重的负担，而 BASE 则被认为是未来的发展方向。时至今日，社区已经逐渐成熟起来，一些天花乱坠的宣传也都不见了踪迹，新一轮的 NoSQL 数据库开始寻求重新定义我们对 NoSQL 的期待，随之而来的是分布式、容错事务又开始出现在了人们的视野中。
向分布式、容错事务领域的进军起始于 2012 年秋季，那时 Google 发布了 Spanner 数据库。Spanner 是个全局分布式、容错、事务型的 NoSQL 数据库；这一系列属性在之前则被认为是自相矛盾的。不过，Google 击碎了人们的这种误解，宣称他们已经在生产环境下使用该数据库一年多时间了。
就在 Google 宣布 Spanner 数据库的几个月后， HyperDex 团队默默地发布了 Warp 扩展，它为 HyperDex 带来了分布式、容错的事务功能。这标志着对这种事务的首个开源实现的发布。趋势开始发生了转移，不过还有很长的路要走。
2013 年 5 月， Kyle Kingsbury 在 RICON 上谈到了 Jepsen 。在演讲中，Kingsbury 披露了各种 NoSQL 数据库在各种失败情况下的一系列缺陷。甚至诸如 MongoDB 和 Redis （一般情况下人们都认为他们可以保证一致性）这样的数据库都无法信守其承诺。Kingsbury 的工作使得社区开始更多地关注于测试与形式化设计，在选择可用性优于一致性时能更好地理解这种折衷。
出于对一致性的密切关注， FoundationDB 发布了其键值存储的 1.0 版，这是第一个拥有分布式、容错事务支持的私有 NoSQL 数据库。FoundationDB 团队深刻理解严格测试的必要性，同时对其测试框架 Lithium 给予了高度评价，这使得 FoundationDB 能够确保 ACID 特性。后来他们又可以通过 Jepsen 对 FoundationDB 进行测试。
去年又涌现出了两款将支持分布式、容错事务作为设计目标的开源NoSQL 数据库。 CockroachDB 尝试模仿 Spanner 的地理位置复制事务，它于去年初启动； Treode 则在去年 6 月发布了最初的 0.1 版。这两个项目都认真地采取了形式化设计，并吸取了很多分布式系统的学术研究成果。
这些事务型数据库已经逐步对 NoSQL 世界产生了影响，我们看到一致性的 NoSQL 数据库正在不断改进自己的承诺。比如说，Redis 就面临着持续的压力，在构建器分布式功能时要求专注于形式化设计与测试。最近， Tokutek 为 MonogoDB 发布了其新的 Ark 一致性算法。Ark 基于 Raft 协议，旨在修复 MongoDB 已知的一致性问题。
虽然现在还是 Treode 与 CockroachDB 的早期发展时段，但已经有不少公司在生产环境中使用了FoundationDB 与HyperDex Warp。分布式、容错事务将会扎根于NoSQL，我们将会看到其产生的影响。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论