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来表示，而不是使用字典，那么就会简洁很多。有限状态机的一个特点是，只需要关注当前状态、转移条件和目标状态，可能一开始写起来有点麻烦，但是以后维护和新增，都是直接定位目标，直接修改，不用担心会影响不相干的其他地方。

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

---