笔记在github,觉得有用的给个 Star 。
此笔记只是记录在使用 rust 遇到的一些坑或者一些比较好用的工具或者其他的东东。本人主要用 rust 开发网络相关的程序或者桌面程序,因此不涉及音视频和其他的领域。
cross:跨平台编译,甚至在 github actions 也可以直接用cross。
tarpaulin:单元测试覆盖率。
min-sized-rust:减少编译后的二进制文件大小。
常用的 tokio 异步运行时不多说了。http web 框架可能有争议,比如 warp,actix-web 可能性能会好一点,但是 axum 写起来更简单。sqlx 虽然直接写 sql ,相信我,其他的 ORM 框架更难用!
tracing:tokio 的日志模块,非常强大,在 tokio 运行时中强烈建议使用 tracing 配合 tracing-appender 做日志。
hyper:开发底层 http1 、http2 必备的 crates 。
axum:http web 框架,CRUD boy 必备。
sqlx:sqlx 框架,CRUD boy 必备。
reqwest:http client 。
clap:开发终端工具/命令行程序必备。
openssl:openssl 相关,由于很多 crate 是基于 openssl 的,一般都是作为 vendor 引入编译的时候直接一起编译。
如果用 rust 做 web 程序,根本用不到生命周期。我至今还不懂生命周期,照样用 rust 开发 web ,技术栈就是 axum+tracing+sqlx+reqwest 。
先说答案,默认的 allocator ,在并发数升高后会导致内存飙升,且并发数降低时,内存不会降低。当前的解决方案是使用 MiMalloc(本人已经验证过,效果良好)。具体的问题讨论在这里。
互斥锁并不慢,我使用互斥锁来存储 redis 的所有数据,最后多线程的压测结果,rcache 的吞吐量是 redis 的两倍。
先说结果,不一定,而且异步的程序相比同步的程序肯定要慢的。
什么时候使用异步运行时开发呢?
什么时候使用同步运行时开发程序呢?
常用场景:我看 tokio 里面有 Mutex 我就直接用了,没想那么多。
这个 Mutex 的性能很低,相比 std::sync::Mutex 性能低一倍以上。如果对性能敏感的应用可以直接在异步运行时中使用 std::sync::Mutex 。感兴趣的可以看一下 tokio 的关于 Mutex 的文档。压测的程序在这里.但是在异步运行时中使用 std 的 Mutex 时需要注意的原则是“锁保护的代码段不跨越 await”。
let a=b.await?;
let c=a.read().await?;
let c=b.and_then(|d|d.read()).await?
看上去第二种写法只 await 一次,其实如上两种写法性能上没有本质差别,第二种写法只是使用了 future 这个 crates 提供的内部的状态机。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.