快速的未来即将来到您所在的城市的一场活动。
在 Redis Released 与我们共聚
share
初次接触 Redis 的用户可能会注意到的最令人惊叹的事情之一是 42 页长的客户端 列表，所有这些客户端都是由 Redis 的伟大开源社区开发的。目前，它包含 218 种不同的客户端！
该列表不仅涵盖了所有主流编程语言，还涵盖了在撰写此博客之前我从未听说过的语言，如 Racket、Rebol 和 Lasso。从技术角度上讲，该列表涵盖了36 种不同的编程语言！（我想你已经明白了。也许我以后可以去掉“！”…）
乍一看，编写一个 Redis 客户端似乎是一项简单的任务。你要做的就是在基于文本的 Redis 协议 (RESP) 中，对 Redis 命令 进行逐一实施。为了准确，该列表包含264 个不同的命令！（抱歉，忍不住又添加了“！”）
因为这 264 个命令仅仅是冰山一角。如果你真的想利用 Redis 的全部功能，仅覆盖这些命令并不能体会 Redis 的优势。除了这些“简单”的命令之外，Redis 还支持当今任何 NoSQL 数据库都会支持的功能：高可用性、分片、事务、访问控制列表 (ACL)、通知 和 可扩展性。
为了保持 Redis 的简单性和稳定性，大量的处理会被分流到客户端。例如，为支持 Redis 事务，客户端必须承诺所有操作都在同一确切的套接字上完成，并且只要事务尚未“执行”，客户端就不能对该套接字进行多路复用。在开始开发新的 Redis 客户端时应对这些细微差别进行考虑，而在支持高可用性和 集群 时，情况会变得更加棘手。
大约两年前，在 Redis 代码移至 Redis 组织 之前几个月，我们开始思考：如何确保 Redis 用户不仅能获得最好的 Redis 服务器，还能在使用 Redis 提供的最新最棒功能时，获得最佳的开发体验？
我们开始接触大量 Redis 社区使用的不同客户端，并将目标设定为帮助客户端维护人员快速了解 Redis 的庞大功能集。首先，我们与许多维护人员组建了一个论坛，为他们提供一个平台，让他们分享自己的经验和难题，同时也让 Redis 核心团队获得他们的直接反馈。
然后，我们在 10 种领先的编程语言中，对更广泛采用的客户端中的差距和缺失特性进行了映射。我们意识到，尽管有些客户端每周有数百万下载量，但它们仍然缺少许多用户无法利用的有价值特性（如 Redis 集群或流水线），因此我们立即开始为这些客户端贡献代码。
最后，在采访许多 Redis 用户后，我们意识到用户可以从中选择的客户端的惊人多样性表明，引导 Redis 客户端是极其简单的，但是维护最新客户端是一项全职工作，用户发现很难决定选择哪个客户端以及哪些客户端可以长期依赖。
在去年，我们开始建议一些更广泛采用的客户端加入 Redis 组织，因此我们很高兴地欢迎三位新成员 Jedis、node-redis 和 redis-py。这三位客户端加入了资深成员 Hiredis 和 redis-rb。我们希望这将减少用户之间的困惑，增加他们对客户端路线图的保证，并帮助我们确保这些客户端提供完整的 Redis 体验。
过去几个月中相当忙碌，这三位客户端进行了一次彻底的改头换面。添加了一长串缺失特性，以确保客户端支持 Redis 提供的所有好东西，同时也会进行重构以提供更“现代”的体验（这些客户端已超过 10 年）。这项艰苦工作的成果是为每位客户端提供了一个新的第 4 版。欢迎您下载新的客户端候选版本 Jedis@v4、node-redis @v4 和 redis-py@v4。请分享您的反馈。
工作才刚刚开始，路线图包含一些有趣的特性，因此在不久的将来会推出更多特性。其中一些是添加对最广泛采用的 Redis 模块的本机支持，如 RediSearch 和 RedisJSON，这应简化开发人员体验。此外，还有一些备受期待的完整其他特性，如 客户端侧缓存 支持、Redis 中添加的新 Redis 协议 (RESP3)、新的 Stream API 以及在 Redis 7 中即将推出的 Redis 函数。
