- 博客(386)
- 收藏
- 关注
RSS订阅原创 LLM Ops 评测与可观测实战（7）：线上质量监控：用户反馈信号的代理指标设计
第一，重做这种最强的单信号 r=-0.52，三个信号做方差正确的线性组合后，合成分的 r 可以逼近 0.65+，而 62 条显式评分算出的 r=0.326 本身就带着千分之几样本的抽样抖动，置信区间宽到没法比。**对话式应用里，每个会话都自带一组免费的行为数据：重做（用户点"重新生成"或对同一问题换个说法再问）、采纳（复制回答、按建议执行下一步、点击回答里引用的文档）、弃置（会话中途消失、追问一次后放弃）、修正（用户纠正模型：“不是这个意思，我问的是……**代理指标的构造是"负向减正向"的加权合分。
2026-10-12 09:47:14
270
原创 自媒体内容工厂实战（1）：生产与分发分离：用一个 Git 私有仓当唯一交接面
先给结论：内容工厂要搭的第一样东西不是提示词模板，是交接面。我们的做法是生产与分发分离——需求方和生产线只认一个 Git 私有仓，需求方只写需求单，工厂只写稿，任何绕过仓库的沟通都不作数。想用 Git 管理内容的人，真正要落地的只有三样：一张目录协议、一台让非法稿件发不出去的状态机、一个交付目录的齐套检查。本篇两个实验都在本机实跑，逐字输出全部进了证据目录，需求方可以随机挑一个重跑。
2026-10-12 09:17:36
125
原创 LLM Ops 评测与可观测实战（6）：Token 成本工程：缓存、路由与压缩的预算控制
LLM 应用的成本结构与传统服务截然不同：服务器按核时计价、用量与成本近似线性，而模型调用按 token 计价，输入侧还藏着系统提示、会话历史、检索片段三大吞金兽，一次带长历史的对话，输入开销能占整单成本的八成。这决定了落地顺序应该是"先路由大头流量，再排布缓存纪律，最后动压缩"——压缩排在最后不是因为难，而是因为它改变模型看到的上下文，是三者里唯一可能伤效果的，必须配合回归评测走，性价比需要效果侧确认后才结算。输入侧优化吃规模，系统提示这类"每条请求都重复支付"的前缀，是缓存的头号目标。
2026-10-11 09:47:09
173
原创 LLM Ops 评测与可观测实战（5）：LLM 调用链追踪：从请求到 token 的全链路观测
上一篇把坏变更拦在了发布门口，但门禁只能保证"上线前已知的好"，挡不住"上线后才暴露的怪"。场景回到那个客服 RAG 机器人：产品经理甩来一条用户反馈——“我问退款进度，它答非所问”，附带一个会话 ID。接下来的三十分钟里你要回答：这条请求当时检索到了哪三份文档？rerank 把它们排成了什么顺序？两次模型调用各自的输入输出是什么？工具查订单接口返回了什么？答案如果都在日志里，排查是一分钟的事；如果只在同事的回忆里，就是一天的事。调用链追踪（tracing）就是把一次请求穿过的所有环节记成一棵树：每个环节一
2026-10-10 09:48:46
233
原创 LLM Ops 评测与可观测实战（4）：Prompt 回归测试：版本管理与变更门禁
G2 是唯一可用的折中，但也漏掉了 90% 的轻度劣化——补漏的手段不在阈值里而在结构里：把回归案例按"安全约束 / 核心链路 / 长尾"分层，安全层 1 条回归即阻断，核心层 3 条，长尾层只告警。**实验二的仿真会给出一个不舒服的结论：任何单一阈值都在"误伤带权衡的改进"和"漏掉轻度劣化"之间摇摆。**总分对比是最弱的证据（第 1 篇的置信区间已经证明），强证据是逐案例状态机：对每个案例，旧版记为稳定过/稳定败/时好时坏三态，新版同样，然后只看翻转——稳定过→稳定败是硬回归，必须逐条人看；
2026-10-09 21:05:57
166
原创 LLM Ops 评测与可观测实战（3）：自动打分：规则评分、LLM-as-judge 与一致性校验
其一，拿 judge 的绝对分数当跨期可比指标：换一版裁判提示词，全体分数平移 0.2，你的"质量周报"就画出一条不存在的曲线——一切比较必须固定裁判版本，或改用同集配对差值。**第三层人工：不是兜底而是校准与审计。**人工不参与每次评测，只做两件事：给 judge 建立"与人一致"的出厂校准（下面实验二的阈值 sweep），以及每次版本评测时抽 5% 双盲复核，监控 judge 是否随被测系统的文风漂移而失准。**评测集里七成的回答本来就是合格的，一个"全判合格"的傻瓜打分器与人的一致率也能到 72%。
2026-10-04 09:17:02
230
原创 LLM Ops 评测与可观测实战（2）：golden dataset 构建：线上数据的采样与标注流程
二是线上原话本身是脏的——错别字、半截话、夹带订单号的隐私串，不清洗不能用。**均匀随机抽样的方差与层内样本量成反比，而流量分布天然头重脚轻：占比 3% 的多轮追问意图，在 300 条均匀样本里平均只有 9 条，单这一层的通过率估计误差就逼近 ±30 个百分点——等于这层没测。工程解法是带下限的分层抽样（stratified sampling with floor）：大层按流量占比分配配额，小层强制保底（比如每层不少于 25 条），代价是评测集分布与线上分布有意的偏离，收益是每层都有最低可用分辨率。
2026-10-03 12:40:27
388
原创 LLM Ops 评测与可观测实战（1）：LLM 应用为什么必须有评测集：告别凭感觉验收
代码有 git，配置的每一次变更有 diff 可查，而 prompt、模型版本、检索参数这三样东西的变更在传统流程里完全没有 diff：改了 prompt 的第三行措辞，你不知道它对"多轮追问"类问题造成了什么影响，因为没有任何基线可以对照。评测集工程的全部动机，就是把这套劣化的隐式评测换成可复现、可累积、可审计的显式评测。尺子立起来了，接下来的问题是这把尺子上的刻度从哪来：评测集不能靠几个人坐在工位上编造问题，它必须采样自真实的线上分布，并经过一套能控制一致性的标注流程。
2026-10-02 09:18:17
800
原创 AI Agent 记忆与上下文工程实战（10）：端到端实战：做一个有长期记忆的个人助理 Agent
上一篇收尾说机制全齐了，今天兑现：把九件套装进同一个个人助理 Agent，连续跑 90 天，再用逐项消融量出每一层各值几个点。照例声明：本机全部数字来自固定种子的确定性模拟，不依赖时钟与外部服务，用来演示记账方法；生产要换成真实模型、真实向量库与真实崩溃统计，跑同一套流程。
2026-10-01 08:01:29
55
原创 AI Agent 记忆与上下文工程实战（9）：记忆效果观测：定位越学越笨的退化问题
探针自己也是记忆，得按第 495 篇的规矩治理：每题记录"问题、期望命中条目、判定规则、绑定的库版本"，跑在快照上而不是活库上，否则库一边改探针一边掉分，永远说不清是谁的锅。但记忆系统还有一类失败从头到尾不给信号：库不崩、写入不报错、进程活得好好的，回答却一周比一周差——用户口中的"越学越笨"。还有一个反直觉的推论：越勤奋的 Agent 退化越快，因为它写得越多，过期证据的票数涨得也越多。观测讲完了，十篇的机制就全齐了：预算、压缩、双路径存储、检索与注入、隔离、工具调度、计划状态机、恢复治理、效果观测。
2026-10-01 08:00:03
132
原创 AI Agent 记忆与上下文工程实战（8）：长任务的记忆治理：checkpoint、恢复与失效策略
第一，从不设点的代价不是"可能全丢"这种玄学，而是白纸黑字的 347 对 169：崩溃点在前半程的任务，白工 227 步，超过任务本体的 1.9 倍——而且模型全程没有报错，它只是在"勤奋地重做已经做完的事"，这正是长任务最难看的失败形态：不是崩，是循环着崩。第二，最优间隔不值钱。B 才是惯犯：版本号挡住了旧踩新，可它对"缺席"的语义判断错了——一个键不在活库里，可能是检查点之后新出现的事实，也可能是被删掉的旧事实，两种含义共享同一个形态（查无此键），LWW 只能赌。到这里，"别把任务弄丢"的治理讲完了。
2026-10-01 07:57:11
142
原创 AI Agent 记忆与上下文工程实战（7）：子任务分解与状态机：Plan-and-Execute 的失败面
上一篇把工具定义从固定税改成了调度资源，窗口的三大户——对话历史、检索注入、工具 schema——各有各的预算方案。但长任务里还有一类开销既不是记忆也不是工具，而是任务自身的骨架：一个需求分解成十几个子任务，计划文本、每个节点的产出、失败重试的残骸，全都往上下文里堆。用 ReAct 风格一步一问的 Agent 对此无感，因为它的"计划"就是消息流水本身；而一旦上 Plan-and-Execute——先出完整计划、再逐节点执行——计划树就成了第二份账本：它既是上下文里最大的单块固定开销，又是失败传播的载体。
2026-10-01 07:55:24
192
原创 AI Agent 记忆与上下文工程实战（6）：工具定义的生命周期：大量工具的裁剪与动态注入
朴素 LRU 的表现值得细看：300 步里升池 84 次，平均 3.6 步换一次血，在场率却只有 72%——因为 15% 的均匀长尾里每个冷门工具都"恰好没见过"，一次调用就把它挤进热池、顺手挤掉一个真正的热点，下次冷门换人、热点再被换出。元工具，允许它在目录里看到"要的工具不在场"时主动召回——把缺席从"任务失败"降级为"多一跳"。方案 B 一刀砍掉 73% 的税，代价是把"正确工具在场率"折在检索质量上——检索漏了，模型连选的机会都没有，表现为"Agent 说我不会"或硬调一个不相干工具。
2026-10-01 07:53:54
57
原创 AI Agent 记忆与上下文工程实战（5）：多 Agent 协作的上下文隔离：角色、黑板与消息总线
全程共享第 8 轮撞墙：单会话的平方级膨胀到了多 Agent 变成"每 Agent 都平方"，协作人数一多最先死的是话最多的角色——这不是调窗口能救的，是拓扑病。这个决定的破坏力要到协作进入第二周才显现：A Agent 把 B 早已被推翻的草稿当成现行方案复述，C 的评审意见里混进了 D 的调试日志，每个 Agent 的注意力都被别人的思维垃圾稀释，而且没人说得清是哪一步串了台。几十个工具的 schema 静态摊进每个 Agent 的窗口，是仅次于对话历史的第二吞噬者，而且它连"摘要"的资格都没有。
2026-10-01 07:52:33
190
原创 AI Agent 记忆与上下文工程实战（4）：记忆检索时机：注入方式如何影响回答质量
五是尾部位置忘回收：上一轮重申的记忆块没摘除，新证据又进来，尾部堆成第二个"中段"，U 形曲线重新惩罚你。模型自判以 25.5% 的预算做到 0.951，看似最优，但注意它的天花板就是 P_SENSE：判断力再差 5 个点，漏检立刻翻倍，而把判断力喂上去靠的是提示词与评测，不是代码。成本侧最后一行提醒别把答案绝对化："问题后重申"质量最高但它是每轮临时块，会话一长仍要靠系统区固化，正确姿势是：稳定偏好的摘要常驻头部，本轮召回的证据尾部重申，两处内容互相引用编号而不是重复全文。触发时机有三档谱系。
2026-10-01 07:51:12
226
原创 AI Agent 记忆与上下文工程实战（3）：向量记忆与结构化记忆：长期记忆的写入路径
这就是给时近权重定系数的难点——它奖励新鲜，也放噪声进门，Generative Agents 论文用"recency、importance、relevance 三项加权"的打分式是同一个结构，系数必须用评测集调，不能拍。t=25 这一行是整篇的戏眼：居住已是新值（第 18 轮生效），预算还是旧值（第 30 轮才变）——同一时刻、不同字段、各自正确，这是"当前视图+历史回放"两个查询负载共存的最小证明。上一篇给摘要装了"分层冻结"的刹车，但被冻结的内容早已不在窗口里——它们要有去处，这就是长期记忆存储。
2026-10-01 00:17:04
716
原创 AI Agent 记忆与上下文工程实战（2）：对话压缩与摘要：什么该丢、什么必须留
第一类是粒度丢失。摘要天然朝"要点的要点"收敛：具体数字被约整、专有名词被泛指、条件从句被剪掉。“每月第一个周二下午三点例会"压两轮之后变成"定期例会”——主干还在，可执行细节蒸发。摘要器判断重要性的代理指标是"在叙事里是否承上启下"，而约束条款往往出现在对话角落，恰好是叙事上最可省的部分。第二类是不对称丢失。
2026-09-30 08:29:01
62
原创 AI Agent 记忆与上下文工程实战（1）：Agent 的记忆真相：有限上下文窗口是硬约束
其一，朴素策略从第 5 轮起就有 22/26 轮处于"回复放不下"的风险中——它把窗口用到了极限，却把极限当成了安全线，真实系统里这类请求要么在生成中途被截断，要么在网关报错，用户看到的是答到一半突然没了。厂商标的窗口长度是输入硬上限，但你的每次请求里，系统提示、工具定义、对话历史、检索注入、预留的模型回复全部共享这块空间。MemGPT 论文给出的类比非常可操作：窗口是 RAM，外部数据库是磁盘，检索写回是页交换——Agent 能"想起来"的只有此刻在窗口里的内容，其余一切只是"可检索"，不是"记得"。
2026-09-30 08:27:33
61
原创 LLM 微调实战（10）：端到端实战：从 0 训练一个行业客服模型并跑通
第九课把知识的存放位置分完拣——事实进库、行为进权重、改写独立成层——系列的组件就全齐了。终章把它们装上整车：一家家电售后公司（空调/冰箱/洗衣机 400 热线加几万名安装维修师傅的派单网络）立项"装修助手"，从 0 训一个行业客服模型并推到生产。本篇按第一篇的立项算账、第二/五篇的数据、第三/四篇的训练、第六篇的评测、第七篇的防遗忘、第八篇的上线、第九篇的混合架构走一条完整流水线；两个实验承担"排期"和"过程监控"这两件在真实项目里最容易拍脑袋的事。
2026-09-30 08:20:52
130
原创 LLM 微调实战（9）：RAG 与微调怎么配合：知识的存放位置决策
上一篇把分诊模型送上了生产，但整个系列反复悬着一个承诺：第一篇说过"知识进 RAG、行为进权重"，可真实请求从来不是按教科书分类的——一句"我们部门新政策下出差住宿能报多少"同时含有身份事实、政策知识和报销话术。修法有三档：维护同义词典（便宜但静态）、微调一个查询改写模型（本篇 SYN 表的学习版，几百条样本就够，正好是第三篇 LoRA 用武之地）、或让生成端模型在回答前先输出标准化查询（微调模型的行为规格之一）。（政策额度、流程版本、库存数字）——版本管理、可溯源是刚需，放文档库，永远不进权重；
2026-09-30 08:19:29
248
原创 LLM 微调实战（8）：微调模型上线全流程：打包、vLLM 部署与版本管理
逐行读：每 token 的 KV 是 128KB，9.6GB 的池子名义上能挂 43 路 1800 token 的并发，但引擎配置把 max_num_seqs 收在 12——KV 容量常常不是第一瓶颈，单卡带宽与调度开销才是，模拟里的每路 40 token/s 就是这种约束的体现。每次发布同时冻结三样东西：模型目录哈希、评测集版本与分数（第六篇的五件套）、推理配置（引擎版本、max_model_len、采样默认值）——三者缺一，"回滚"就无从谈起。，发布流程上你给任何二进制制品的严谨度，这里都只多不少。
2026-09-30 08:18:02
220
原创 LLM 微调实战（7）：灾难性遗忘与模型合并：专业化的代价
因为它平均的是"同一个目标周围的噪声"，不碰任务差异。跨任务直接平均：两个任务的 loss 双双爆到 0.6+，精确等于几何上的"距离²/4"——两个不相干的最优点取中点，等于同时背叛两边，这就是"把代码模型和批改模型简单平均做出个废物"的数学解释。第二行混训拿到 0.662/0.700：冲突并未消失，只是被摊平——注意这个线性模型容量下两个反号规则不可兼得，真实 LLM 参数冗余大得多，混入 10~30% 旧任务数据回放通常能把两边都推回高位，但"共享关键参数=必留冲突"的几何直觉不变。
2026-09-30 08:16:38
440
原创 LLM 微调实战（6）：评测集是护城河：微调效果的自动化评测
数据配比表（第五篇）交出来那天，宠物医疗连锁的分诊助手项目组吵了一架：有人说"我试了 20 个 case，微调后明显变好"，有人说"我试了 10 个，没区别"。另一点：+0.397 的提升大部分来自格式合规——真实项目里这很典型，微调的第一桶金是"学会说规矩话"，第二桶才是"学会判断"。明细比均分有信息量：基座几乎每个案例都栽在格式（缺"分诊等级"字段），唯独案例 4 格式全对却错得最隐蔽——把"可居家观察"的咬胶误判成"紧急催吐"，三层分数里它照样拿了 0.720，因为 ROUGE-L 与格式都满分。
2026-09-30 08:14:46
190
原创 LLM 微调实战（5）：垂直领域数据构造：让训练样本像真实业务
垂直领域数据工程最容易犯的错，是把"条数够多"当成"像真实业务"：造了三万条样本，分布却是拍脑袋的比例，上线第一天就被真实流量的长尾打爆。更微妙的是最热 3-gram 占比：模板少时任何三字片段都高度集中（模型会学到"报修"式口头禅），而 12 模板配置里残留的 1.33% 集中片段正是槽位高频词"设备"“处理”，属可接受。上限不够就加模板、加槽位维度（语气、客户角色、上下文片段），或者把模板产物交给强模型做同义改写再回流去重——用蒸馏的多样性补模板的骨架，两源合流的数据才既有分布又有变化。
2026-09-30 08:13:24
160
原创 LLM 微调实战（4）：QLoRA 与 4bit 量化：单卡跑通 7B 微调
—注意力里 k_proj 之后的个别通道、MoE 的专家门控常是重灾区，所以才有"对关键层保留高精度"的后续方案（GPTQ/AWQ 用误差补偿、LLM.int8 的思路做混合精度），但 QLoRA 用简单分组就够用了，因为 LoRA 旁路本身是 bf16 全精度，量化误差进不了被训练的部分。，每次前向反量化成 bf16 再算，数值计算路径与全精度一致——代价是量化误差固定存在且不可被训练消除（被量化的是冻结的 W，梯度只流过 B·A 旁路），收益是速度损失约 15~25% 的 dequant 开销。
2026-09-30 08:11:28
179
原创 LLM 微调实战（3）：LoRA 实战：rank、alpha 与显存开销的关系
全量微调让 W（比如 4096×4096）里每个元素都动，LoRA 则冻结 W，只训练两个窄矩阵 A（r×4096）和 B（4096×r），前向变成 y = Wx + (α/r)·B·A·x。第二个实验把 LoRA 的最小单元抽象出来：6×6 权重矩阵，冻结 W，用 s·B·A（s=α/r）去逼近一个满秩的理想增量 D=T−W，手写 SGD 训练 400 步。中段是全篇最重要的一列数：理想增量 D 是满秩（6）的，rank=1 逼近完还剩 81% 的能量没学到，rank=6 才归零——，不是能不能跑得下。
2026-09-30 08:10:00
647
原创 LLM 微调实战（2）：SFT 数据工程：指令集的构造、清洗与去重
其一，五道规则各抓各的缺陷、零误伤——真实语料上做不到这么干净，所以剔除统计必须逐规则留存，一旦发现"回答与意图不匹配"误杀了大量正常样本（中文意图词未必出现在话术里），要么改规则要么换成分词重合度，瀑布日志是唯一能发现这种事的证据。：对改写型重复（蒸馏数据尤其常见，同一条指令让大模型"换种说法再写三遍"产生的正是这种）必须把阈值压到 0.6 附近，而阈值一低，正常样本被误杀的风险又上升——同一批语料上，0.8 阈值是常配的起点，高重复风险的蒸馏源单独配 0.6。（最贵，只留给评测集与边界案例）。
2026-09-29 09:16:31
343
原创 LLM 微调实战（1）：什么时候该微调：预训练、微调与 RAG 的成本边界
RAG 只动第二处：每次查询把检索到的片段拼进 prompt，模型权重一个比特都不变，所以它天然适合"知识经常变、查询量可控"的场景，代价是每次推理都要为这几千 token 的上下文重复付费，而且检索器召回什么模型就信什么。这是《LLM 微调实战》系列的第一篇，之后八篇会把 SFT 数据、LoRA、QLoRA、评测、上线逐个讲透，而本篇先回答一个更靠前的问题：花了一个月做微调，结果发现该用 RAG——这种事故怎么在立项阶段避免。预训练、微调、RAG 的差别不在"智能程度"，而在。，这要用第二笔账说明。
2026-09-28 09:19:41
370
原创 数据库高可用与容灾实战（10）：架构实战：为一个 500GB 生产库设计高可用方案
这一篇做终章收束：把前九篇攒下的所有零件、参数与教训，装进一道典型的综合题——某核心业务 MySQL 库，数据量 500GB、写峰值 1500 TPS、读峰值 20000 QPS、年增 40%，部署在两个可用区，SLA 承诺 99.99%、RPO=0、RTO 不超过 5 分钟，团队只有三名 DBA。答案在数据里，不在架构图的方框里。选骨架（B 案 + 两个补丁）之后，把七件套参数逐条装配，每条都注名出处篇号，最后输出一张不留情面的验收清单——没有出处和验收动作的架构描述，在评审会上等于没说。
2026-09-28 09:18:08
365
原创 数据库高可用与容灾实战（9）：机房级故障演练：混沌工程怎么做到可回滚
（用业务指标而非资源指标描述"正常"：写成功率、P99 时延、从库延迟上界）、
2026-09-27 09:24:01
43
原创 数据库高可用与容灾实战（8）：亿级大表清理与归档：pt-osc 与 gh-ost 原理实战
另一个反直觉点：删除任务"主库很快"从来不是好事，限流器的目标函数应该是"从库延迟上界 + 业务高峰避让"，而不是"今晚必须删完"。圈住两亿行，undo 表空间被撑到磁盘报警、一个不可拆分的巨型事务让从库延迟爬到小时级（第 1 篇 MTS 栅栏的极端形态）、回滚比删除更慢、删完磁盘还不归还（第 1 篇的高水位）。对比"固定节奏每块睡 0.5 秒"与"延迟超过 0.2 秒就暂停派发下一块"的自适应策略。清理与重建解决的是"单实例内的历史包袱"。块大小下"查出的行集"与"删掉的行集"必须严格同界，用。
2026-09-27 09:22:58
58
原创 数据库高可用与容灾实战（7）：PITR 时间点恢复：把误删的数据找回来
其三，闪回只修"这次误操作"，不修"这之后的合法更新"——误删后业务又新建了数据，undo 包里的 UPDATE 会覆盖新值，所以工具普遍要求圈定精确的时间窗与主键范围。的截断是以事务为原子的——落在截断点内开始的完整事务会被重放到它的 XID 为止，没等到 XID 的事务整体丢弃。理解这一条，就能理解为什么"停在半路"的恢复比"没恢复"更糟：半截的大事务比数据缺失更难向业务解释。一个事务的语句可能持续几十秒（大 UPDATE、批处理），它的开始事件、行事件、XID 提交事件各带各的时间戳；
2026-09-27 09:21:49
58
原创 数据库高可用与容灾实战（6）：备份体系设计：mysqldump、XtraBackup 与快照的边界
本篇把三种主流手段——mysqldump 逻辑备份、XtraBackup 物理备份、文件系统/云盘快照——各自的机制、一致性与时间账算清楚，第 7 篇再讲如何用它们把时间拨回去。所以 XtraBackup 的备份速度接近磁盘裸速、恢复也快一个量级，但它买的只是一致性页面的集合，逻辑错误（把错删也备份进来）照单全收。它与"备份完成"之间还差一步：快照是实例级而非表级，恢复粒度粗，回滚动作会吞掉快照点之后的全部数据，必须有配套的 binlog 归档兜底。的语义内核，也是"随便什么顺序拷页都能收敛"的底气。
2026-09-27 09:20:37
196
原创 数据库高可用与容灾实战（5）：代理层路由选型：ProxySQL、中间件与直连的取舍
连接与路由这一层有四种活法：客户端直连加 DNS、客户端自带多主机插件（如 Connector/J 的 failover 模式）、地址层（VIP/LVS）漂移、独立代理层（ProxySQL、MySQL Router）或数据库中间件。但从第 1 篇开始就埋着一句话：复制只保证"传播”，不保证"可回溯"——误删、坏发布、勒索加密，代理层一律帮不上。规模账提醒另一件事：如果你的应用会话普遍带粘性（大量用户变量或长事务），代理层宣称的连接数收益会缩水到和直连同一量级，此时上代理层的理由只剩路由与故障摘除。
2026-09-27 09:19:26
161
原创 数据库高可用与容灾实战（4）：MHA 与 Orchestrator：故障探测、选主与自动切换
自动切换系统的主流程可以浓缩成五步，MHA（Perl 实现，manager 节点 + 各库上的健康检查表）与 Orchestrator（Go 实现，靠实例上复制元数据自动发现拓扑、内置 Raft 保证管理面自身的高可用）在这五步上的差异是工程性的而非路线性的。上一篇把 RPO=0 的条件拆明白了：半同步只压缩丢数据的窗口，窗口归零的那一刻恰恰依赖"ACK 来源还活着"。收集它缺的增量 binlog，过滤掉重复区间后应用——这是 MHA 最精髓的一步，等于用全集群的副本凑出旧主最后的完整账本。
2026-09-27 09:18:12
174
原创 数据库高可用与容灾实战（3）：半同步复制与无损切换：RPO=0 能不能做到
这就是半同步复制的立身之本，也是"RPO=0"这个承诺在 MySQL 体系里的唯一正统路径。8.0 时代 AFTER_SYNC 是唯一模式（AFTER_COMMIT 被废弃），正是因为 AFTER_COMMIT 的 ack 点在引擎提交之后，主库回滚时副本已收到，会产生"客户端看到回滚、从库却存在"的幽灵事务——这个坑在后面的持久性矩阵里还会再见。半同步把丢数据的窗口压缩到"降级发生的那一瞬间"，但要让这个瞬间尽可能晚、且在发生时被自动处置，就得有一套会探测、会选主、会执行切换的自动化系统。
2026-09-27 09:17:06
146
原创 数据库高可用与容灾实战（2）：GTID 与主从切换：传统位点切换为什么会不一致
这些都是真实演练里反复出现的画面，本篇先用模拟把账算细，再讲 GTID 如何把"事务身份"从偏移量升级成全局唯一主键，让切换从"猜坐标"变成"算集合差"。所以位点切换没有"运气好就对"这一说，只有"错误暴露得晚不早"：硬报错算最好的结局，静默跳过事务才是生产事故的形态。日常跑复制没问题，一到主从切换就出事：故障切换的本质上要把"从库 A 的进度"翻译成"新主 B 的进度"，而 file+offset 是。第一，它只保证"事务身份"的全局性，不自动解决"谁的数据更多"——切换前仍要选出集合最大的候选者。
2026-09-27 09:15:47
307
原创 数据库高可用与容灾实战（1）：MySQL 复制全链路：binlog dump、IO 线程与 SQL 线程
后面十篇里反复出现的选举、切换、半同步、PITR、异地容灾，全部建立在一个最基础的事实上：主库的每一次提交，要经过"生成 binlog、dump 线程推送、从库 IO 线程落 relay log、SQL 线程回放"这条四段流水线，才会变成从库里可查的数据。第二，主库写完 900 笔的时刻，"从库没收到"只有 1 笔，"收到了没回放"却有 242 笔：异步复制宕机丢数据的窗口，其实只等于"主库已落盘但未传出"的那一小截；不是"落后多少秒的真实时钟差"，而是"正在回放事件的源端时间戳"减"从库当前时间"。
2026-09-27 09:13:33
586
原创 高并发流量治理实战（10）：大促 48 小时：一次全链路压测与扩容演练复盘
系列完结篇不再引入新机制，而是把前九篇按进一次真实节奏里：某电商平台"年货节"，T-48h 全链路压测，T-0 零点峰值，T+24h 复盘。作者是当晚值班 SRE，复盘文档脱敏后如下。看的时候不妨拿着前九篇当检查表——你会发现每一个惊险时刻，背后都对应某一篇里"平时不做、战时必炸"的那件事。复盘会按无指责（blameless）原则过三个问题：探测为什么慢（命中率监控 2 分钟粒度，故障 90 秒即自愈型事件几乎不可见——改为 10 秒粒度加环比告警）；
2026-09-26 18:03:04
105
原创 高并发流量治理实战（9）：全链路压测方法：容量评估、影子表与压测标透传
回看前八篇：限流的窗口容量、熔断的检出阈值、降级的触发水位、主从延迟的等待上限……——线程池切换（任务提交时的 ThreadLocal 不会自动跟到工作线程，需要装饰器/TransmittableThreadLocal 类机制）、MQ（标必须写进消息属性，消费端恢复）、定时任务与补偿重放（入口根本没有标）、以及旁路系统（对账、报表、数仓抽取会把带影子标记的行"洗白"）。，ORM 拦截器按标改写出，成本最低、但 DDL 要双维护、大流量压测与真实业务抢同一实例的 IO/CPU，压测本身会"压"到线上）；
2026-09-26 18:00:51
68
Playwright 自动化操作富文本编辑器完整源码（Vue双向绑定+剪贴板粘贴+登录态复用）
2026-07-11
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人