|
|
|
@ -49,10 +49,10 @@ async fn main() {
|
|
|
|
|
|
|
|
|
|
在上一节中,我们介绍了几个解决方法,但是它们大部分都不太适用于此时的情况,例如:
|
|
|
|
|
|
|
|
|
|
- `std::sync::Mutex` 无法被使用,这个问题在之前章节有详解介绍过,同步锁无法在 `.await` 调用过程中使用
|
|
|
|
|
- `std::sync::Mutex` 无法被使用,这个问题在之前章节有详解介绍过,同步锁无法跨越 `.await` 调用时使用
|
|
|
|
|
- 那么你可能会想,是不是可以使用 `tokio::sync:Mutex` ,答案是可以用,但是同时就只能运行一个请求。若客户端实现了 redis 的 [pipelining](https://redis.io/topics/pipelining), 那这个异步锁就会导致连接利用率不足
|
|
|
|
|
|
|
|
|
|
这个不行,那个也不行,是不是没有办法解决了?还记得我们上一章节提到过几次的消息传递,但是一直没有看到它的庐山真面吗?现在可以来看看了。
|
|
|
|
|
这个不行,那个也不行,是不是没有办法解决了?还记得我们上一章节提到过几次的消息传递,但是一直没有看到它的庐山真面目吗?现在可以来看看了。
|
|
|
|
|
|
|
|
|
|
## 消息传递
|
|
|
|
|
之前章节我们提到可以创建一个专门的任务 `C1` (消费者 Consumer) 和通过消息传递来管理共享的资源,这里的共享资源就是 `client` 。若任务 `P1` (生产者 Producer) 想要发出 Redis 请求,首先需要发送信息给 `C1`,然后 `C1` 会发出请求给服务器,在获取到结果后,再将结果返回给 `P1`。
|
|
|
|
@ -108,7 +108,7 @@ async fn main() {
|
|
|
|
|
|
|
|
|
|
一个任务可以通过此通道将命令发送给管理 redis 连接的任务,同时由于通道支持多个生产者,因此多个任务可以同时发送命令。创建该通道会返回一个发送和接收句柄,这两个句柄可以分别被使用,例如它们可以被移动到不同的任务中。
|
|
|
|
|
|
|
|
|
|
通道的缓冲队列长度是 32,意味着如果消息发送的比接收的快,这些消息将被存储在缓冲队列中,一旦存满了 32 条消息,使用`send(...).await`的发送者会**进入睡眠**,直到缓冲队列可以放入信息的消息(被接收者消费了)。
|
|
|
|
|
通道的缓冲队列长度是 32,意味着如果消息发送的比接收的快,这些消息将被存储在缓冲队列中,一旦存满了 32 条消息,使用`send(...).await`的发送者会**进入睡眠**,直到缓冲队列可以放入新的消息(被接收者消费了)。
|
|
|
|
|
|
|
|
|
|
```rust
|
|
|
|
|
use tokio::sync::mpsc;
|
|
|
|
|