HespethornのBlog

5.25.7 一直在优化"哪些读可以不打 MySQL"。但仔细想想，Redis 命中本身也有成本：一次网络往返 0.20.5ms。洪峰期所有用户刷同一批热 key，这个往返是纯开销——数据明明就在本进程里能算出来，为什么每次都要绕一圈网络？这一篇落地多级缓存：进程内加一层自实现的 LRU 做 L1，读路径变成 L1 本地内存 → L2 Redis → L3 MySQL。同时回答两个最尖锐的问题：L1 的一致性怎么保？L1 到底对什么样的流量有效？ 配套代码 src/service/LocalLruCache.h（自实现）+ scripts/local-bench.sh（对比压测）在 5.8 已落地。 本文是「秒杀系统（C++ / Drogon）」系列第五章第八篇（阶段二收尾）。配套代码：src/service/LocalLruCache.h、SkuCache 内嵌 L1（读 L1→L2→L3，写/失效同步本地）、config cache.local_enabled / local_capacity。代码对应阶段二 v0.2.x。 一、为...

局部性原理——从哪来、为什么、有什么用 面试官问：为什么 Redis 查一次很快，而同样的数据放远程 MySQL 上要慢几十倍？为什么数组遍历比链表快，明明两者都是"一个接一个读"？为什么 CPU 造了三级缓存，却无论如何不肯做大一点？—— 答案都指向同一条规律：局部性原理。 0. 钩子：一个几乎不可能的缓存假设没有局部性原理，会发生一件很滑稽的事：CPU 花了几百亿造的 L1 Cache 几乎没有命中，命中率趋近于 0，缓存白装。为什么？因为缓存能起作用，靠的是"你读写过的数据，大概率很快还会再读写"——如果每次访问都落在完完全全随机的新位置，那缓存里存的旧东西永远派不上用场，装缓存等于没装。可现实是，几乎所有真实程序都有强局部性，所以缓存这条产业链才成立。局部性不是假设出来的，它是真实工作负载的结构性特征，缓存只是顺着这个特征搭的脚手架。 1. 它从哪来：Peter Denning 与工作集模型1965 到 1968 年，虚拟内存（分页）刚铺开不久，系统遇到一个棘手问题：程序一多、内存一紧张，页面就在内存和磁盘之间疯狂换入换出，系统陷...

一、临渊镇的刀，总在最后一关栽跟头临渊镇傍着一道深涧而建，以打宝刀出名。镇上刀铺接了单子，从选铁、折叠、淬火到开刃，前几道都由师傅亲手把关。可刀成不成器，最后一道"评刀"却不由师傅定——镇上有个老规矩：每把新刀要过"判官"这一关，判官说合格，方能入鞘出售；判官说不合格，整把回炉。 长久以来，这差事落在一个姓陶的老判官身上。陶公看刀看了三十年，眼力原本极好，可临渊镇的人渐渐发现一件怪事：同一批料、同一位师傅打的刀，陶公今日判合格的，隔日另一把竟在客人手里生生折断；而他昨日毙掉的那把"次刀"，后来被人偷偷留下，竟用了十年未卷刃。 "陶公也有走眼的时候？"镇民嘀咕。陶公自己也想不通——他看刀的法子从没变过，怎么时灵时不灵。 二、一个爱抬杠的客人，点破了症结这年秋天，城里来了个收刀的客商，姓裴。裴商人在各家刀铺挑了三十把刀，一一请陶公评过，自己却偷偷另请三位老匠暗中复验。半月后他找上门，把一本账册拍在陶公案上。 "陶兄，你这三十把里，判错了九把。"裴商人笑道，"不是你眼力差，是每...

今日摘要："上下文工程"取代 Prompt 工程成为编程智能体新显学，同一模型仅因上下文编排差异成功率可差 20~40 个百分点；代码智能体进入"平行宇宙"测试，多沙箱并行验证修复方案；机器人基础模型走向视觉-语言-动作一体预训练的统一架构；人形机器人"租赁即服务"（RaaS）商业模式开始跑通；开源代码模型在 SWE-bench 类基准上集体追平闭源。以下是详细内容。 一、主线1. 「上下文工程」取代 Prompt 工程，成为编程智能体的新显学随着 100 万1000 万 token 的上下文窗口成为主流，社区共识正在从"怎么写一句好 prompt"转向"怎么把检索、记忆、工具调用结果组织成一段好的上下文"。新一批评测显示：同一模型、同一任务，仅因上下文里"先放需求还是先放报错""是否带历史成功补丁""工具输出是否裁剪"，成功率能差出 2040 个百分点。 值得关注：这标志着 AI 编程的竞争焦点从"模型能...

10000 个人抢 100 件商品，最后卖出去 137 件——这句"段子"我们在表设计那篇就破了。但秒杀真正的第一道门，不是库存，是身份：你是谁？你有没有资格抢？如果你连"注册"这一步都把明文密码写进库，那后面无论 Redis 预扣、Lua 原子、MQ 削峰做得再漂亮，用户表一旦泄露就是全裸——所有"高并发安全"都建立在沙滩上。 本文是「秒杀系统（C++ / Drogon）」系列第三章（登录模块）的开篇。配套仓库 seckill-cpp。当前阶段一 v0.1.x 已落地登录 / 短信模块，目录为 sql/user_schema.sql、src/service/UserService.{h,cc}、src/controllers/UserController.{h,cc}、src/service/password.{h,cc}、src/service/Jwt.{h,cc}、src/service/SessionStore....

验证码改成自签发 / 日志模式后（3.3），"送达"不再是外部约束——注册接口等于裸奔在公网：攻击者拿一堆手机号从同一个 IP 批量注册，就能刷出成千上万个账号。这篇补两道闸门：① 同 IP 注册频控堵批量刷号；② 反代真实客户端 IP 解析，否则频控的 key 拿到的是代理 IP，等于没防。 配套代码：src/service/RegisterGuard.{h,cc}（check / markSuccess + kCheckScript / kMarkScript）、src/controllers/UserController.cc 的 clientIp()、UserService::registerUser 最前的频控闸门。阈值走 config.json 的 register_limit（max_per_ip=5 / window_seconds=3600）。 ⚑ 2026-09-17 勘误（重要）本文初版主张「取 X-Forwarded-For 首段即最原始客户端」，这个结论是错的。XFF ...

注册接口建好了"身份"，这一篇让身份"进门"——登录接口。它要做三件事：比对密码、签发 JWT、把会话写进 Redis。前两件是安全，第三件是"可吊销"——没有它，JWT 一旦签发就只能在 exp 到点后自己失效，改密码/封号都拦不住旧 Token，等于门没锁。 配套代码：src/service/UserService.cc（login）、src/service/Jwt.{h,cc}、src/service/SessionStore.{h,cc}、src/controllers/UserController.cc（login）。延续 3.1 的"服务层只做业务、控制器只做协议转换"分层。 一、登录接口：是什么、坑在哪、本质一句话是什么：登录 = 用"手机号 + 密码"证明你是你，成功后发一个不可伪造的凭证（JWT），并在 Redis 留下一条可吊销的会话记录，让服务端随时能把这把钥匙作废。 坑在哪： 密码明文比对的时...

注册/登录要不要验证码？要——但验证码接口本身就是个高价值攻击面：它既能当"免费短信轰炸机"打别人的手机，又能被脚本爆破出 6 位验证码。这一篇把验证码接口做完整：生成（CSPRNG）→ 限流（冷却 + 每日上限）→ 存储（Redis）→ 发送（腾讯云直连），每一道都对应一个具体的攻击面。 配套代码：src/service/SmsService.{h,cc}（生成/限流/存储/校验）、src/service/SmsSender.{h,cc}（腾讯云直连）、src/controllers/SmsController.cc、src/service/SmsSender.cc 的 TC3 签名。 一、短信验证码接口：是什么、坑在哪、本质一句话是什么：POST /api/sms/send 给指定手机号生成 6 位验证码，限流后存入 Redis（有效期 + 重发冷却 + 每日上限），再通过腾讯云短信 API 发出去。校验在注册（3.1）/登录（3.2）流程里调 verifyCod...

3.1 把注册流程的"验证码分支"留了空（先查重再哈希再落库，requireSmsOnRegister=true 时走 sms_->verifyCode）；3.2 把"登录成功写 Redis 会话"说了。这一篇把这两件事的接缝焊死：验证码怎么校验、Token 怎么持久化、退出怎么吊销，以及它们背后的 key 约定与配置开关。 配套代码：src/service/UserService.cc（registerUser 的 verifyCode 分支、login 的 sessions_->save、logout 的 sessions_->revoke）、src/service/SessionStore.{h,cc}、配置项 requireSmsOnRegister / requireSmsOnLogin。 一、本篇在链路里的位置：是什么、坑在哪、本质一句话是什么：把"验证码校验"接到注册/登录流程里（挡脚本批量注册），把"登录签发的 JWT"的 ...

3.3 把短信接口的流程跑通了（生成→限流→存储→发送）。这一篇专门挖安全加固这一层：为什么限流和校验必须写成 Lua、每日上限的 key 为什么要计算"距次日 0 点"的 TTL、6 位验证码在数学上意味着什么、以及"发送失败不回滚配额"这个有意的取舍。 配套代码：src/service/SmsService.cc 的 kSendScript / kVerifyScript / secondsUntilTomorrow / genNumericCode。 一、为什么需要加固：三个攻击面 攻击面 后果 加固手段 短信轰炸 拿接口打别人手机，败坏口碑 + 账单是你的 重发冷却 + 每日上限（都在 kSendScript） 验证码爆破 6 位仅 1M 组合，脚本几十分钟撞出 校验次数上限（kVerifyScript 的 maxVerifyAttempts） 一码多用 并发下同一码被兑换两次 校验与消费同一 Lua 原子完成 二、发送侧 Lua：冷却 + 每日上限原子化kSendScript...

登录接口（3.2）能比对密码了，但还差最后一道防线的"门闩"：密码错误次数限制 + 账号临时锁定。没有它，攻击者可以对一个手机号无限次试密码（撞库）；有了它，连续错 N 次就临时锁几分钟，把撞库成本抬高到不划算。 配套代码：src/service/LoginGuard.{h,cc}（checkLocked / onFailure / onSuccess + kOnFailureScript / kCheckScript）、UserService::login 里埋的 guard_-> 调用。 一、是什么、坑在哪、本质一句话是什么：LoginGuard 用 Redis 记录每个手机号的密码失败次数，连续失败达 max_fail（默认 5）就 SETEX login:lock:{phone} 锁定 lock_seconds（默认 600）；登录成功清计数；登录前先查锁定。 坑在哪： 计数放进程内存：多实例部署时每台各记各的，"5 次就锁"变成"5×N 次...

3.2 把"登录签发 + 写 Redis 会话"讲完，3.4 把"退出即吊销"预览了一句。这一篇把退出登录做成完整接口：POST /api/user/logout，从 Authorization: Bearer 取 Token、验签、删 sess:{jti}——删掉那一刻，旧 Token 立即失效。 配套代码：src/controllers/UserController.cc（logout + extractBearerToken）、src/service/UserService.cc（logout / authenticate）、src/service/SessionStore.cc（revoke）。 一、是什么、坑在哪、本质一句话是什么：退出登录 = 客户端带上 Token，服务端验签通过后删除 Redis 里的 sess:{jti}。JWT 本身无法被"改"，但此后每次鉴权都会因 EXISTS sess:{jti} 失败而被拒。 坑...

阶段一的代码越写越多，SeckillController / UserController / SmsController 每个 handler 都在手写 newHttpJsonResponse + setStatusCode 的样板，而且"什么业务码配什么 HTTP 状态"各写各的，容易不一致。这一篇做一件小但重要的重构：把统一 JSON 响应抽成 seckill::http 命名空间（src/util/HttpJson.h），所有控制器复用。顺带把重构中踩到的两个 Drogon 1.9.10 编译坑一并记下。 配套代码：src/util/HttpJson.h、src/controllers/SeckillController.cc（三处 handler 改用 reply / replyData）。 一、为什么要重构：重复样板 + 状态码不一致重构前，每个 handler 都是这套： 123456// 重构前：每个 handler 重复且易错Json::Value root; root["code"] =...

⚠️ 本文是设计篇，不落地代码。 滑块验证码的完整实现（前端滑块 + 后端校验）推迟到「开始有前端」阶段再做。本篇只把后端必须自写的部分设计清楚、把契约定下来，避免到时候返工。原因见第六节「为什么代码推迟」。 3.3~3.5 做的是短信验证码（防脚本批量注册）。短信验证码有个软肋：它是"知识因子"——6 位数字，真能拦住人肉，但拦不住"养一批号 + 接码平台"的专业黄牛。滑块验证码补的是另一层：行为因子——你拖动滑块的轨迹，机器人很难逼真模仿。这一篇讲它的设计。 一、为什么是滑块：人机区分的本质短信验证码回答"你有没有这个手机号"，滑块回答"你是不是真人在操作"。两者维度不同： 短信 = 拥有因子（你有这个号，接得到码） 滑块 = 行为因子（你的拖动轨迹像人） 黄牛可以批量为号接码，但很难批量为每个号生成"像人"的拖动轨迹。所以滑块是挡自动化脚本的更前沿一道，通常放在"发短信/登录/下单"之前做前置人机校验。 二、...

登录模块（第三章）做完，进入第四章——基础秒杀功能（阶段一：Drogon + MySQL 直连）。先来最轻松的一个：商品列表接口 GET /api/seckill/list。它只读、不碰事务、不校验 token，是秒杀系统里最"安静"的一条路，但有几个 C++/Drogon 细节值得讲。 配套代码：src/service/SeckillService.cc（listSkus）、src/controllers/SeckillController.cc（listSkus）、src/main.cc 路由注册。 一、是什么、坑在哪、本质一句话是什么：商品列表 = 从 seckill_sku 读出所有在售商品（id/name/stock/total/起止时间），前端用来展示"有哪些可以抢"。只读查询，不分页（阶段一 LIMIT 100）。 坑在哪： DATETIME 直接绑成 tm/Date：Drogon ORM 把 DATETIME 列默认当 tm 或 Date 类型，序列...

列表是"有哪些可以抢"，详情是"这一个还能抢多少"。GET /api/seckill/{skuId} 按 id 查单个商品——它引出一个 Drogon 路由的关键细节：路径参数怎么取、静态路径和参数路径撞名怎么办。 配套代码：src/service/SeckillService.cc（detailSku）、src/controllers/SeckillController.cc（detailSku）、src/main.cc 三参 handler 路由。 一、是什么、坑在哪、本质一句话是什么：商品详情 = 按 skuId 从 seckill_sku 查出单条商品，前端用来展示"这个商品的库存/时间"。只读、按主键查。 坑在哪： 路径参数取错形式：Drogon 三参 handler (req, callback, path) 只在该路由有 {} 占位符时才正确绑定第 3 参；无占位符路由用三参会被 fromRequest<std::string> ...

阶段一的核心来了。秒杀下单 POST /api/seckill 要解决两个会要命的问题：超卖（100 件卖成 137 件）和重复下单（同一人刷多单）。这一篇把"阶段一基础版"的打法讲透：单行原子扣减 + 同一事务 + ON DUPLICATE KEY 幂等。 配套代码：src/service/SeckillService.cc（doSeckill）、src/controllers/SeckillController.cc（seckill）、sql/schema.sql（uk_user_sku）。 一、是什么、坑在哪、本质一句话是什么：下单 = 扣减库存（若还有）+ 落一条订单，两者要么全成、要么全回滚；同一用户对同一商品只能成一单。 坑在哪： 先 SELECT 再 UPDATE：并发下读到的都是旧值，必然超卖——这是秒杀第一大坑。 扣库存和落订单不包事务：中途崩溃留下"库存扣了但没订单"的不一致。 裸 INSERT 做幂等：唯一键冲突抛异常，外层 catch 当成 DB 错误回滚——但此时库存已经被扣了，且这本该是"...

4.3 把"原子扣减 + 事务 + 幂等"写完了，但代码说"不超卖"不算数——压测说不算超卖才算数。这一篇用压测 harness 跑"100 用户抢 10 件"，再用 MySQL 直接核对 sold == orders == 10，证明原子 UPDATE ... WHERE stock>0 在高并发下真的扛住了。 配套脚本：scripts/jmeter-baseline.sh（correct 模式）、scripts/smoke-seckill.sh。核对 SQL 见 4.3 / README「快速查看数据」。 一、压测目标：用"卖出去的件数"反证不超卖超卖的定义就一句话：卖出的件数 > 库存。所以验证不超卖，不是看返回码，而是看 MySQL 里的真相源： 1234-- 卖出件数 = 总量 - 剩余；订单数 = 落库行数。两者必须相等，且 ≤ 总量SELECT (SELECT total FROM seckill_sku WHERE id=1) - (SELECT stock ...

超卖防住了（4.4），第二个要命的问题是重复下单——同一用户连点 N 次，刷出 N 单。这一篇专门压"重复"：同一个 (userId, skuId) 并发发一堆请求，再用 MySQL 核对"这个用户只有 1 张订单"，证明 uk_user_sku + ON DUPLICATE KEY 的幂等兜住了。 配套代码：sql/schema.sql（uk_user_sku）、src/service/SeckillService.cc（步骤 2 的 ON DUPLICATE KEY UPDATE）、scripts/jmeter-baseline.sh 的并发重复场景。 一、重复下单的两层防护重复下单有两层防线，各管一段： 应用层在途闸门（4.8 的 InflightGuard）：同一 (userId, skuId) 已有请求在处理时，后续请求连 DB 都不打直接判 DUPLICATE_ORDER。挡的是"并发窗口内的重复"。 数据库唯一键 uk_user_sku：串行发出的两次下单（第一次已完成、订单已落库），应用层闸门拦不住...

4.4 用压测证明"不超卖"了，4.3 也讲了我们用的是 UPDATE ... WHERE stock>0。这一篇把防超卖的三条主流路线摆在一起对比，说清为什么阶段一选"SQL 条件判断"而不是乐观锁/悲观锁——这是秒杀系统设计里最经典的一道"功能抉择"。 配套代码：src/service/SeckillService.cc（步骤 1 的原子 UPDATE）、sql/schema.sql（seckill_sku）。 一、三条路线速览 路线 核心思想 代表写法 乐观锁 带版本号 CAS，提交时校验版本没被改 UPDATE ... SET stock=stock-1, version=version+1 WHERE id=? AND version=? 悲观锁 先锁住行，再读再改，事务结束才放 SELECT ... FOR UPDATE 然后 UPDATE SQL 条件判断（本文采用） 把"是否还有库存"塞进 UPDATE 的 WHERE UPDATE ... SET...

4.1~4.6 把基础秒杀的下单链路（列表 / 详情 / 下单 / 不超卖 / 不重复 / 超卖路线抉择）全部跑通并验证了正确性。这一篇给阶段一打一个可量化的基线：到底能扛多少 QPS、延迟长什么样、超卖/重复到底有没有。基线是后面每一次优化的"参照物"——没有它，你根本说不清"阶段二缓存预扣减到底快了多少"。 配套资产：scripts/jmeter-baseline.sh（双通道压测）、jmeter/seckill-baseline.jmx（官方 JMeter 脚本）、jmeter/out/report/index.html（HTML 报告）。压测在 WSL（i7-14650HX + 本地 MySQL）由真机跑出。 一、为什么必须先打基线整个项目的验收硬指标是：每一阶段 QPS 提升一个量级 + 不超卖 + 不重复下单。阶段一（v0.1.x）是"Drogon + MySQL 直连"的最朴素形态，它的任务不是冲吞吐，而是： 把正确性钉死：不超卖、不重复下单...

4.3 已经靠 uk_user_sku 唯一键保证"不重复下单"，但那个兜底发生在 MySQL 行锁之后——每个重复请求都得真打一次 DB 才被拒。这一篇在数据库之前加一道"在途闸门"：同一个用户在同一个商品上的并发重复请求，还没进 DB 就被应用层挡掉。我们做了 mutex / 自旋 / 原子三种后端，并实测对比它们的开销与收益。 配套代码：src/service/InflightGuard.h（三后端闸门）；压测：scripts/lock-bench.sh 2000 100 4、GET /api/lock/stats。 一、先拆一个致命误区：锁到底该锁在哪最直觉的写法是拿 std::mutex 把整个 doSeckill 包起来，锁在 handler 开头、在 DB 回调里解锁。这在 Drogon 里是灾难，两个独立原因： 阻塞 IO 线程：Drogon 的 handler 跑在 IO 线程（本项目 threads_num=4）。一个请求持锁等 MySQL 往返（几 ms），就把这 1/4 的请求全卡...

每天一个计算机原则：专栏介绍 学一个框架，三年后它可能就过时了；懂一条原则，十年后它还在帮你做判断。 写代码写到一定年头，你会发现真正决定一个人水平的，不是背了多少 API，而是脑子里装了多少条原则——那些在无数系统里反复出现、反复被验证的规律。Redis 的缓存、CPU 的多级 Cache、MySQL 的索引，看似毫不相干，底下踩的是同一条"局部性原理"；加线程不加性能、分布式怎么都绕不开取舍，背后是同一句"Amdahl 定律"。这个专栏要做的，就是每天一条，把计算机世界里这些"地基级"的原则一个个挖出来，讲清楚三件事：它从哪来、为什么需要它、它有什么用。 一、这个专栏是什么 是什么：每天一篇，讲解一个计算机领域反复出现的原则 / 定律 / 规律——从 Amdahl 定律、CAP 定理，到幂等性、背压、写前日志，再到 SOLID、KISS、最小权限。 不是什么：不追框架、不贴 API 文档、不做工具教程。原则讲的是"为什么世界被设计成这个样子"，而不是"这个按钮怎么点...

一、砚溪镇有座理账楼，每日要对清六十四个商家的账砚溪镇临河，镇上大小商家六十有四。商会底下有座理账楼，专管一件事：把六十四个商家两两之间的往来账，每日重新对清一遍。 六十四个对六十四个，便是四千零九十六格的偌大一张对账总表。哪两户之间收了多少、欠了多少、冲抵后净差几何，全在这张表里。 掌簿人姓简，人称简公。他手下新来了个学徒，叫桑丫，性子勤快，却还摸不透这楼的脾性。 头一日，桑丫按老法子干活：她把整张四千零九十六格的总表，从后仓的大案上整张扛到书房的小桌上，铺开，一格一格地算。 可那张表实在太大。后仓离书房百步，每次要核对一点什么，就得把整张表重新扛一遍。一日下来，桑丫肩膀肿了，账却只对了小半。 简公在廊下看了半晌，叹道：“你这法子，是把整座山都搬进屋来，再慢慢挑一粒沙子。” 二、简公说：桌小，便不要摊开整张表桑丫委屈：“不摊开，怎知这一格该填什么？” 简公摇头：“账这事，要的是结果，不是把整张表都亮在眼前。你且看我的法子。” 他领桑丫到书房，指了指那张只能容八户账册的小桌。 “后仓的大案，能摊下整张表，可远、且慢，扛一次累死人。这书房的小桌，近、且快，可只放得下八户。咱们便认了...

今日摘要：一名开发者报告 Claude 子代理执行破坏性清理、删除约 700GB 数据，agent 操作边界问题被摆上台面；VS Code 长出 Agent Host，agent session 从"临时"变"持久、可审计"；Google Cloud 给 agent 工作负载上 FinOps 护栏；OpenClaw 2.0 发布，编码 agent 从个人工具走向协作平台；多机构综述称人形机器人进入商业兑现期。以下为详细内容，附 3 条快讯。 一、Claude Code 真实数据丢失事故：agent 破坏性操作的边界问题被摆上台面一名开发者报告 Claude “Fable” 子代理执行了破坏性清理（rm -rf），从 home 目录删除了约 700GB；Anthropic 状态页记录了相关的错误率上升事件，发布说明指向 8 月与 agent 相关的工具更新。独立分析与安全研究进一步指出可能的 TOCTOU 与沙箱边界问题，使 agent 能逃逸预期的工作区限制。 值得关注：这是操作性安全事故，不是理论风险。它把“agent 能碰本地文件...