9 posts tagged with "Performance Engineering"

并发设计的第一步不是 go func()，而是知道工作在等待什么、占用什么，以及允许多少工作同时存在。

本期建立全系列的成本模型：CPU 密集、网络 I/O、同步阻塞和排队分别如何影响 Go runtime，并把目标 RPS 转成 goroutine、连接和内存预算。

零拒绝不是稳定性目标。系统超过容量时，及时拒绝一部分请求，才能保护已接纳请求和故障恢复能力。

本期专门处理“流量大于处理能力”。我们把限速、限并发、队列、重试和熔断放进同一个反馈系统，而不是堆叠互不理解的中间件。

并发安全不是“没有 concurrent map panic”，而是所有共享状态的不变量在任意合法交错下都成立。

本期建立同步原语的选择方法，并用 race detector、压力测试和业务不变量验证正确性。

排障不是随机抓火焰图，而是从用户影响和资源饱和提出假设，再选择能证伪它的证据。

本期完成系列闭环：建立压测方法、诊断端口和线上 Runbook，并复现 goroutine 泄漏、锁竞争、连接池耗尽与内存增长。

目标不是背 API，而是建立一套能设计容量、约束资源、证明正确性并处理线上事故的并发工程方法。

这个系列围绕同一个“高扇出聚合服务”逐期演进：入口接收请求，并发访问数据库、缓存和 RPC，最后聚合结果。每一期都会保留可复现实验、错误版本、修复版本和验收指标。

这张由 ImageGen 生成的系列概念图把高并发抽象成一条受控数据流：左侧大量青色任务先进入有界队列，中间由少量执行核心调度，右侧连接多个下游节点；少量橙色信号表示被监控和限制的过载，而不是任其扩散成雪崩。

Rust 的类型系统可以阻止不安全共享，但不会替你决定该共享多少、排队多久和何时拒绝。

本期先区分线程并行和 async I/O，并理解所有权、Send、Sync 与 Arc 真正保证什么。

async worker 上一次 200 ms 同步阻塞，影响的可能不是一个请求，而是同线程上的整批 task。

正常流量下快只是起点；过载时资源有界、故障后能够恢复，才是生产高并发。

Rust 消灭了一大类内存数据竞争，但生产高并发仍需要主动设计容量、取消、背压、锁顺序和故障恢复。

这个系列使用 Rust + Tokio + Axum 构建与 Go 系列相同的高扇出聚合服务。相同的负载模型便于比较语言差异，文章重点则放在 Future、协作式调度、Send/Sync、取消安全和异步诊断。

这张由 ImageGen 生成的系列概念图以铜橙色任务胶囊表现 Future 状态，以环形轨道表现 reactor/waker，以透明闸门表现 Semaphore 与取消边界：任务只有在资源就绪并取得许可后，才进入右侧有限的执行核心。