NeverBlock 和无阻塞数据库适配器

NeverBlock 是一个使用 Ruby 1.9 的 Filber 特性构建的库。使用 NeverBlock 可以编写 non-blocking 代码。第一个获益于 NeverBlock 的数据库是 Postgres（可见 InfoQ 上

关于Fibers 和 NeverBlock 的文章。现在，就在Postgres 几天之后，NeverBlock 也添加了对于MySQL 的支持，并使用了新的MySQLPlus 驱动。MySQLPlus 构建于Ruby 自带的MySQL 驱动之上，此外还添加了异步查询处理支持和线程访问支持。

此外，另一个致力于为Ruby 的MySQL 连接增加异步操作能力的工程是

Asymy 。InfoQ 为此采访了 MySQLPlus 的一位开发人员 Roger Pack。我们特别感兴趣的是 MySQLPlus 和 Asymy 的差异，以及为什么要创建一个新的适配器。

首先介绍一些历史：之前我们使用的一般是用 C 编写的 MySQL 库，它在任何一次查询时都会进行阻塞。MySQLPlus 和 Asymy 都试图改变这一情况。

MySQLPlus 基本上可以算是在标准的 MySQL Ruby C 库之上增加了一些多线程友好的特性，尤其是在一条查询返回前不阻塞 IO。

Asymy 则是一个为比较纯粹的异步 MySQL 适配器。它用 Ruby 写成，因而解析相对慢的多（大约要慢 10 倍），而且由于推出不久，尚有一些 bug。

让 我来说，二者间的一个差别在于 Asymy“只是”事件驱动的，而 MySQLPlus 则同时兼有线程模式和事件驱动。MySQLPlus 的事件驱动特性有一 定的局限，这体现在当一个查询被读入时，用户不能够真正的检测到何时去等待 IO——这说明 MySQLPlus 尚未完善，但这至少是朝着正确方向迈出的一 步。

实际上，最开始的时候我们曾考虑过使用 Asymy，后来 Muhammed [Ali, NeverBlock 的一名工作人员] 发现只要对标准的 C MySql 库稍作修改，就可以使其基本具有多线程能力，所以我们就转到了标准库这边。MySQLPlus 库可以看作是对 Tomita Masahiro 库的一个修改。

所以我想 MySQLPlus 和 Asymy 之间可能有一些重复的部分，这主要是 C 和 Ruby 两种语言的问题。MySQLPlus 的 C 语言部分并不是我们写的，所以在这部分没有什么重复。

现在 NeverBlock 可以和 MySQLPlus 一起工作，那么它会能够和 Event Machine 一起工作吗？

NeverBlock 基本上可以看作是 Fiber、EventMachine、Postgres 或 MySQLPlus 驱动的结合体。因此答案是：在应用了

一些小补丁后，NeverBlock 可以和 EventMachine 一起工作。因此如果你很喜欢 EventMachine 的分阶段编程风格，NeverBlock 甚至可以与 1.8.x 版本的 MySQL 驱动一起工作。

值得注意的是 MySQLPlus 已经作为相对于 1.8.x MySQL 驱动来说更加线程友好的代替品而推出。MySQLPlus 也可以很好的与 NeverBlock 和 1.8.x MySQL 驱动兼容，这也是它最初的目标。

这个项目未来的计划是什么样的？你们是否打算去适配其它种类的数据库？

Muhammed 提到过这一潜在目标。我倒还没有这么想过，因为我觉得我们已经足够好的覆盖了这方面工作最重要的部分。

未来的计划主要是让 rails 2.2 兼容 NeverBlock 和 MySQLPlus，希望能得到比较好的性能。

Aman Gupta，MySQLPlus 的作者之一，将 MySQLPlus 用在了 Aman Gupta 所开发的

异步Event Machine MySQL 客户端中。当然，Postgres 和MySQL 并不是Ruby 仅可用的两个数据库，所以我们也访问了KUBO Takehiro，Oracle 数据库接口

ruby-oci8 的作者之一。我们请教了他关于 NeverBlock 的看法，以及 NeverBlock 是否可以方便的与 ruby-oci8 集成：

我觉得集成不容易。Neverblock-pg 使用了

PGconn#send_query 来登 记一条查询，然后挂起 fiber 直到查询完成。但 ruby-oci8 的无阻塞模式则不是这样。当一个查询被执行时，处于无阻塞模式的 ruby-oci8 等 待结果，但并不阻塞其他线程。在 ruby-oci8 之外不能够增加挂起 fiber 的代码。我们不打算通过修改 ruby-oci8 来适配 NeverBlock。这是因为用户在不用到 NeverBlock 的 fiber 池的情况下，透明的使用无阻塞操作。

另外，我不确定要使用无阻塞操作时，是否一定要用到 NeverBlock。如果通过使用 rb_thread_blocking_region() （ruby 1.9 的新特性），让 ruby-pg 包装那些阻塞性操作，其他线程就不会被阻塞。（可参见 Ruby 线程机制的未来）。

当然，虽然我有这些看法，我还是很欣赏 NeverBlock 在为 activerecord 增加连接池特性方面所做的工作，这些正是我一直想要的。

说实话，我觉得并不是那么重要。SQLite 是一个内置数据库，而不是像 MySQL 或 PostgreSQL 那样使用客户端 / 服务器架构。为了在 SQLite 中支持异步查询，用户得首先将 SQLite 转换为服务器模式，以使得 SQLite 运行于用户应用外的一个单独进程。如果用户真的这么做了，那 么也许使用 SQLite 就不再是一个好的选择。

确实，我个人非常强烈的不主张人们在一个 web 应用的产品版本中使用 SQLite。SQLite 非常适合测试阶段和开发阶段，并且能够很好的与内置的各种应用协同工作，但在一个 web 环境中，SQLite 并不能像客户端 / 服务器模型那样工作。

读到这里，你有什么想法呢？是不是我们为了性能考虑，需要无阻塞的数据库访问呢？