在 Python 中使用 Redis，基本上都会选择 redis-py 这个库。本质上，它是封装了 Redis 命令，将它们变成 Python 的函数。比如 SET 这个命令，它的使用方式，在 redis 文档中是这么定义的：
|
1 |
SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL] |
然后 redis-py 对应的 Python 函数是这样的：
|
1 |
def set(self, name, value, ex=None, px=None, nx=False, xx=False, keepttl=False): |
redis-py 中有几百个函数，封装了对应的 redis 命令。
这样的好处是你可以使用原生的函数来调用 Redis，返回结果也是 Python 的原生类型。在写代码的时候编辑器可以自动为你补全 Python 函数，调用的什么 Redis 命令也比较清楚，对 Python 代码静态分析就知道对 Redis 做了什么操作。
缺点也显而易见：
- 如果 Redis 对已有命令支持了新的参数，需要 redis-py 支持才能使用。比如 让 HSET 支持多对 key value，给 SET 添加 KEEPTTL 参数，这两个PR。合并之后要等 redis-py 发布新的版本，到应用能真的用的上 redis 的 Feature，将会是很漫长的一个过程；
- 第二个问题是从 Redis 的命令，到 Python 的函数，相当于加了一层中间的转换。首先我要去看 Redis 的文档，知道了 SET 的用法，然后我还要去看 redis-py 的文档，去学习一下在 Python 中是如何抽象的，哪些是值是字面值，哪些值翻译成了 Python 的 bool；
在群里看到过网友这么吐槽，对这个问题总结的比较精辟：
所以，这一层抽象真的有必要吗？Redis 的命令如此简单，我们能否直接给 Redis 发送想要执行的命令呢？
我一直在想， 理想的 Redis Python 客户端应该是这样使用的：
|
1 |
redis.call("SET", "foo", "bar", "XX", "KEEPTTL") |
而接口的定义，显然可以只需要一个，能够通过这个接口接收任何命令：
|
1 2 |
def call(command_name, *args): # package request using resp... |
以目前的 RESP，实现起来还是有点难度的。我在 IRedis 中做了类似的事情，先分享一下 IRedis 里面是怎么做的，阻止我们实现一个这样的客户端的问题是什么。
IRedis 是一个 redis-cli 的替代品，一个命令行 REPL 工具。在 IRedis 中，如果使用 redis-py 这些函数的话，那么一个命令从用户输入，到真正到达 Redis server，要经过这样的转换：cli input -> 分解出来命令，和这些命令的参数 -> 调用相应的 redis-py 里面的函数 -> redis-py 打包成 RESP 协议的请求 -> 发送给 Redis Server。显然太复杂了。并且我认为上面的 问题2 对 IRedis 也是一个不小的限制：使用 IRedis 应该体验到 Redis 最新的 Feature，而不是等到 redis-py 发布之后。
redis-py 中 的 connection.py 是封装了 RESP 协议的内容的，这部分代码解耦的比较好，所以目前 IRedis 只依赖了打包和解析 Redis RESP 协议的部分代码。在 IRedis 中向 Redis 发送命令的代码是这样的（简化了重试之类的细节代码）：
|
1 2 3 4 5 6 7 8 |
def repl(): while 1: user_input = input() command, args = split_command_args(user_input) # connection from redis-py connection.send_command(command, *args) response = connection.read_response() print(response) |
这样如果 Redis 支持了新的命令，IRedis 用户不需要升级 redis-py，甚至不需要升级 IRedis 本身，就可以直接使用新的命令。
So far, so good. 但是有一个我没提到的缺点是，RESP2（redis-py 是屏蔽了 RESP 协议的，如果不熟悉当前 RESP 的话，可以读一下这篇文章，解释的比较好：理解 Redis 的 RESP 协议）的类型太少，比如 LRANGE SMEMBERS HGETALL 三个命令，返回的都是 Array（术语中叫做 multi bulk reply），但其实这三个命令返回的结果分别是：list, set, dict。redis-py 里面是对这些命令的结果做了转换。所以，现在的 RESP 中是无法区分出返回的类型的，这就要求 Redis 的客户端必须记住每一个命令的返回类型。因此，redis-py 在当前的 RESP 协议中，对每一个命令封装是最合理的做法。
IRedis 中我也有同样的问题，所以我用一个 csv 文件整理了所有的命令返回的类型，以针对不同的类型做不同的渲染（redis-cli中并没有区分出类型，所以用户看到的都是 Array）：
在 IRedis 中将不同类型分开解析了
redis-cli 中全部当成 list 显示
另外，当前的 RESP 协议也缺乏很多其他类型，比如浮点数是没有的，要用 string 来返回，boolean 也没有，要用 int 来返回。比如在写 Lua 代码的时候，因为 Redis 协议的本身并没有 Boolean 类型，如果我们要在 Lua 脚本中判断 True/False 的话，必须通过字符串相等来替代。比如这个PR。
除此以外，当前的 RESP 还有其他一些限制。但是我觉得最严重的就是混用了一些类型，导致开发一个语言的客户端必须一个一个地按照 Redis 的文档来实现它的命令。
好在，这个问题在下一代的 Redis 协议 RESP3 里面彻底解决了。RESP3 有丰富的类型：
- Null: a single null value replacing RESP v2
*-1and$-1null values.- Double: a floating point number
- Boolean: true or false
- Blob error: binary safe error code and message.
- Verbatim string: a binary safe string that should be displayed to humans without any escaping or filtering. For instance the output of
LATENCY DOCTORin Redis.- Map: an ordered collection of key-value pairs. Keys and values can be any other RESP3 type.
- Set: an unordered collection of N other types.
- Attribute: Like the Map type, but the client should keep reading the reply ignoring the attribute type, and return it to the client as additional information.
- Push: Out of band data. The format is like the Array type, but the client should just check the first string element, stating the type of the out of band data, a call a callback if there is one registered for this specific type of push information. Push types are not related to replies, since they are information that the server may push at any time in the connection, so the client should keep reading if it is reading the reply of a command.
- Hello: Like the Map type, but is sent only when the connection between the client and the server is established, in order to welcome the client with different information like the name of the server, its version, and so forth.
- Big number: a large number non representable by the Number type
这样，我们可以实现这样一个客户端，完全不关心执行的命令，不需要对特定的命令进行支持（一些影响客户端行为比如 CLIENT REPLY OFF 依然需要特殊支持），就可以与 Redis Server 交互，无论 Redis 对已有命令做出了修改，或者支持了新的 Feature 新的命令，客户端都不需要做升级，应用就能直接使用。
我尝试写一个基于 RESP3 的这样的客户端，如果有兴趣可以在这里 follow：https://github.com/laixintao/resp3-py
RESP3 并没有采用基于现有数据打包结构（BSON 或者 msgpack）的方式实现，简单来说原因是 1）这些只是数据结构，依然要实现通讯层的东西，没有脱离要“设计一个通讯协议”的问题。2）引入了复杂性，用户本质上要和两个库相处 3）这些数据结构不是基于流处理的，比如 json，你要读完（至少读一定程度）才能开始处理，所以需要某种 buffer，可能是潜在的性能瓶颈。而 RESP3 是在 TCP 上的一种简单的协议，在协议上发送大的字符串的时候不需要全部读完，客户端就可以开始处理。
往远处想，RESP3 的意义不仅仅是适用于 Redis 的协议，甚至不局限于数据库，基于 RESP3 实现 RPC 也是完全可以的。
在 Unix 的哲学中，文本是优于二进制的，RESP3 中说道：
RESP 在过去的几年中工作的非常好。这说明，如果用心设计，那么一种简单的、用户可读的协议不会成为通信的性能瓶颈，而且这种对用户阅读友好的协议对客户端生态的建设大有好处。
最后，RESP3 是不兼容 2 的，而 Redis6 只支持 RESP3，这意味从 Redis5 迁移到 Redis6 可能要麻烦一些。这个设计选择可以看 Antirez 的博客：Why RESP3 will be the only protocol supported by Redis 6
RESP3 的 spec: RESP3
hah 荣幸，我的文章还会被引用。
https://www.youtube.com/watch?v=kliQLwSikO4 这个视频还是蛮值得看的
哈哈，我本来想跟你聊聊这个想法来着，后来觉得有点难说清楚，就写下来，打算今天发你看下的~
这个演讲我也看过，非常精彩，还写过一篇笔记：https://www.kawabangga.com/posts/3590
可惜 Redis 天生异步的特性无法改变，不然这场景不光可以用于缓存，甚至可以用于动态改变程序中内存的值（进而配合 if-else 控制程序的行为），而不会带来额外的性能开销和开发成本（在拥有 client-cache 库的情况下）。
其实我自己觉得去重新写一个协议并不是什么非常好的做法。。
其实还是协议解析所带来的 cost，一个全新的协议，意味着主流语言的客户端都需要重新实现一份对应协议的解析，这个对于自己扩展和定义来说其实是并不友好的
其实我更喜欢 etcd 这样利用 protobuf 这种自带 DSL 和 Code Generator 的 Message Protocol 的做法。。这样比让社区直接去读 SPEC 要爽的多（逃
如果现在有协议能满足的话，那是用现有的会比较好。protobuf 确实既有数据结构、又有通讯协议，像是一个比较好的全套的方案。
但是 Redis 应该要求还是高一些，比如 Redis 协议支持客户端不需要完全读完一个字符串（不需要读到}之类的符号）才可以开始处理，不知道 protobuf 支持不支持。另外用 protobuf 开发成本和调试成本也高了一些，一些小众语言如果没有 protobuf 客户端会麻烦一些。现在的 Redis 协议，是完全可以拿 nc 当客户端在 bash 中使用的。
当然，貌似很多公司也直接在 Redis 里面存储 protobuf，好像微博是这样的。