Fix typo in tokio/channels.md

pull/376/head
lijinpeng 3 years ago
parent 8d1b51ceed
commit 1324ee33fd

@ -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;

Loading…
Cancel
Save