Posts

背景 缓存能提升性能，但也最容易制造隐性 bug。 线上常见问题： 数据库已更新，缓存还是旧值 热点 key 失效瞬间把数据库打穿 多服务写入同一份数据，更新顺序错乱 在 Go 服务里，缓存一致性通常不是“技术选型”问题，而是“写路径设计”问题。 常见策略 Cache Aside 最常见模型：读先查缓存，未命中再查库并回填；写时先写库，再删缓存。 func (s *UserService) GetUser(ctx context.Context, id int64) (*User, error) { key := fmt.Sprintf("user:%d", id) if val, ok := s.cache.Get(ctx, key); ok { return decodeUser(val) } user, err := s.repo.FindByID(ctx, id) if err != nil { return nil, err } _ = s.cache.Set(ctx, key, encodeUser(user), 5*time.Minute) return user, nil } func (s *UserService) UpdateUser(ctx context.Context, user *User) error { if err := s.repo.Update(ctx, user); err != nil { return err } key := fmt.Sprintf("user:%d", user.ID) _ = s.cache.Delete(ctx, key) return nil } 这个模型简单、可靠，适合大多数业务系统。 双删策略的取舍 有些场景会用“先删缓存，再写库，延迟再删一次”。 它能降低极端并发下的脏读概率，但不是银弹。更关键的还是： 写操作是否集中在一条服务链路 有没有事件通知机制统一刷新 key 的 TTL 是否合理 避免缓存雪崩 两个实用点： TTL 加随机抖动 热点 key 做单飞保护 var g singleflight.Group func (s *UserService) GetUserWithSingleflight(ctx context.Context, id int64) (*User, error) { key := fmt.Sprintf("user:%d", id) v, err, _ := g.Do(key, func() (interface{}, error) { return s.GetUser(ctx, id) }) if err != nil { return nil, err } return v.(*User), nil } 总结 缓存一致性最重要的不是某个技巧，而是明确一致性目标： ...

成本高不一定是机器贵 很多集群成本高，核心原因是资源配置粗放： request 远大于实际使用 HPA 指标失真导致过度扩容 长尾任务长期占用节点 第一件事：拉齐 request 和真实负载 建议先看 7 到 14 天数据，按 P95 使用量设置 request，再保留安全余量。盲目按峰值配置，浪费通常最大。 第二件事：把弹性策略拆开 在线服务：偏稳定，防抖优先 离线任务：可抢占，成本优先 把工作负载分层后，调参会清晰很多。 第三件事：节点池治理 基础池用稳定机型承载核心服务 弹性池接临时流量和批任务 定期清理空转节点 额外收益点 镜像瘦身缩短拉取时间 减少跨可用区流量 对低优先级任务使用 Spot/抢占实例 小结 成本优化不是一次性动作，而是持续运营。先让容量模型可信，再谈更激进的降本策略。

背景 Rust 的 Result 很强，但很多项目还是会遇到同一个问题： 错误被一路 ? 传上去 日志里只有一个模糊报错 出问题时不知道是哪个环节失败 这通常是错误分层没有做好。 一条实用原则 库层定义结构化错误类型 应用层补充上下文并统一输出 use thiserror::Error; #[derive(Debug, Error)] pub enum RepoError { #[error("record not found")] NotFound, #[error("db error: {0}")] Database(String), } use anyhow::{Context, Result}; pub async fn get_user_handler(id: i64, svc: &UserService) -> Result<UserDto> { let user = svc .find_user(id) .await .with_context(|| format!("get user failed, id={id}"))?; Ok(UserDto::from(user)) } 日志里要带可关联字段 只打印错误文本通常不够，至少带上： 请求 ID 用户或租户标识 关键资源 ID tracing::error!( request_id = %request_id, user_id = user_id, error = %err, "failed to get user" ); 总结 Rust 错误处理做得好，排障效率会明显提升。 ...

背景 裸重启进程很简单，但线上会带来短暂不可用。优雅重启的目标是： 停止接收新连接 等待在途请求处理完 平滑切换到新进程 Go 侧的退出处理 srv := &http.Server{Addr: ":8080", Handler: mux} go func() { if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) } }() sigCh := make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT) <-sigCh ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second) defer cancel() _ = srv.Shutdown(ctx) Shutdown 会先关闭监听，再等待连接收尾。 systemd 关键配置 [Service] ExecStart=/opt/app/server Restart=always RestartSec=2 TimeoutStopSec=20 KillSignal=SIGTERM KillSignal=SIGTERM 给应用机会走优雅退出逻辑 TimeoutStopSec 要大于应用 Shutdown 超时 发布建议 先在网关层摘流量 再重启实例 观察错误率与连接数回落 小结 优雅重启不是一个函数调用，而是应用与进程管理器协同设计。把退出路径做好，发布风险会明显下降。

先明确目标 “零拷贝”不是为了炫技，而是为了减少： 内存分配次数 数据复制成本 GC 或 allocator 压力 在高吞吐场景里，收益通常很直接。 借用驱动的数据视图 Rust 的借用模型天然适合做零拷贝读取： #[derive(Debug)] struct Header<'a> { trace_id: &'a str, method: &'a str, } fn parse_header<'a>(trace_id: &'a str, method: &'a str) -> Header<'a> { Header { trace_id, method } } 这里没有分配新字符串，只是借用了输入切片。 适用边界 适合： 协议解析 日志处理 消息中间件消费链路 不适合： 需要长期持有数据跨线程传递 接口边界复杂，生命周期管理成本过高 工程上的折中 热路径零拷贝 冷路径允许复制换可读性 用基准测试验证收益，而不是主观判断 小结 零拷贝是性能工具，不是教条。只有在瓶颈路径上，它才是值得支付复杂度的优化。

编译期类型不是防弹衣 TypeScript 很强，但它无法保证运行时数据一定符合类型。只要数据来自网络、表单、消息队列，就需要校验。 一个常见坑 type User = { id: string; age: number } function handleUser(u: User) { return u.age + 1 } 如果后端把 age 传成字符串，编译不会报错，运行才炸。 用 Zod 建立输入防线 import { z } from "zod" const UserSchema = z.object({ id: z.string().min(1), age: z.number().int().nonnegative(), }) type User = z.infer<typeof UserSchema> function parseUser(input: unknown): User { return UserSchema.parse(input) } 好处是： 校验规则集中管理 报错信息可读 类型与校验规则同步 在 API 层统一拦截 建议在 BFF 或网关层就完成 parse，业务层只接收已验证的数据。这样能显著减少线上脏数据导致的连锁异常。 小结 TS 负责编译期，Zod 负责运行时。两者结合，才能让类型安全真正落地。

痛点 项目初期组件写得很快，半年后常见症状是： props 越加越多 事件命名混乱 业务逻辑散在模板与组件里 要解决这些问题，关键是建立稳定的组件边界。 用 defineProps 和 defineEmits 明确契约 const props = defineProps<{ modelValue: string disabled?: boolean }>() const emit = defineEmits<{ (e: "update:modelValue", val: string): void (e: "submit"): void }>() 契约清楚后，重构成本会明显降低。 分离容器组件与展示组件 容器组件负责数据获取、状态管理 展示组件只关心渲染和交互事件 这能避免“万能组件”不断膨胀。 组合式函数复用逻辑 export function usePagination() { const page = ref(1) const pageSize = ref(20) const setPage = (v: number) => (page.value = v) return { page, pageSize, setPage } } 把重复逻辑提炼到 composable，比 mixin 更直观也更可控。 结语 Vue3 + TS 的上限很高，但前提是组件契约、职责边界、逻辑复用这三件事先做好。代码会更稳，也更容易协作。

慢构建的根因 很多项目 Docker 构建慢，不是机器不够快，而是缓存命中策略有问题： 频繁变动的文件放在前面导致层失效 依赖下载每次重来 多阶段构建没有复用中间层 先调整 Dockerfile 顺序 典型 Node 项目可参考： FROM node:20-alpine AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci FROM node:20-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN npm run build FROM nginx:alpine COPY --from=builder /app/dist /usr/share/nginx/html 先拷贝依赖清单再安装，能最大化命中缓存层。 用 BuildKit 缓存挂载 RUN --mount=type=cache,target=/root/.cache/go-build \ --mount=type=cache,target=/go/pkg/mod \ go build -o app ./cmd/server 这类挂载尤其适合 Go/Rust 的依赖与编译缓存。 CI 中的实践 使用远程缓存导入导出 主分支构建作为缓存热源 避免无意义的 --no-cache 小结 镜像构建优化不是玄学，核心就三点： 层次顺序 缓存挂载 CI 缓存复用 把这三点做好，开发反馈速度会提升一个量级。

常见事故模式 发布时最容易看到这几类问题： Pod 刚启动就被打流量，依赖还没就绪 应用短暂卡顿被 liveness 误杀 Pod 被删时连接直接断开，导致错误尖峰 三类探针分工 startupProbe：启动阶段保护期 readinessProbe：是否可以接收流量 livenessProbe：进程是否需要重启 不要用 liveness 去做复杂业务检查，它更适合检测“进程是否活着”。 终止流程要完整 示例配置： spec: terminationGracePeriodSeconds: 30 containers: - name: api lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 8"] 应用内部还需要做到： 收到 SIGTERM 后停止接收新请求 等待在途请求结束 关闭连接池与后台任务 一个经验值 如果入口网关或 Service Mesh 更新端点需要几秒，preStop 这几秒很关键。它给控制面收敛时间，避免流量打到即将退出的 Pod。 结语 高可用不是靠单个参数，而是探针策略和退出流程共同生效。发布稳定性通常是这些细节堆出来的。

先问一个问题 同样是 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++，缓存友好的数据布局往往比微观语法技巧更值回票价。