redis-async

使用Tokio和Rust的future创建异步Redis客户端。 文档

发布

API目前为低级，可能会发生变化。

最初我专注于单服务器Redis实例，另一个长期目标是支持Redis集群。这将使实现更加复杂，因为它需要路由和处理如MOVED之类的错误条件。

最近更改

版本0.14引入了实验性TLS支持，使用特性标志with-rustls启用Rustls支持，或使用with-native-tls启用本地TLS支持。为了实现这一点，对公共API进行了其他一些小的更改，特别是现在需要单独的host和port参数，而不是单个addr参数。

其他客户端

在启动此库时，没有其他使用Tokio的Redis客户端。然而，当前的情况更为竞争激烈。

• Redis-RS - https://github.com/mitsuhiko/redis-rs - Rust的最早Redis客户端现在支持使用Tokio的异步操作。
• Fred - https://github.com/azuqua/fred.rs - 此客户端也支持Redis集群。

用法

在redis_async::client中有三个函数提供功能。一个是低级接口，一个是高级接口，第三个是专门用于PUBSUB功能的。

低级接口

函数client::connect返回一个解析为同时实现Sink和Stream的连接的future。这些各自独立工作以允许管道化。匹配响应与请求的责任在于调用者。客户端也有责任将应用数据转换为resp::RespValue实例以及相反（有可用于常见示例的转换特质）。

与其他Redis客户端相比，这是一个非常底层的API，但这是出于两个原因故意设计的：1）它是功能型Redis客户端（即能够支持所有类型的请求，包括阻塞请求和流式响应）的通用分母；2）它会产生干净的Sink和Stream，这些与其他基于Tokio的库可组合。

如果与Redis服务器的连接丢失，此低级别连接将被永久关闭，调用者负责处理此情况并在必要时重新连接。

对于大多数实际用途，此低级别接口不会被使用，唯一的例外可能是MONITOR命令。

示例

此低级别接口的一个示例在examples/monitor.rs中。可以使用cargo run --example monitor运行，它将一直运行，直到按Ctrl-C停止，并显示针对Redis服务器运行的每个命令。

高级接口

client::paired_connect用于大多数Redis命令（那些一个命令返回一个响应的命令，它不适用于PUBSUB、MONITOR或其他类似命令）。它允许发送Redis命令并为每个命令返回一个Future。

命令的发送顺序与调用send时的顺序相同，而不管未来是如何实现的。这是为了让我们能够利用Redis的功能，通过隐式管道化命令。这的一个副作用是，对于许多命令，例如SET，我们根本不需要实现未来，它可以被认为是即发即忘；但是，最后一条命令的最终未来确实需要实现（至少）以确保观察到正确的行为。

在通信到Redis服务器失败的情况下，此连接将尝试重新连接。但是，命令不会自动重试；这是调用者的责任来处理此情况并决定是否应该重试特定的命令。

示例

请参阅examples/realistic.rs，其中使用了完全人工测试数据，它在模拟现实世界模式方面是现实的，即某些操作取决于其他操作的结果。

这表明代码可以以直线方式编写 - 遍历外循环，对每个值调用INCR并使用结果将数据写入唯一的键。但是，当运行时，各种调用将被管道化。

为了测试这一点，可以使用类似于ngrep的工具来监控发送到Redis的数据，因此运行cargo run --release --example realistic（需要设置--release标志，以便缓冲区填充速度比发送到Redis服务器的数据包速度快）以显示数据流

interface: lo0 (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 6379 )
#####
T 127.0.0.1:61112 -> 127.0.0.1:6379 [AP]
  *2..$4..INCR..$18..realistic_test_ctr..*2..$4..INCR..$18..realistic_test_ctr..*2..$4..INCR..$18..
  realistic_test_ctr..*2..$4..INCR..$18..realistic_test_ctr..*2..$4..INCR..$18..realistic_test_ctr.
  .*2..$4..INCR..$18..realistic_test_ctr..*2..$4..INCR..$18..realistic_test_ctr..*2..$4..INCR..$18.
  .realistic_test_ctr..*2..$4..INCR..$18..realistic_test_ctr..*2..$4..INCR..$18..realistic_test_ctr
  ..
##
T 127.0.0.1:6379 -> 127.0.0.1:61112 [AP]
  :1..:2..:3..:4..:5..:6..:7..:8..:9..:10..
##
T 127.0.0.1:61112 -> 127.0.0.1:6379 [AP]
  *3..$3..SET..$4..rt_1..$1..0..*3..$3..SET..$1..0..$4..rt_1..*3..$3..SET..$4..rt_2..$1..1..*3..$3.
  .SET..$1..1..$4..rt_2..*3..$3..SET..$4..rt_3..$1..2..*3..$3..SET..$1..2..$4..rt_3..*3..$3..SET..$
  4..rt_4..$1..3..*3..$3..SET..$1..3..$4..rt_4..*3..$3..SET..$4..rt_5..$1..4..*3..$3..SET..$1..4..$
  4..rt_5..*3..$3..SET..$4..rt_6..$1..5..*3..$3..SET..$1..5..$4..rt_6..*3..$3..SET..$4..rt_7..$1..6
  ..*3..$3..SET..$1..6..$4..rt_7..*3..$3..SET..$4..rt_8..$1..7..*3..$3..SET..$1..7..$4..rt_8..*3..$
  3..SET..$4..rt_9..$1..8..*3..$3..SET..$1..8..$4..rt_9..*3..$3..SET..$5..rt_10..$1..9..*3..$3..SET
  ..$1..9..$5..rt_10..
##
T 127.0.0.1:6379 -> 127.0.0.1:61112 [AP]
  +OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+OK..+O
  K..

请参阅“性能”部分了解这有什么影响。

PUBSUB

Redis中的PUBSUB工作方式不同。一个连接将订阅一个或多个主题，然后接收发布到该主题的所有消息。因此，paired_connect的单请求/单响应模型将不起作用。为此目的提供了一个特定的client::pubsub_connect。

它返回一个将解析为 PubsubConnection 的未来，这提供了一个 subscribe 函数，该函数接受一个主题作为参数并返回一个未来，一旦订阅得到确认，就解析为包含发布到该主题的所有消息的流。

如果连接到 Redis 服务器的连接中断，此连接将尝试重新连接。但是，任何现有的订阅都将终止，调用代码有责任根据需要重新订阅主题。

示例

请参阅examples/subscribe.rs。此示例将监听一个主题（默认为：test-topic）并在接收到每条消息时打印出来。要运行此示例：cargo run --example subscribe然后在另一个终端中打开 redis-cli 连接到同一服务器并发布一些消息（例如：PUBLISH test-topic TESTING）。

性能

由于示例都已过时，我已从项目中删除了基准测试。我打算在某个时候创建一个单独的基准测试存储库，该库可以更公平地对本和其他 Redis 客户端进行性能测试。

下一步

• 更好的文档
• 测试所有 Redis 命令
• 决定支持 Redis 事务的最佳方式
• 决定支持阻塞 Redis 命令的最佳方式
• 确保所有边缘情况都已完成（例如，返回集合、nil 等的 Redis 命令）
• 与其他 Redis 客户端进行全面的基准测试

许可证

根据您的选择，许可协议为以下之一

• Apache 许可证，版本 2.0 (LICENSE-APACHE 或 https://apache.ac.cn/licenses/LICENSE-2.0)
• MIT 许可证 (LICENSE-MIT 或 http://opensource.org/licenses/MIT)

。

贡献

除非您明确声明，否则根据 Apache-2.0 许可证定义，您提交的任何有意包含在作品中的贡献都应双重许可，如上所述，无任何附加条款或条件。