导读：本文为Redis 作者 Antirez 就重点功能的发展方向做出澄清，并表明“Redis 没有一个可靠的路线图，多年来我发现走一步看一步才是优秀的路线图”，阅读此文，关注 Redis 功能研发方向。
昨天有位Redis 的用户在Hacker News 上做了以下评论：
虽然我喜欢Redis，但我对目前正在开发的一些功能持怀疑态度。 respv3 协议中的一些功能，虽然听起来很简洁，但是也可能使客户端代码复杂化。 还有细粒度ACL 需要的工作量很大。 我无法理解为什么这些功能是必要的，或者说比其他功能（如多线程支持，更好的持久化模型，数据类型等）的优先级更高。
很多用户将ACL视为Redis Labs 强行添加的功能。 评论中的其他要点也很有趣，我相信这些都值得澄清，以便Redis 社区理解前方的道路。
为简单起见，我将此博客文章分为几部分，对应原始评论中提到的每个功能。
RESP3
正如我在文档上所写的那样，RESP3 的目标是简化客户端环境。我希望每个客户端都有一个较低层次的抽象，不需要尝试重新发明更高级别的接口，例如：redis.call（“get”，“foo”）。不再需要进行转换，因为现有协议在语义上足以告诉客户端response的结构，不需要事先知道大多数命令的元数据。我认为该用户指的是 RESP3 对带外通信的支持，即回复“属性”。
我认为Redis 未来的“客户端缓存”将是非常重要的功能。这是每个可扩展系统的必经之路。但是如果没有服务器参与，客户端缓存失效将是一场噩梦。这就是为什么 RESP3 需要支持回复属性。然而Redis 6 不会实现该功能。 Redis 现有不稳定版本将成为Redis 6.该版本已经有一个几乎完整的RESP3（没有实现属性）实现。实现了RESP3 的客户端可以先不支持属 性，即使对于将来的Redis版本，也可能根本不发送属性数据。对于客户端缓存，必须将连接置于特殊模式。此外，Redis 6 将完全向后兼容RESP2。我认为RESP2 的支持永远不会被移除，因为它是免费的，一旦我们尝试在 RESP2 和 RESP3 之间实现一个抽象层，就没有充分的理由来破坏向后兼容性。
通常我不喜欢在没有充分理由的情况下改变事物，但RESP2 的限制对客户端生态系统有很大影响。我希望从一个客户端到迁移另一个客户端，用户有宾至如归的感受。API 都是Redis API，而不是客户端作者单独的特殊抽象。除了较低级别的API，我不反对更高级的API，但它们应该有一些共同点，客户端应该能够在不知道任何相关命令元数据的情况下发送命令。
ACLs
四年前我自己修改了ACL 规范。我用了很长时间才说服自己现在是实现该功能的时候了：我们在没有任何ACL 的情况需要使用命令重命名等方式来达到目的。不能认为实现ACL 的主要动机是因为企业客户需要安全性。ACL允许出于安全目的对用户进行身份验证，但该功能的主要目标是可运维。
举例来说，你有一个Redis实例，并且计划使用该实例来执行新操作：延迟作业处理。你从互联网上下载了一个库，它看起来没啥问题。但是这个库可以调用“FLUSHALL”并清除所有数据。也许只是库的测试代码里面有这样的命令，然而你意识有问题的时候为时已晚。或者你刚好雇佣了一位喜欢在Redis 实例上调用“KEYS ”命令的”高级”开发人员。
另一种情况是云供应商：他们需要小心地重命名管理命令，甚至为了某些原因而屏蔽这些命令。使用ACL，你就能设置Redis，以便在没有某些身份验证的情况下，阻止默认用户执行任何危险的操作。我认为这对运维来说将是一个很大的进步
此外，AC L是我为Redis AFAIK 写的最好的代码之一。几乎没有CPU成本，除非您使用密钥模式，然而即便使用密钥模式，CPU 消耗依然很低。该实现都在acl.c文件中，其余的代码有一些对ACL API 的调用。ACL完全是模块化的，所以没有增加系统复杂性。实际上，ACL 代码围绕AUTH 命令也做了一些重构。
多线程
Redis 可能通过两种方式获得多线程支持。我相信用户希望的是“memcached相似”的多线程，即能够将单个Redis 实例扩展到多个线程，以便增加QPS。这种设计将I/O，命令解析等多线程化。所以我们称之为“I/O线程”。
另一种多线程方法是允许在其他线程中执行慢速命令，以便不阻塞客户端。我们将这种线程模型称为“慢速命令线程”。
这就是计划：I/O线程方案不会出现在Redis AFAIK中，因为经过深思熟虑之后，我认为该方案太复杂。大部分Redis 的瓶颈实际上是网络或内存。另外，我喜欢share-nothing，所以我想扩展Redis 的方法是改进其对同一主机中执行多个Redis实例的支持，特别是通过Redis Cluster。 因此，2019年主要集中在两件事：
A）redis cluster多个实例能够协调使用本地实例的磁盘，即避免AOF同时重写。
B）我们将把Redis集群代理作为Redis 项目的一部分发布，这样用户就可以在没有良好实现集群协议客户端的情况下抽象出集群。
另外需要注意的是Redis不是Memcached，然而像memcached一样，它是一个内存系统。对于非常简单的数据模型来说多线程（如memcached）非常有意义。对于Redis来说，多线程磁盘存储也是必须的。一个多线程的复杂内存系统将是非常复杂的：Redis 客户端不是孤立的，数据结构也很复杂。例如，执行LPUSH 的线程需要服务于执行 LPOP 的其他线程。获得的收益较少，添加的复杂性也很高。
相比之下，我想要解决的是慢操作问题，并且因为有了Redis 模块系统，我们已经走上了正确的方向。在将来（不确定是否在Redis 6或7中）我们会在模块系统中实现key 级锁定，以便线程可以完全获得对key 的控制以处理慢操作。现在，模块可以实现命令，并以完全独立的方式为客户端创建回复，但仍然需要访问共享数据集，这时候需要全局锁。
更好的存储
最近我们做了多项努力，以改善Redis的基本功能。 最近的最优秀的实现是AOF文件中的RDB前导码。 Redis 4和5中还有很多关于复制的工作，与之相比现在的改进完全处另一个级别。 改进这些功能仍然是我的主要工作之一。
数据结构
从Redis 5 开始，Redis 就支持了Stream 结构。对于Redis 6和7，我们计划优化一些实现，提高内存使用效率。 然而要添加新的数据结构，就需要做很多考虑。 我花了几年时间才领悟到，如何在时间序列和 stream 的背景下使用stream 来弥合lists, pub/sub以及 sorted sets 的差异。 我希望Redis是一组用户可以随意组合的正交数据结构，而不是一组预定义的工具（用户只能按照设计的方式使用）。 Streams是一个抽象日志，所以我认为这是一个非常有价值的结构。 然而对于其他结构我不能完全确定它们是否值得加进核心功能。 无论如何，在最近几年中，添加新数据结构的压力肯定更大。 HyperLogLogs，更高级的位操作，stream，阻塞的sorted sets操作（ZPOP 和BZPOP ）都是很好的例子。
结论
我相信Redis社区应该知道为什么要做某事以及为什么要推迟某些事情。我通过推特进行了大量沟通，但很多人并没有关注这些内容。博客是一种更好的告知社区的方式，因此我需要花时间写博客。需要注意的是，Redis没有一个可靠的路线图，多年来我发现走一步看一步才是优秀的路线图。为Redis制定路线图是愚蠢的，因为OSS核心团队的规模很小，有时我会在几个星期内陷入随机崩溃......任何固定的长期计划都行不通。此外，由于Redis社区提供反馈，我的想法发生了很大变化，所以我每个月都会重写路线图。博客是一个很好的解决方案，至少可以显示当前版本的优先事项/想法，并说明为什么其他想法被放弃。
最后一点：我和Redis实验室在开源项目方面的自由度几乎是无限的。我认为这在行业中是一个奇迹，或者只是说在Redis Labs中的同事都是很好的人，他们明白我们所做的事情源于开源运动并且明智地保持这种方式。如果Redis路线图出问题了，那肯定是我的错误。
