在 SpringOne 平台华盛顿大会上宣布的 R2DBC 是一个从头开始设计的实验性 API,用于针对关系型数据库进行反应式编程。最终目标是试图影响 ADBA 规范。
在活动中,Cloud Foundry Java Experience 团队负责人 Ben Hale 表示,R2DBC 的设计原则是基于以下四个原则:
- 利用反应式流类型和模式;
- 访问数据库的整个过程完全非阻塞;
- 把驱动 SPI 压缩为专门实现的最小操作集,且不管可用性;
- 基于驱动 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 团队将要做的事情。
查看英文原文: Experimental Reactive Relational Database Connectivity Driver, R2DBC, Announced at SpringOne
评论