https://junozee.com/posts/Recent content in 文章 on 工程师手记Hugozh-CNMon, 31 Aug 2026 09:00:00 +0800https://junozee.com/posts/ai-era-engineering-notes/Mon, 31 Aug 2026 09:00:00 +0800https://junozee.com/posts/ai-era-engineering-notes/<p>基础概念、框架入门和 API 参数说明，正在快速变成随问随答的能力。把官方文档换一种说法，已经很难成为有价值的内容。</p> <p>但工程实践里真正昂贵的部分，从来不是记住一个 API，而是判断：<strong>在当前规模、团队能力和历史包袱下，哪一种方案的长期成本最低。</strong></p> <p>AI 能给出方案列表，却不知道你的数据库有十年的数据债、核心链路不能停机，也无法替你承担一次错误架构决策的后果。这些现实约束，正是一名资深工程师可以持续记录的内容。</p> <p>我希望这里留下的不是“标准答案”，而是可供复盘的判断过程：当时有哪些选择、为什么排除、上线后的结果是什么，以及下次会如何改进。</p>https://junozee.com/posts/thread-pool-is-a-design/Mon, 24 Aug 2026 10:30:00 +0800https://junozee.com/posts/thread-pool-is-a-design/<p>“CPU 密集型任务设为 CPU 核数加一，I/O 密集型任务设为 CPU 核数乘二”是一个不错的起点，却不是生产配置的终点。</p> <p>线程池真正需要回答三个问题：</p> <ol> <li>任务阻塞时，谁会先被拖垮？</li> <li>高峰来临时，应该排队、快速失败，还是降级？</li> <li>下游服务能承受多大的并发？</li> </ol> <p>一个为搜索构建的线程池和一个为支付回调构建的线程池，拒绝策略往往应该完全不同。前者可以快速失败并返回兜底结果，后者则更需要保序、重试和可追踪的补偿机制。</p> <p>因此，参数配置应该从业务的失败语义开始，再结合监控数据持续调整。公式负责给出初值，工程设计才决定最终值。</p>https://junozee.com/posts/cache-consistency-tradeoffs/Wed, 12 Aug 2026 15:00:00 +0800https://junozee.com/posts/cache-consistency-tradeoffs/<p>缓存一致性不是二元命题。对大多数业务来说，重要的不是“绝对一致”，而是明确：<strong>哪一类数据可以旧多久，哪一类操作绝不能错。</strong></p> <p>商品详情允许数秒的价格展示延迟，库存扣减通常不能接受；报表看板可以异步刷新，支付状态必须有可追溯的最终结果。把这些边界说清楚，才有资格讨论 Cache Aside、延迟双删、消息驱动或版本号校验。</p> <p>设计缓存时，我会先写下三条约束：</p> <ul> <li>不一致的可见范围与最长时间；</li> <li>缓存失效或穿透时的服务降级策略；</li> <li>写入失败时的补偿、告警与人工介入方式。</li> </ul> <p>技术方案只是实现手段。先定义业务可承受的风险，缓存设计才会变得简单。</p>