我是内存数据库领域的新手，尤其是 KeyDb 对我来说已经了解了几天，我想知道 KeyDb/Redis 测试过的数据集是否公开可用。我想自己做测试。提前致谢。

我们使用 Redis 已经有很长一段时间了，直到我们得出结论，迁移到 KeyDB 可能是其功能的一个不错的选择。

环境

背景

参考 KeyDB 文档，KeyDB 兼容最新版本的 Redis。

KeyDB 与 Redis 模块 API 和协议保持完全兼容。因此，从 Redis 到 KeyDB 的迁移非常简单，并且类似于您在 Redis 到 Redis 方案中的迁移。https://docs.keydb.dev/docs/migration/

在同一页面中，他们提供了与 KeyDB 兼容的 redis 客户端列表。该列表包含我正在使用的 ioredis。

KeyDB 与此处列出的所有 Redis 客户端兼容，因此不必担心。只需像使用 Redis 一样使用您的客户端。 https://docs.keydb.dev/docs/migration/

问题

如文档中所述。我应该能够在几个小时内轻松迁移到 KeyDB。好吧，事实并非如此！至少对我来说不是！我花了我最后 3 天在互联网上搜索解决方案。我得出的结论是我应该写信给 stackoverflow :)

这个问题有点有趣。客户端实际上正在使用 KeyDb，并且该过程实际上正在设置和检索密钥（不确定，但可能会在错误期间丢失一些数据。）。但是在 10% 的时间里，它给了我以下错误，并在一段时间后继续工作。当我使用 Redis 在我的生产环境中存储会话和其他内容时；我不能冒险忽略这种坚持错误。

我几乎在所有互联网上搜索了这个错误，但没有人提供解决方案，也没有人解释出了什么问题。

幸运的是，该过程“有时”会显示错误堆栈。它指向lib/redis/index.ts:711ioredis 代码内部。我不知道它做了什么。

https://github.com/luin/ioredis/blob/master/lib/redis/index.ts#L711

我在 ioredis github 存储库上发现了一些问题，提到了一些 EPIPE 错误。但它们中的大多数都是关于错误处理的东西，并且都标记为已解决。

我还在谷歌上发现了一些一般的 EPIPE 错误（其中大部分是关于 socket.io 的，这不是我使用的东西。）

包起来

这件事有什么问题？

怎么能做到这一点？使用 Jedis 和 Java。

我现在正在使用hset，但这并不重要。

是否必须发送 lua 代码才能实现这一目标？Jedis是怎么做到的？

我正在尝试使用 KeyDB 来查看是否可以获得以及可以获得多少性能改进，因为 Redis 单线程查询模型肯定存在瓶颈。所以我找到了 KeyDB，他们说他们使用“真正的”多线程对数据库进行并行查询，这与 Redis 不同，它只有 IO 多线程而不是实际查询。

从上面的文档链接：

与 Redis6 和 Elasticache 不同，KeyDB 多线程有几个方面，包括将事件循环放置在多个线程上，使用网络 IO，以及同时完成查询解析。

我的简单测试设置：

1. 首先，我在 Ubuntu (WSL2) 上安装 KeyDB 并让它运行
   1. 我注意到启动 KeyDb 时，有 2 个线程处于活动状态： Thread 0 alive. Thread 1 alive.
2. 我修改了 keydb.conf 以禁用一些保存/持久化，但最重要的是，我将server-threads选项更改为 2: server-threads 2。注意：我也尝试过不使用配置文件，只添加 cmd 标志--server-threads 2并将线程设置为 4，没有区别。
3. 然后我运行一个简单的脚本：
   1. 使用一些简单的 JSON 对象在散列中创建 1M 条目
   2. 创建一个使用两个线程的简单控制台应用程序；一个线程开始在循环中执行非常简单的 SET ( SET key1 1) 或 GET ( )，而另一个线程从哈希 ( )GET key1 1中“获取所有” 。HGETALL testhash第二个线程在开始其“长查询”之前等待 1 秒。

可以在此处找到 GitHub 存储库（使用 StackExchange.Redis 库）。

我的期望：

我希望简单的快速 SET/GET 每次都花费大约相同的时间，而不会因为长查询运行时 KeyDB 中的阻塞而导致任何延迟或节流。

怎么了：

在长查询运行时，简单的快速 SET/GET 会被阻塞/延迟大约 500-700 毫秒，这表明只有一个线程正在使用，因此会阻塞其他操作。这符合 Redis 的工作方式，以及我希望使用 KeyDB 避免的情况。

日志：

“开始长查询”是当我们执行时HGETALL，几乎立即执行，简单的 SET 被限制并占用超过 500 毫秒，而它应该占用 0-1 毫秒，如之前和之后所见。

使用 ServiceStack Redis 客户端：

我也测试过从哈希而不是 SET 中获取，同样的事情。

使用 StackExchange.Redis：在 GitHub reproducable 项目中，在这里找到，我使用的是 StackExchange.Redis 而不是 ServiceStack，我得到了不同的（更糟糕的！）行为：

结论

无论我使用什么客户端库，KeyDB 都会在运行“长查询”时限制请求/查询，即使我有 2 个线程。如果我用 4 个线程启动 KeyDB 并没有关系，同样的行为。

我不知道为什么 StackExchange 的行为与 ServiceStack 不同，但这不是现在的主要问题。

我开始研究如何替换REDIS的问题，找到了KEYDB数据库的描述，但是我没有找到如何开始使用Golang的描述，如果有例子或者谁知道在哪里可以阅读，请分享信息。