欢迎访问

先问一个问题 同样是 O(n)，为什么有的循环快很多？ 答案常常不在算法复杂度，而在 CPU cache 命中率。现代 CPU 的瓶颈常常是内存访问，不是算术指令。 AoS 与 SoA 常见结构： struct Particle { float x, y, z; float vx, vy, vz; int alive; }; std::vector<Particle> particles; 如果你只更新位置，实际上每次还会把速度和状态也加载进缓存。更好的方式是 SoA： struct Particles { std::vector<float> x, y, z; std::vector<float> vx, vy, vz; std::vector<int> alive; }; 这样 CPU 读取的数据更“纯”，预取更有效。 减少伪共享 多线程里，两个线程写不同变量也可能互相拖慢，因为它们落在同一 cache line。 struct alignas(64) Counter { std::atomic<uint64_t> value; }; 用对齐把热点写入隔离开，通常能明显降低抖动。 少做指针追逐 链表、树这类结构在理论上优雅，但在缓存层面很吃亏。工程上更常见的折中是： 用连续数组表示节点池 索引代替裸指针 批量遍历而不是随机跳转 实践建议 先用 profiler 看 cache miss，再改代码 热路径优先考虑连续内存 把“数据怎么放”当成接口设计的一部分 小结 性能优化不是玄学。对于 C++，缓存友好的数据布局往往比微观语法技巧更值回票价。

为什么会积压 很多服务写了 worker pool，但上线后仍然： 高峰时队列暴涨 平均延迟还行，P99 很差 CPU 没打满却开始超时 这通常是“入队速率 > 出队速率”的背压问题。 基础模型 type Job struct { ID string } func startPool(ctx context.Context, n int, jobs <-chan Job) { for i := 0; i < n; i++ { go func() { for { select { case <-ctx.Done(): return case job, ok := <-jobs: if !ok { return } handle(job) } } }() } } 结构不复杂，难点在参数选择。 三个观测指标 吞吐：每秒处理多少请求 延迟：P50/P95/P99 队列深度：channel 长度趋势 如果队列长期接近上限，说明处理能力不足或外部依赖抖动。 调优顺序 固定业务流量，先找单 worker 处理能力 逐步增加 worker，观察 P99 与 CPU 变化 达到拐点后停止扩容，避免锁竞争和上下文切换过量 设置拒绝策略，不让队列无限增长 一个实用策略 快速失败：队列满时直接返回可重试错误 分级队列：高优先级任务单独通道 限时执行：每个任务绑定 context 超时 总结 worker pool 不是“越大越好”。并发数本质是资源预算，必须和外部依赖能力、延迟目标一起设计。

为什么这个问题总会出现 线上服务一旦有重试、聚合查询、异步回调，就很容易出现 goroutine 泄漏： 上游请求已经结束，下游协程还在跑 超时只控制了入口，没有传到内部依赖 背景任务没有退出信号 context.Context 不是万能药，但它是 Go 服务里最基础的生命周期约束。 三条硬规则 请求入口创建 context，内部只传递不重建 外部依赖调用必须接收 context 子协程要么监听 ctx.Done()，要么有明确退出条件 一个最小可用结构 func handler(w http.ResponseWriter, r *http.Request) { ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond) defer cancel() user, err := userSvc.Get(ctx, "u-1001") if err != nil { http.Error(w, err.Error(), http.StatusGatewayTimeout) return } _ = json.NewEncoder(w).Encode(user) } 关键点在于：超时预算从入口建立，并传给每一层。 扇出场景的取消联动 func aggregate(ctx context.Context, id string) (Profile, error) { g, ctx := errgroup.WithContext(ctx) var base BaseInfo var score CreditScore g.Go(func() error { v, err := queryBase(ctx, id) if err != nil { return err } base = v return nil }) g.Go(func() error { v, err := queryScore(ctx, id) if err != nil { return err } score = v return nil }) if err := g.Wait(); err != nil { return Profile{}, err } return Profile{Base: base, Score: score}, nil } errgroup.WithContext 的价值是：任一分支失败，其他分支自动收到取消信号。 ...

场景 很多团队不是从零重写，而是把热点模块逐步迁到 Rust。最现实的路径是： C++ 主程序继续跑 Rust 提供一个动态库 双方通过 C ABI 通信 核心原则很简单：跨语言只传 C 兼容类型。 先定义稳定接口 #[repr(C)] pub struct CalcResult { pub code: i32, pub value: i64, } #[no_mangle] pub extern "C" fn calc_sum(a: i64, b: i64) -> CalcResult { CalcResult { code: 0, value: a + b } } #[repr(C)] 保证结构体布局可预测 extern "C" 保证调用约定一致 #[no_mangle] 让符号名可被 C++ 链接 字符串内存谁分配谁释放 跨边界最容易出问题的是字符串： Rust 分配、C++ 释放，或者反过来 不同分配器混用导致崩溃 推荐做法：统一由一侧分配和释放，并显式提供 free 函数。 错误处理不要 panic 穿透 FFI 层应该“防炸”： #[no_mangle] pub extern "C" fn safe_div(a: i64, b: i64, out: *mut i64) -> i32 { if out.is_null() { return -2; } if b == 0 { return -1; } unsafe { *out = a / b; } 0 } 返回错误码是最朴素、也最稳的方式。 ...

背景 写 C++ 服务或者引擎代码时，经常会碰到一种情况：CPU 看着不高，但延迟就是压不下去。 最后一 profile，热点不在算法，也不在锁，而是在 operator new 和 operator delete。 这类问题在下面几种场景里尤其常见： 网络服务里大量创建短生命周期请求对象 游戏引擎里频繁分配小型组件 消息队列消费者持续构造临时 buffer 如果对象大小固定，或者分布相对集中，内存池通常是很直接的一刀。 为什么默认分配器会成为瓶颈 通用分配器要解决的问题很多： 不同尺寸的内存申请 跨线程竞争 碎片整理 对齐要求 这些能力都很重要，但它们也意味着额外开销。 如果你的场景很单一，比如“每次都申请一个 256 字节的请求对象”，那继续走通用分配器其实是在为用不到的能力买单。 一个简单的固定块内存池 先看一个足够说明问题的版本。 #include <cstddef> #include <new> #include <vector> class MemoryPool { public: MemoryPool(std::size_t blockSize, std::size_t blockCount) : block_size_(blockSize) { data_.resize(blockSize * blockCount); for (std::size_t i = 0; i < blockCount; ++i) { void* ptr = data_.data() + i * blockSize; free_list_.push_back(ptr); } } void* allocate() { if (free_list_.empty()) { throw std::bad_alloc(); } void* ptr = free_list_.back(); free_list_.pop_back(); return ptr; } void deallocate(void* ptr) { free_list_.push_back(ptr); } private: std::size_t block_size_; std::vector<char> data_; std::vector<void*> free_list_; }; 思路很直接： ...

背景 只要做过高并发服务、游戏引擎或者低延迟组件，迟早会碰到一个问题：锁太重了。 典型场景包括： 生产者线程持续推消息 消费者线程高频拉取任务 临界区很短，但锁竞争很激烈 延迟指标对尾部抖动非常敏感 这时候很多人第一反应是“上无锁队列”。 方向没错，但无锁代码最危险的地方在于：看起来能跑，不代表一定正确。 尤其在 C++ 里，只会用 compare_exchange_weak 还不够，真正决定正确性的往往是内存序。 无锁不等于没有同步 先澄清一个常见误区： mutex 是同步 原子变量也是同步 无锁结构只是把同步方式从“阻塞锁”换成了“原子操作 + 内存可见性约束”。 也就是说，你不是不需要同步了，而是需要更精确地控制同步。 一个最简单的 SPSC 环形队列 先从单生产者、单消费者模型说起。这个模型更适合作为理解内存序的起点。 #include <atomic> #include <array> #include <cstddef> template <typename T, std::size_t N> class SpscQueue { public: bool push(const T& value) { const auto tail = tail_.load(std::memory_order_relaxed); const auto next = (tail + 1) % N; if (next == head_.load(std::memory_order_acquire)) { return false; } buffer_[tail] = value; tail_.store(next, std::memory_order_release); return true; } bool pop(T& value) { const auto head = head_.load(std::memory_order_relaxed); if (head == tail_.load(std::memory_order_acquire)) { return false; } value = buffer_[head]; head_.store((head + 1) % N, std::memory_order_release); return true; } private: std::array<T, N> buffer_{}; std::atomic<std::size_t> head_{0}; std::atomic<std::size_t> tail_{0}; }; 这个实现不复杂，但已经体现了两个关键点： ...

背景 上一篇聊了 Docker 多阶段构建，重点是镜像体积和构建效率。 但把镜像做小，只解决了一半问题。真正要上线时，还得继续问几个更现实的问题： 镜像里有没有不该带进去的工具 容器是不是还在用 root 运行 依赖包有没有已知漏洞 基础镜像是不是长期没人维护 很多项目的 Dockerfile 确实“能跑”，但离“适合上线”还差不少。 小镜像通常也更安全 这不是绝对规律，但大体成立。 原因很简单： 装得越多，攻击面越大 多余工具越多，漏洞概率越高 调试方便的环境，往往也更容易被滥用 所以镜像瘦身和安全加固，在很多时候是同一个方向上的事情。 不要默认用 root 运行 很多 Dockerfile 最容易忽略的一点，就是进程默认是 root。 FROM alpine:3.20 WORKDIR /app COPY myapp /app/myapp ENTRYPOINT ["/app/myapp"] 这份文件能跑，但容器里的进程权限过大。 更稳妥的方式是显式创建低权限用户： FROM alpine:3.20 RUN addgroup -S appgroup && adduser -S appuser -G appgroup WORKDIR /app COPY myapp /app/myapp USER appuser ENTRYPOINT ["/app/myapp"] 这样即使应用被利用，攻击者拿到的默认权限也会更低。 基础镜像要尽量克制 基础镜像选型很影响最终的安全边界。 常见选择大概是： ubuntu / debian：通用，但内容更多 alpine：体积小，适合简单运行时 distroless：更克制，适合生产环境 scratch：最小，但调试和兼容性要求更高 如果你的程序是静态编译的 Go 服务，通常可以考虑 scratch 或 distroless。 ...

背景 很多团队从 REST 切到 gRPC 后，第一感受通常都不错： 接口定义清晰 代码生成省心 性能和序列化效率更好 但线上跑久了会发现，真正决定服务质量的不是 protobuf 文件写得多漂亮，而是这些问题处理得怎么样： 超时怎么设 失败要不要重试 下游抖动时怎么自保 连接和并发要怎么控 这些内容不处理好，gRPC 只是让调用更快地失败而已。 超时必须从调用入口就带上 Go 里最好的习惯之一，就是把超时放进 context.Context。 func (s *OrderService) GetUser(ctx context.Context, userID string) (*pb.User, error) { callCtx, cancel := context.WithTimeout(ctx, 300*time.Millisecond) defer cancel() return s.userClient.GetUser(callCtx, &pb.GetUserRequest{ UserId: userID, }) } 为什么一定要带超时？ 因为不带超时的 RPC，本质上就是把失败时间交给网络、内核和对端服务决定。你无法控制，也无法稳定预期。 线上更糟的是，请求可能层层调用： API -> Order Service -> User Service -> Profile Service 如果每一层都没有明确 deadline，慢请求会像雪球一样越滚越大。 重试不是默认开启就完事 很多人一看到失败就想自动重试，但重试最危险的地方在于：如果失败原因是过载，重试可能会让故障更严重。 适合重试的场景通常是： 短暂网络抖动 连接瞬时中断 明显的临时性错误 不适合盲目重试的场景： 已经超时很久的请求 非幂等写操作 下游明显处于过载状态 一个更稳的客户端封装通常像这样： func callWithRetry(ctx context.Context, fn func(context.Context) error) error { var lastErr error backoffs := []time.Duration{50 * time.Millisecond, 100 * time.Millisecond, 200 * time.Millisecond} for _, backoff := range backoffs { if err := fn(ctx); err == nil { return nil } else { lastErr = err } select { case <-time.After(backoff): case <-ctx.Done(): return ctx.Err() } } return lastErr } 这里最重要的不是代码本身，而是策略： ...

背景 很多团队的监控体系，起点都差不多： 接了 Prometheus 做了几个 Grafana 大盘 报警规则也写了一堆 结果线上一出问题，还是有两个老问题： 真故障没及时报 不重要的抖动疯狂报 本质原因通常不是“监控没接”，而是指标设计和告警语义不对。 尤其在 Go 微服务里，写 metrics 很容易，写出真正有业务意义的 metrics 并不容易。 先区分：监控数据不等于告警指标 你当然可以采很多数据，但不是所有数据都适合直接拿来告警。 比如这些指标： goroutine 数量 GC 次数 进程 RSS 请求总量 它们都很有价值，但更适合作为排障上下文，而不是一上来就触发 Pager。 真正适合做核心告警的，通常是离用户体验更近的信号。 这就是 SLI / SLO 的意义。 什么是 SLI / SLO 简单说： SLI：你用什么指标衡量服务质量 SLO：这个质量要达到什么目标 以一个 HTTP API 为例，最常见的两个 SLI 是： 可用性 成功请求比例是不是足够高。 延迟 请求耗时是不是在可接受范围内。 例如： 30 天内成功率不低于 99.9% 95% 的请求延迟低于 200ms 这两个目标就比“CPU 超过 80% 告警”更接近真实业务体验。 Go 服务里的基础指标 假设你已经有一个标准 HTTP 中间件，可以记录请求总量和耗时。 ...

背景 很多团队第一次把服务上到 Kubernetes 时，会觉得滚动发布已经帮我们解决了“不中断发布”的问题。 实际上，RollingUpdate 只是开始，不是答案。 线上真正导致发布抖动的，往往是这些细节： 新 Pod 还没准备好就被加进流量 老 Pod 收到 SIGTERM 后立刻退出 长连接请求被中途切断 readiness 和 liveness 配置混乱 ingress、service、应用本身三层状态不同步 想做到真正意义上的零中断，得把整条链路串起来看。 先理解滚动发布到底做了什么 Deployment 默认使用 RollingUpdate 策略，大致过程是： 拉起新 Pod 等新 Pod Ready 逐步减少旧 Pod 直到新版本全部替换完成 一个常见配置如下： strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 这表示： 发布期间不允许可用实例减少 每次最多多起一个新 Pod 它能降低抖动概率，但不能保证应用层面的请求一定不受影响。 Readiness Probe 决定流量什么时候进来 如果只配了 liveness，没有配 readiness，基本等于告诉集群： “只要进程还活着，就可以接流量。” 这在很多服务里是错的。 比如一个 API 服务启动后还要做这些事情： 加载配置 预热缓存 建立数据库连接池 初始化路由和依赖客户端 在这些动作完成之前，进程虽然活着，但根本不适合接请求。 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 3 periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 10 这两个探针不要混用： ...