背景

AliSQL在云栖大会宣布开源,并有幸请到MySQL之父、MariaDB创始人Monty一起见证。

图1. AliSQL开源瞬间

我们在将消息公布到社区之后,也同时关注社区的反馈。以下是对于评论的评论。

handshake protocol

声音:以阿里的个性就是大多数开源了 push 到 github 后面就不怎么管了

其实这么说的人并没有真正全面的去看阿里开源的趋势,大家会看到这几年的分支维护的是越来越健康的。“后面就不怎么管“,这里的“后面”说得很有艺术性,除了天地之外没有什么东西是保证天长地久的。活跃三天和活跃三十年,只要停下来,你说的“后面”就都是对的。如果以这个为标准,那么不只是中国的开源分支,全世界的开源产品都是到“后面”就不维护的。

因此我们眼中的健康的开源会是什么样呢?我觉得最重要的是态度,然后是天时地利。 态度是:我们把开源分支和维护作为我们的一个小理想在保护。只要条件还允许,我们会持续维护。天时地利是:那些条件。

以 AliSQL 的开源策略来说,我们希望节奏上是RDS线上经过验证的、稳定使用的patch才发布到开源分支。所以我们可以保证的是,只要阿里云RDS的业务在,这个分支的维护就会持续。 大家会看到我们接下来会每个季度至少发布两个Release Notes,把我们认为稳定的和有足够应用场景的patch发布到开源分支。 本次发布开源代码同时我们发布了新的Release Note,增加了TokuDB和秒杀场景功能 支持。

声音:Release Notes 里两个版本号竟然是一样的

其实版本号不同,你需要把发布日期也一起带进去看。AliSQL的版本策略是这样的,我们会持续 rebase 到官方最新或次新的GA版本,但是AliSQL要保持自己的更新节奏,因此我们的版本号格式是官方base版本+(发布日期)。

这样的好处是大家从版本号可以得到足够的信息,包括与自用 MySQL 的版本对比和分支活跃情况。

声音:issue#2 ~ issue#7 是什么鬼👻?也是 KPI 的一部分?

并不是所有事情都要跟 KPI 挂钩,尤其issue里的“赞”,没有意义。 作为分支管理者,对于外部参与者的称赞,我们只能表示感谢,然后关闭。难道还可以删除吗?话说好像 GitHub 也没有删除发言的功能,只能修改,总不能修改别人的评论。

至于内部的同学,在 issue 发“赞”我们是批评的。因为在github上最直接的赞,是Star;最有直接价值的赞,是提问题和改进建议;最有长远价值的赞,是提需求或者pull request。 比如上周末 @DarkiT 同学提的建议“建议官方帖个标准的my.cnf的配置” 就非常好,感谢。我们已经在 wiki 上更新了三个不同规格的推荐配置。

声音:就不能把优化合并到官方 MariaDB 或 MySQL 么?

如果所有的patch都能合并到MariaDB,我们又何必这么麻烦再单独维护一个分支呢。如果可以而没有这么做,MariaDB的创始人Monty肯定是第一个提出反对意见的。

实际上的情况是:

  1. 我们会把能够合并到MariaDB或MySQL的patch提交上去。这篇文章 里面提到的patch,其实就都是提交到MySQL,并已经被5.7合并入主干的patch;
  2. 有一些patch是不够general,但是我们觉得对某个垂直场景有效果的。

这里举个例子,AliSQL里面有 COMMIT_ON_SUCCESS 这个hint,作用是,如果带此hint的语句执行成功,事务就默认提交。这个有什么好处呢?正常的使用方法是更新、等待成功、发commit。加这个hit可以减少事务提交的最后一次交互,在系统压力大或者网络较长的场景下,这是可以减少事务持续时间,提升整体吞吐量的。

这样的 patch 其他分支未必会接受,但对我们自己和我们的用户来说,在一些场景下是有效的,我们就去维护。

展望:从公司力量到社区力量

“事实上很多成熟的开源项目都是商业公司主导或贡献的”(from @incompatible),此句为真相。 同时,我们也看到,一个成熟项目一定是社区力量一起来完成的。因此我们真诚希望在GitHub上能够看到pull request、功能需求、IDEA、测试结论。

相信每个公司的DBA都偶尔有这么一个想法:要是MySQL支持xxx这个功能,我就爽了。但是没有开发和维护能力?没有关系,提到issue中,如果这是一个在某个方向足够通用的需求,我们或者社区其他开发者,会去实现的。

阿里云RDS团队有没有做这件事情的驱动力呢? 有的,以现在RDS的用户量和覆盖场景,你的需求,也一定是一部分RDS用户的需求。