42｜阶段实操（7）：构建一个简单的KV server-如何做大的重构？

很多时候，实际工作修改老系统，老系统啥单元测试啥的都没有😂，果真是动一行，就是牵一发而动全身，这方面老师有什么指导性原则么。

我有个疑问, tokio 本身不就是 支持了多路复用吗 用 yamux来整合多路复用的意义是什么?

我现在有个困惑 这几天一直没想到答案 比如老师说的yamux 来做连接的多路复用 如果客户端不能用rust 有办法对接吗? 我试了一下 如果服务器yamux 过的服务 对方如果不是yamux包装的 请求 会报错 就是不能当成常规的tcp连接来处理

写测试代码的确有助于我们思考，从而把代码写的更好。

tokio家出了，tokio-yamux，哈哈哈，这下不用util转了

思考题1: 主要考虑如何检测 receiver 被 drop 的情况以及何时触发 gc 操作；对于如何检测 channel 被关闭有两种方式： 1. 每个 sender 发一次消息便可知道，这种方法低效，而且一方面需要考虑用于检测的消息不能和用户可能发送的消息出现重合，另一方面发送出去的消息还可能会被用户看到，不考虑这种方式 2. tokio::mpsc::sender 提供了 is_closed 方法来判断 channel 是否关闭，简单高效。如果使用的 channel 没有提供这个方法，可以考虑仿照第 35 讲中的 channel 的实现，对 channel 进行包装并增加一个原子计数来判断 receiver 的数量 有了检测方式，接下来就是考虑触发时机，考虑到并发情况下，访问 subscriptions 会有锁的问题，而且这种情况不会太频繁，因此可以放在 unsubscribe 的时候进行检查和清理。 思考题2：如果要提供 PSUBSCRIBE 功能，考虑增加一张 patter 表，按照 glob::Pattern 来匹配，则表的形式为 patterns: DashMap<Pattern, DashSet<u32>>，其中 DashSet 用于保存 subscription id。在 publish 时候，遍历 patterns 并于 channel 进行匹配，匹配成功则取出 subscription id 并发送一条消息。 思考题的完整实现可以参考：https://github.com/Phoenix500526/simple_kv/blob/main/src/service/topic.rs

二刷，终于跟着把代码写下来了

有一个问题, 假设一个client sub了很多topic (同时有其他client在这些topic上做publish) sub的client端如何区分一次response是上一次sub的CommnadResponse::ok还是之前某次sub的topic上push来的新内容?