node_redis 和 ioredis 是目前使用相对比较广泛的 Node.js Redis 客户端。ioredis 是我在半年前开发的，那时我参与的公司项目对 Redis 的稳定性要求很高，然而在应用开发阶段发现当时使用的 Redis 客户端 node_redis（几乎是那个时候的唯一选择）存在一些严重的 bug，如果不加以修改的话无法继续使用下去。

最初我的想法是给 node_redis 打一些 patch，不过查看源代码后发现要解决这些 bug 需要对代码进行较大范围的重构才行。例如在判断 Pub/Sub 状态时，node_redis 依赖于对 Redis 服务器的响应结果，其本身没有一套完整的状态判断，这导致了一些特殊（但很容易重现）的情况会使 node_redis 内部的逻辑出错从而让应用无法继续工作。此外当时的 node_redis 已经很久没有维护了，我在此之前提交的 Pull Request 也都没有获得回应。所以在当时这种情况下，ioredis 诞生了。

到目前为止，ioredis 已经被国内外众多的公司使用，期间有很多有意思的小故事，比如 ioredis 使用 Gitter （一个类似 Slack 的线上聊天工具）作为用户社区，我偶尔会在里面回答一些问题，后来才发现聊天室里面的一个用户就是 Gitter 的 CTO，他告诉我现在 Gitter 已经全面迁移到 ioredis 了，我们发的每一条消息都经过了 ioredis 的中转。

同一个语言的社区有两个 Redis 客户端既有好处又有坏处。好处就是能给开发者更多的选择，比如当他们发现 node_redis 不支持 Sentinel 和 Cluster 时，就可以选择 ioredis。而坏处就是社区需要维护两个轮子，同样的功能需要在两个地方以不同的方式重复实现一遍。前一段时间 node_redis 的主要维护者 BridgeAR 通过 Twitter 联系我，交流对两个客户端的规划。讨论后我们觉得将两个客户端进行整合是最好的方式。整合的方式是两个客户端将各自的代码逐步地拆分成小的组件，如 node_redis 的 protocol parser，ioredis 的 command parser。而后这些组件会被两个客户端共同依赖，同时其他的开发者也可以更方便地贡献自己的代码。

新的组件都会被放到 NodeRedis 组下，ioredis 的下一个版本 2.0 也将直接使用 node_redis 的 parser，同时我会继续 ioredis 和 node_redis 的维护，也欢迎大家继续使用 ioredis。当然最重要的一点是，希望大家能多多地参与进 node_redis 和 ioredis 的开发中来。