SpringOne平台华盛顿大会上宣布的R2DBC是一个从头开始设计的实验性API,用于针对关系型数据库进行反应式编程。最终目标是试图影响ADBA规范。

在活动中,Cloud Foundry Java Experience团队负责人Ben Hale表示,R2DBC的设计原则是基于以下四个原则:

  1. 利用反应式流类型和模式;
  2. 访问数据库的整个过程完全非阻塞;
  3. 把驱动SPI压缩为专门实现的最小操作集,且不管可用性;
  4. 基于驱动SPI实现多个“人性化”的API。

这是Hale幻灯片中的一个例子,一个简单的Select语句:

connectionFactory.create()返回一个Mono连接。Hale解释说,这个调用的结果是,“最后,当有人订阅,它会获取一个连接,执行查询,然后为每一行返回值,比如说一个整数,最终生成一个整数Flux作为结果,连接的生命周期是在订阅时打开、完成后关闭。”

当然,构建在SPI之上的客户端可以对其进行进一步地简化,Hale给出了这样一个隐藏细节的例子:

下面是使用SPI时一个事务中的Prepared Insert的例子:

正如Hale在演讲中承认的那样,这并不是很好,但同样可以在客户端简化:

有一些替代R2DBC的方法。一种方法是将JDBC封装在线程池中,但这不会提供回压——无界队列将导致资源耗尽,而有界队列将导致阻塞。另一个是ADBA。Hale谨慎地说:

我们很早就与ADBA的工作人员进行了接触,但是,关于CompletableFuture是否真的是Reactive有很多不同的看法,所以我们放弃了,这促成了R2DBC的工作。但现在,R2DBC已经有了经过实际证明的、可以使用的API,我们再次被邀请参与进来。因此,ADBA可能会变成这样,在某种程度上,这是像这样一个项目的最终目标。

至于未来计划,Hale明确表示,R2DBC是一个实验场,虽然它足够稳定可以使用,但绝对不能用于生产环境。需要注意的是,有很多边缘情况,包括缺少BLOB/CLOB处理,并且目前只支持写入一个数据库——PostgreSQL,但是Hale希望看到面向其他数据库的实现。他最后说:

Spring不会生成规范。我们不是规范引导者,也不管理规范。这个项目的全部目标是为了影响ADBA规范,这是最好的情况。但毫无疑问,我不是那种会容忍ADBA规范不好的人。如果他们不接受我们的建议,如果他们没有看到Reactive与async的区别,那么,这就是Spring团队将要做的事情。

Comments are closed.