探讨NuoDB数据库的架构

在本文的第 1 部分，我们介绍了 NuoDB，并对它的几个主要特性进行了讲解：三层架构、对等的节点以及原子这个基本的数据单元。此外还讲述了版本控制、用以处理数据更新冲突的并发系统以及如何实现一致性。

运行中的事务

你现在已经熟悉了整体模型、内部的结构以及版本控制，接下来让我们看几个简单的例子，以帮助你更好地理解它们在实际中是怎样运用的。为了简单起见，假设有一个简单的数据库，包含两个事务引擎（TE）和一个存储管理器（SM），从这个简单配置着手研究，应该能够很简单地推导出更复杂的配置。

首先考虑一下原子是怎样被导入到这两个 TE 缓存中的。假设有一个原子存在归档中，但并不存在任何缓存中，当某个客户端连接到第一个 TE 并且启动一个需要这个原子的事务时，TE 就会在它的目录（Catalog）结构中进行查找，当它发现缓存中没有该数据时，就会到 SM 中去获取对象。这时，目录结构就会反映出原子已经处于第一个 TE 的缓存中了，并且该 TE 将被认为是相关数据的 Chairman（主持人）。

此时如果在第二个 TE 上启动一个事务，并且该事务需要同一个原子中的数据时，目录将会告诉事务可以在 SM 与第一个事务这两处找到该原子。虽然第二个 TE 可以自由地选择从哪里获取这个原子，但在实际过程中它总是会从第一个 TE 请求该原子，因为从内存中的拷贝获取原子速度更快。此时目录会相应地进行更新，显示原子已经存在于两个缓存中了。

接下来，让我们看看当原子中的数据产生变化时会发生些什么。举个例子，假设原子中的数据里的某一行被更新，为了接受这个更新，运行该事务的 TE 需要发送两条消息：一是对所有包含该数据拷贝的对等进程（在本例中就是指另一个 TE 以及 SM）发送一条等待更新的消息，二是对 Chairman 发送一条申请批准该更新的权限的消息。如果该更新发生于第一个 TE，那么第二条消息的发送会被短路（跳过），因为该 TE 本身就是 Chairman。两条消息都是异步执行的，这确保了事务能够继续执行。如果没有发生任何冲突情况，Chairman 最终会接受该更新，并发出响应。

如果两个事务同时尝试更新同一份数据，就会发生冲突。哪个事务能够首先将请求传递给 Chairman 就能够“获胜”，另一个事务最终会收到一条更新被拒绝的响应。此时这个失败的事务必须被回滚，随后再次尝试。

之前我曾经提过，NuoDB 对提交协议的支持很灵活，现在就会讲到它的应用了。为了将某个客户端的提交执行成功的信息发送回去，TE 必须始终确保 ACID 中的原子性、一致性和隔离性，但在持久性方面则拥有一定的灵活性。

在上面的示例中，更新消息将会异步地发送给所有拥有该对象拷贝的对等进程，包括 SM 在内。当消息在可靠的频道中传递时，除非我们等待确认消息的到来，否则是没有办法知道该 SM 的生存时间是否足够使该数据保持持久性的。作为数据库配置的一部分，你可以选择某个 TE 在报告提交成功前是否需要等待确认消息。由于你可以选择性地在运行时打开日志功能，实际上你所需要从 SM 返回的内容也就有了多个版本。

因此提交即可以表示消息已发送至所有的对等进程，也可以表示 SM 对本次改变的响应已进行日志记录或者已经被写入持久化的归档中，提交还可以表示至少有某些最小数量的 SM 发送了响应。这种方式给了你充分的灵活性，你可以决定在发生提交失败时你的持久化保证有多可靠，也可以决定你的分布式数据库运行有多快。

管理层

我之前曾提到过，NuoDB 有一个管理层，正是它支持了按需伸缩功能以及那些我们已见识过的迁移模型。每个主机系统都运行着一个本地的管理代理，代理构成了一个与数据库无关的对等网络。我们将这个互联主机的集合称为一个领域（Domain）。

领域包含一个单一的本地管理视图，这使得监控、管理及自动化等数据库活动变得简单。每个代理都负责它的本地主机，有些代理还会以中介（Broker）的角色运行，中介将整个领域展示为一个全局视图。所有中介都具有相同的知识与能力，因此如果你有多个中介在运行，你就可以访问管理与自动化接口。通过中介，你可以启动、停止或迁移数据库，改变你的配置，监控以及捕获 TE 和 SM 的日志记录，并运行一切按预计运行。

由于数据库就是一个运行中的进程集合而已，要在一台单独的主机上运行多个数据库也很方便。换句话说，管理层能够支持多租户（multi-tenant）系统的部署，每个租户运行着自己的数据库，它们在进行级别上进行了隔离，由自己的安全通道进行保护，并将数据存于自己的归档内。那么我们在一个单一的系统里可以创建多少个数据库呢？关于这一点在我们的博客中的“支持密集部署”文章中谈论了更多内容。

SQL 客户端在连接到数据库时，正是利用中介而得以找到 TE 的。这就使中介的功能像一个简单的负载均衡器一样，它了解领域中发生的一切，并能够智能地决定让客户端连接到哪里。

总结 NuoDB 的功能

了解了这些特性之后，让我们再回头看看我说所的云伸缩，我认为有一些用例是尤其适合 NuoDB 进行处理的。首先，它不仅支持自动化、按需水平伸缩，并且在拥有这些能力的同时还提供了高可用性（HA）。这种高可用性并非来自预先搭建的额外的故障转移功能，而是因为 NuoDB 能够监控系统错误，并且非常迅速地将新资源上线所带来的。这种反应迅速的高可用性意味着你不需要为了避免错误而带来多余的开销，并且在面临错误情况时依然能够保持良好的可用性。

其次，NuoDB 能够为跨越数据中心、并且分布在不同区域的数据库提供一个单一的逻辑数据库视图。这一点显然有助于高可用性，不仅如此，如果你的应用程序的用户来自不同地方，而且你希望让他们尽量连接到最接近他们的应用与数据，这一特性也非常关键。NuoDB 支持按地理位置分布，因为连接系统的客户端会乐于使用本地化的数据，因此尽管已经有了简单负载均衡、按需缓存以及区域间的异步分发功能，单一数据库这一特性仍然能够将大多数协调信息保持在一个本地区域内。

再次，因为 MVVC 为 NuoDB 提供了一个高效的快照隔离模型，它能够很好地支持对同一份数据的操作性与分析性的访问。换句话说，对频繁更新的数据进行运行时间较长的只读查询也不会产生冲突。这一特性有助于简化部署操作，否则部署时将不得不运行多个数据库，并且要不断地试图同步数据集。

最后，NuoDB 是全自动的。无论是按需水平伸缩，还是多租户的运行效率，我们都将数据库当做服务看待，它需要由简单的 SLA（服务级别协议）和策略进行驱动。这正是 NuoDB 的开发方向。

NuoDB 的下一步是什么？

我在本文中想表达的是，NuoDB 展现了一种全新的架构，在设计的最初就支持水平伸缩、敏捷式部署与自动化。可以很方便地加入新的主机并扩展系统能力，并且在出现大量的数据加载或者系统错误时能够自动地扩展，还能够跨多个数据中心扩展数据库。回到这篇文章开始的地方，我认为这些能力足以保证 NuoDB 是一个优秀的云伸缩数据库。

我们当前的工作是使自动化功能进一步简化。你可以通过简单的 SLA 详细地定义你对某个数据库的需求。无论你是否正打算在笔记本上进行开发，管理你公司的内部数据库或是在互联网上启用一个服务，这一特性让 NuoDB 使用起来就像一个服务一样简单。

我们正在扩展按地理位置分布的数据库的功能，它在你遇到错误时提供了更多灵活性，并且进一步保证了数据可用性。我们也在继续加强服务端编程模型，存储层并行的能力，并且改善了 SQL 与管理客户端的 API。我希望你能够去尝试一下，然后告诉我你的想法。

关于作者

Seth Proctor是 NuoDB 公司的 CTO，在可伸缩系统的研究、设计和实现上有超过十五年的经验。这些经验来自于网络、语言、操作系统、安全、数据库和分布式环境等领域，然后凝结成了 NuoDB 产品。在 NuoDB 之前，Seth 就职于 Nokia，负责内部私有云的架构。再往前，Seth 在 Sun 公司的研究实验室工作，和产品组、大学进行合作。