欢迎访问

为什么“打开 O3”还不够 大型 C++ 服务的热点跨模块分散，单文件优化难以奏效。LTO 能打通跨 TU 优化，PGO 能把优化预算聚焦在真实热路径。 推荐流程 基线版本：记录 p50/p99、CPU、指令数、缓存 miss。 LTO 版本：先验证链接时间与二进制体积变化。 PGO 训练：必须使用“接近线上”的请求分布。 组合验证：LTO + PGO 与基线做 A/B。 CMake 关键配置示例 # LTO set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # PGO 两阶段 # 1) -fprofile-generate # 2) -fprofile-use -fprofile-correction 最常见的误区 用单一压测脚本训练 PGO，导致优化偏科。 只看吞吐，不看长尾延迟和抖动。 忽略符号变化对排障工具链（perf、addr2line）的影响。 回归防线 增加“训练集漂移”检测：训练流量和线上流量偏差超阈值就拒绝发布。 将“优化收益”拆解到函数级，防止偶然抖动误判。 为 PGO 单独维护回退开关和构建产物。 小结 LTO/PGO 是生产力工具，不是玄学加速按钮。只有接入真实流量画像和回归防线，优化收益才可持续。

背景 在微服务里，重试是常态；没有幂等，重试就会制造脏数据。 常见重复来源： 客户端重复点击 网关超时后自动重试 消息队列重复投递 一种常见实现 以幂等 key 做唯一约束，先查后写或直接 UPSERT。 type IdempotencyRecord struct { Key string Status string ResultRef string } func (s *OrderService) CreateOrder(ctx context.Context, key string, req *CreateReq) (*Order, error) { if rec, ok := s.repo.FindByKey(ctx, key); ok { return s.repo.FindOrder(ctx, rec.ResultRef) } order, err := s.repo.CreateOrderWithKey(ctx, key, req) if err != nil { return nil, err } return order, nil } 总结 幂等设计本质是在失败重试下维持业务语义稳定。 关键是“唯一键 + 状态机 + 可重放结果”。 高可用系统默认会重试，幂等就是重试的安全带。

背景 同样是自动伸缩，HPA、VPA、KEDA 解决的问题并不一样。 选择思路 请求型 Web 服务：优先 HPA 资源画像长期不准：引入 VPA 做建议或自动调参 事件驱动消费：优先 KEDA 常见组合 HPA + Cluster Autoscaler：最常见 HPA + KEDA：API + 消费任务混合系统 VPA 先建议模式观察，再决定是否自动 总结 不要为“自动化程度更高”盲目上更多组件。 先把指标质量做好，再谈伸缩策略。 伸缩策略的上限，取决于指标体系的下限。

背景 不是所有性能优化都要上自研内存池。很多时候，std::pmr 已经能解决不少问题。 一个实用场景 请求处理阶段会构建很多临时字符串和容器，生命周期一致，适合放在同一块内存资源里。 #include <memory_resource> #include <string> #include <vector> void handleRequest() { std::byte buffer[4096]; std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer)); std::pmr::vector<std::pmr::string> fields{&pool}; fields.emplace_back("user", &pool); fields.emplace_back("email", &pool); } 总结 pmr 的价值在于“低侵入地控制分配策略”。 在临时对象密集场景里，收益通常比预想更明显。 能用标准库解决的问题，优先别把复杂度推到自研。

背景 很多部署问题，其实在本地就埋下了： 本地依赖版本和线上不同 环境变量缺省值不一致 本地绕过了鉴权或网络策略 一个简单做法 用 Compose profile 区分场景，但保持核心依赖一致。 services: app: build: . env_file: .env depends_on: [db, redis] db: image: postgres:16 redis: image: redis:7 总结 环境一致性不是“完全一样”，而是“关键契约一致”。 只要契约一致，很多线上问题能在开发期提前暴露。 部署质量往往从本地开发流程就开始决定了。

先澄清核心矛盾 无锁链表里，线程 A 可能刚把节点从链表摘下，线程 B 还在读取它。此时直接 drop 会造成悬垂引用。 两类主流方案 Epoch Based Reclamation（EBR） 线程进入临界区时 pin 当前 epoch。 删除节点先放入 retired 列表。 只有当所有线程都跨过该 epoch，节点才可释放。 Hazard Pointer（HP） 读取前先声明“我正在看这个指针”。 回收线程扫描所有 hazard slot。 未被保护的 retired 节点才能释放。 EBR 的工程特性 吞吐通常更高，读路径开销小。 线程暂停会拖慢全局回收进度。 更适合短临界区、线程活跃的服务。 HP 的工程特性 回收更精细，不容易被慢线程拖住。 读路径需要发布 hazard，CPU 开销更高。 更适合线程生命周期不可控的系统。 Rust 落地建议 // 伪代码：删除节点不立即释放，而是 retire fn remove(node: Shared<Node>, guard: &Guard) { if cas_unlink(node, guard) { guard.defer_destroy(node); // 交给回收器延迟释放 } } 使用经过验证的库（如 crossbeam）而不是手搓回收器。 把“最大 retired 数量”做成指标，防止隐性内存膨胀。 压测时加入 SIGSTOP 慢线程场景，验证回收鲁棒性。 小结 锁不一定是瓶颈，错误回收一定是灾难。无锁结构上线前，先证明回收策略在“慢线程、抖动、长尾”下仍可控。

背景 很多 Go 服务都会做 worker pool，但只做“固定 worker 数量”还不够。 真正决定稳定性的，是池子打满后怎么办。 基础模型 type Job func(context.Context) error type Pool struct { jobs chan Job } func NewPool(workerN, queueN int) *Pool { p := &Pool{jobs: make(chan Job, queueN)} for i := 0; i < workerN; i++ { go func() { for job := range p.jobs { _ = job(context.Background()) } }() } return p } 关键点：拒绝策略 func (p *Pool) TrySubmit(job Job) error { select { case p.jobs <- job: return nil default: return errors.New("worker pool saturated") } } 当队列已满时，快速失败通常比无限排队更可控。 总结 worker pool 的目标不是“永不拒绝”，而是让系统在高峰时有可预测行为。 配合监控和限流，才能构成完整保护链路。 可用系统的关键是边界清晰，而不是无限扛压。

问题画像 线上最危险的不是“改表”，而是“业务和改表耦合发布”：应用已读新字段，但 DDL 还没完成；或者 DDL 成功了，回滚却读不懂新结构。 迁移模型：Expand -> Migrate -> Contract Expand：只做向后兼容变更（加列、加索引、双写入口）。 Migrate：后台回填与数据校验，逐步把读流量切向新字段。 Contract：确认没有旧路径后，再删旧列/旧索引。 Go 侧发布顺序 // 第一步发布：双写 + 旧读优先 func SaveOrder(ctx context.Context, o Order) error { row := model.OrderRow{ ID: o.ID, // old_total 保持兼容 OldTotal: o.Total, // new_total 为新字段 NewTotal: decimalPtr(o.Total), } return repo.Upsert(ctx, row) } // 第二步发布：读新字段，失败回退旧字段 func LoadOrderTotal(r model.OrderRow) decimal.Decimal { if r.NewTotal != nil { return *r.NewTotal } return r.OldTotal } 回填策略 按主键区间分页，避免大事务长时间占锁。 每批记录校验 checksum，把异常写入死信表。 回填作业限速，和在线业务共享数据库 QPS 预算。 观测与止损 指标：回填进度、回填错误率、慢 SQL、锁等待时间。 开关：双写开关、读路径开关、回填暂停开关。 预案：任意阶段都能回到“旧读+旧写”。 常见坑 在 Expand 阶段做非兼容 DDL（例如直接改列类型）。 回填任务不幂等，重跑会污染数据。 只关注“DDL 成功”，忽略“业务一致性成功”。 小结 零停机迁移不是一条 SQL，而是一条发布流水线。把数据库变更当成可灰度、可观测、可回滚的工程流程，风险会从“不可控事故”变成“可管理演进”。

背景 Axum 用起来很顺手，但真实项目里经常出现一个隐性问题： 中间件越加越多 顺序靠经验调整 出故障时不知道是哪个层拦住了请求 推荐分层 从外到内通常建议： request id / tracing panic recover 全局限流 认证鉴权 业务路由 let app = Router::new() .route("/api/user", get(get_user)) .layer(TraceLayer::new_for_http()) .layer(RequestIdLayer::new()) .layer(TimeoutLayer::new(Duration::from_secs(2))); 总结 中间件不是“越多越安全”，而是“每层职责清晰、顺序可解释”。 发布前做一次链路压测，往往能提前发现大部分分层问题。 架构清晰的系统，异常路径也应该清晰。

背景 很多集群的问题，最后都落在资源配置上： requests 太高，调度不进去 requests 太低，服务被抢占导致抖动 limits 太严，CPU 被频繁 throttling 基本策略 先测业务基线，再填 requests CPU limits 结合业务特性决定是否设置 内存 limits 必须有，否则容易把节点拖垮 resources: requests: cpu: "300m" memory: "512Mi" limits: cpu: "1000m" memory: "1Gi" 观测指标 建议持续看： container_cpu_cfs_throttled_seconds_total container_memory_working_set_bytes Pod OOMKilled 次数 总结 资源参数不是一次性配置，而是持续调优过程。 用监控数据驱动参数调整，比凭经验拍数值更靠谱。 资源治理本质是容量治理，最终影响的是可用性和成本。