马超的代码园

一次压测揪出两个“测试全绿”的性能 bug:KV 引擎压测复盘

Mon, 20 Jul 2026 21:30:00 +0800

最终数据:200k 条 (value=100B) 单线程本机压测 → 写 70.9万 / 随机读 59.1万 / 布隆负查询 321.6万 ops/s 修复前:fillseq 232 ops/s、readrandom 4,936——两个 bug 把所有数字按在地上摩擦口径:22MB 数据全在 page cache,测的是内存命中下的引擎路径效率,不能直接外推生产

KV 引擎做到 Week 4,布隆过滤器和 BlockCache 都上线了,11/11 测试全绿。我跑了一轮 200k 条压测,准备把数字写进简历。

结果 fillseq 跑出来 232 ops/s。

什么概念?平均每次写 4.3ms,p50 2,565μs——这是每次写都 fsync 的价位,而我跑的明明是 sync=0(异步刷盘)。更邪门的是读:readrandom、readmissing 三项全部稳定在 ~190μs/次,布隆过滤器开关与否毫无区别。

测试全绿,性能烂了两个数量级。这篇文章记录我是怎么把这两个 bug 挖出来的——功能正确和性能正确是两件事,前者保不了后者。

网络层设计:主从 Reactor + One Loop Per Thread

Sun, 19 Jul 2026 23:00:00 +0800

代码:src/network/ 8 个核心类,共 ~800 行灵感:陈硕《Linux 多线程服务端编程》+ Muduo 源码 设计目标:0 锁的 IO 路径(每连接绑定一个 EventLoop,无共享)

写 RPC 框架,网络层是最值得"自己写一遍"的部分——HTTP 框架、RPC、消息推送、游戏服务器,网络层都是这套。

我对照陈硕《Linux 多线程服务端编程》自己撸了一遍,没抄 Muduo 源码——边看边写,踩了 6 个坑,全部记下来。

熔断与限流:滑动窗口的两种算法

Sun, 19 Jul 2026 22:55:00 +0800

代码:src/rate_limiter/{token_bucket, redis_token_bucket}.{h,cc} + src/circuit_breaker/{circuit_breaker}.{h,cc} 场景:防止下游服务雪崩,客户端限流 + 熔断 + 服务降级

微服务架构里,保护下游比"打到最快"更重要。三个核心组件:

限流(Rate Limiter):单位时间最多处理 N 个请求
熔断(Circuit Breaker):下游错误率超阈值,临时熔断,不再打下游
负载均衡(Load Balancer):把请求分散到多个实例(轮询/一致性哈希)

这篇文聚焦前两者——把面试常考的"你怎么做限流"答得有深度。

服务发现:内存注册中心 vs etcd 两种实现

Sun, 19 Jul 2026 22:50:00 +0800

代码:src/discovery/memory_registry.{h,cc} (180 行) + src/discovery/etcd_registry.{h,cc} (260 行) 场景:rpc_client 调 EchoService.Echo,注册中心返回所有 EchoService 实例的 host:port

RPC 调用第一步:“EchoService 的实例在哪些机器上?”——这就是服务发现。三种主流实现:

直连——客户端 hardcode host:port,简单但无扩展性
内存注册中心——单进程内 map<服务名, 实例列表>,适合开发/单测
独立服务——etcd / consul / nacos,跨进程共享

我两个都实现了。这篇文记录为什么需要两个、怎么设计、怎么从内存版升级到 etcd。

从零写一个连接池:为什么不用 std::queue

Sun, 19 Jul 2026 22:45:00 +0800

代码:src/pool/connection_pool.{h,cc} (350 行) 场景:rpc_client 每个请求都要 TCP 连接,per-call connect 性能 7,800 QPS,加连接池 28,000 QPS

RPC 客户端最朴素的写法:connect() → send() → recv() → close()。性能 7,800 QPS(p99 4.2ms)。

上连接池,瞬间 28,000 QPS(p99 2.1ms)。3.5x 加速。

听起来就是 std::queue<TcpConnection*> + mutex 的事。真写起来,光"连接怎么回收"就够喝一壶。

docker 部署踩的 9 个坑:从 gcr.io 到健康检查

Sun, 19 Jul 2026 22:40:00 +0800

目标:https://rpc.myxingchen.xyz/api/echo 返回 JSON,延迟 < 10ms 链路:浏览器 → nginx(443) → rpc-proxy(Flask, 8080) → echo-server(C++, 9000) 最终:4.18ms HTTPS / 0.63ms 直连

把 RPC 框架扔上公网,听起来简单——docker build && docker run 完事。我踩了 9 个坑,4 个 deploy 晚上,反复搞。这篇文把每个坑的现象、根因、修法、教训完整记录,下次别再重复。

手写 RPC 协议帧:18 字节头 + CRC32 + protobuf

Sun, 19 Jul 2026 22:35:00 +0800

协议版本:v1.1 完整代码:github.com/FSSLI/rpc_framework - docs/protocol.md

RPC 协议设计,新人最容易踩的坑是:“protobuf 已经有 RPC 语法了,我直接用不就行了?”

可以用,但你失去了:

自定义传输层——gRPC 强绑 HTTP/2,不能上 UDP/QUIC
自定义扩展——trace_id 怎么塞?心跳怎么发?
二进制紧凑度——HTTP/2 头部 + framing 开销在 30-50%

我花了两天设计自己的协议,18 字节头 + 变长 body + 4 字节 CRC。记录下来,顺便说说踩的坑。

48,765 QPS 是怎么压出来的:一个 C++ RPC 框架的压测全流程

Sun, 19 Jul 2026 22:30:00 +0800

数据:8 线程自研 C++ 压测程序同机回环 → 48,765 QPS,p99 382μs(WSL2,4 cores @ 4.0 GHz) 代码:github.com/FSSLI/rpc_framework 协议:18 字节固定头 + 变长 body + CRC32(详见协议设计)

写完 RPC 框架第一版,我面临一个问题:怎么证明这玩意儿不是花架子?

光"我写了一个 RPC"太虚,得拿出数。所以我从第一版压测开始,记录每轮改了哪个文件、为什么这么改,迭代到 48,765 QPS。这篇文把整个过程写下来。