IRedis 开发记录:Redis 命令语法的处理

我最近在写一个命令行应用程序,一个支持自动补全、命令校验、语法高亮的 redis-cli 。项目的地址:

https://github.com/laixintao/iredis

写这个插件是想达到 mycli/pgcli 的那种效果,让 redis-cli 用起来非常顺手,本质上,这又是一个满足我自己个人需求的项目。但是我觉得应该很多人会喜欢这个。

开发的过程中遇到了很多有意思的问题,一直想分享一下,但是最近太忙了,白天工作比较忙。晚上我基本都花在写这个项目的代码上,没有时间系统的写一下。今天这篇文章批评了我这里面写过的一段正则,所以今天借这个机会,就写一下吧。

这个正则在项目的代码库里面:代码地址

为什么用这么大一个正则表达式呢?

完成语法校验、高亮,基于语法的补全,肯定要实现一个 lexer。这个 Lexer 是写一个状态机,还是用一个正则去匹配语法,基本上是每天都在想的问题,也每天在想用正则是不是对的,现在看来,遇到了很多问题,但是多都解决了。

对于这个 lexer 我一开始是写的 Pygments lexer,见这个commit 。但是我后来选择了用一个正则表达式来处理所有的 Redis 命令:任何能match这个正则的字符串就是一个合法的 Redis 命令。为什么呢?因为 Redis Grammar 基本不能叫做一个 Grammar,它基本没有 Grammar。要么是一个 Command 后面跟一个 key,要么是 Command 后跟一个 DB index 这种,如果你写一个 Lexer,你会发现全都是一层扁平的 if-else。

所以我放弃了用Lexer,直接用正则。

这个正则难理解吗?

我觉得不难,首先一个 command 属于一种格式,比如 command + key 是一种,command + ip + port 也是种,我是这么对这些 command 分类的:ip/port/key/fields 这种基本的token定义在最前面,并且每一种格式都会有单元测试覆盖。我觉得无论是维护还是新手理解都是可以的。

这么做的另一个好处是,我可以直接使用正则表达式里面的分组,将token拿到,lexer和 completer 都变得很简单,completer 源代码。但是你可以去看下 mycli 的 completer 。

回到本文中:

这个正则表达式你们自己都看不下去了,所以才会需要使用拼接的方式生成。

这个说的不对,我很冤枉。通过我的 commit log 可以看出,我选择用正则,是一开始就想好了要拼接的,先定义基本的 Token,然后用基本的 Token 定于语法。

费脑子,难以理解,难维护。

这不对,可能读者没有按照我的方式理解,现在这个项目开发比较快,不好写文档(我也没啥时间写),因为都在变。如果我写完了稳定你在看的话就简单多了。首先是 command_syntax.csv 文件,定义了每一个 command 的语法。然后 grammar 里面解释了每一种的语法的组成,按照字面就可以理解。比如 <command-key-field> <key> <field> ,<command-key> <key> 我觉得无论是下面的大正则,还是csv文件,都是比较好理解的。

这个组织是扁平的,其实比 Lexer 好理解、维护不少。

并且每一种语法都带测试,测试已经帮我发现了很多问题。

其实这么做也有一些坑。比如用户输入第一个字符是空格,那么按照我那个正则,空格是“可能匹配”所有的情况的。就导致用户输入第一个空格,整个进程会卡10+s。解决办法是我patch了原生的 Completer,strip() 之后的空字符串不做 completer。(PR

compile 太慢的问题,我想过去缓存 re.compile 的结果(laike9m 的建议,我觉得这个想法太天才了。)。但是最后放弃了,原因见这里

现在这个问题是通过应用在启动的时候新启动一个线程去编译正则,主线程正常接收用户输入来实现的。

还有一个坑是,这个正则其实不是Python本身的正则,断言无法使用,{} 风格的 repeat 无法使用,所以必须用很多 tricky 的方式绕过去。这导致有一些语法树也很难实现,比如这个

但总体上,我觉得相比 Lexer,是比较好维护一些,但是功能弱一些。

 

下面再说一个好玩的东西,比较烧脑,我觉得可以作为一个不错的面试题目:如何实现 Bash 风格的引号处理?要注意双引号里面可以有单引号,单引号里面可以有双引号。双引号里面可以有 \ 转义的双引号,单引号也是。答案在这里。这个 PR 里面也有一个单元测试,有兴趣的同学可以试下能否写一个更优雅的函数,来通过这个单元测试。

最后,这个项目我跟朋友说了之后,得到很多不错的 Feature 建议,未来想要实现的都记录在 issues 里面了,有兴趣的可以看下。如果您有什么想法也可以跟我交流下。主要的目的是实现一个行为和 redis-cli 一致、但是更好用的 redis-cli。

 

附录:本文所谈论的原文相关的部分,这里备份一下,以防读者不知道我在说啥:

多说一句
以下内容与本次讨论的re.compile无关。

@Manjusaka给出了一个compile需要3秒钟的大型正则表达式,并以此作为例子说明re.compile的合理性。

首先这种情况下,确实需要提前re.compile。

但我所想表达的是,在这种情况下,就不应该使用正则表达式。既然要做Redis的语法校验,那么就应该使用有限状态机。这种使用很多的f表达式拼出来的正则表达式,才是真正的难以维护,难以阅读。

否则为什么里面需要用一个csv文件来存放命令呢?为什么不直接写在正则表达式里面呢?使用CSV文件每行一个命令尚且可以理解,但是SLOT/SLOTS/NODE/NEWKWY这些正则表达式,可就说不过去了。或条件连接的每一段都要加上这些东西,如果直接写进去,这个正则表达式你们自己都看不下去了,所以才会需要使用拼接的方式生成。

我在读这段代码的时候,首先看到正则表达式里面的t[xxx],会先去找t是什么东西,发现t是一个字典,字典是在commands_csv_loader.py中生成的,然后去到这个文件里面,发现它读的是一个存放Redis命令的CSV文件。然后去项目根目录读取这个csv文件的内容,知道了它的结构,于是推测出t的结构。然后再回到正则表达式里面,继续看这个超大的正则表达式。整个过程会非常费时间和脑子。

但是,我又不能直接打印REDIS_COMMANDS这个变量,因为它多且乱,不同命令长短不一,拼出来以后再打印出来根本没法看。

这个正则表达式只有两位维护者知道什么意思,如果别人想贡献新的Redis命令,那么理解这个超大正则表达式都需要花很久的时间。

如果换成有限状态机,并且t使用Python的data class来表示,而不是使用字典,那么就会简洁很多。有限状态机的一个特点是,只需要关注当前状态、转移条件和目标状态,可能一开始写起来有点麻烦,但是以后维护和新增,都是直接定位目标,直接修改,不用担心会影响不相干的其他地方。

算上维护时间,正则表达式真是一个非常糟糕的方式。

IRedis 开发记录:Redis 命令语法的处理”已经有2条评论

    • 谢谢!这个很有用。

      但是发现一些细节的地方还是不太一样,比如 redis-cli 是可以使用单引号里面的转义单引号的,比如:

      而 Shell 是不允许的,shell 不管转义,只要遇到一个单引号,就会把前面一个单引号给关掉。

      _strip_quote_args 是我自己实现的一个函数 现在看起来问题不大。

      谢谢你的推荐,之前我都不知道这个~

Leave a comment

电子邮件地址不会被公开。 必填项已用*标注