<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[qq_35107975的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/qq_35107975</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; qq_35107975]]></copyright><item><title><![CDATA[10 行代码给 Agent 加上自我纠错能力]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163604071</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163604071</guid><author>qq_35107975</author><pubDate>Mon, 17 Aug 2026 06:42:45 +0800</pubDate><description><![CDATA[Agent 输出了一个错误的 SQL 查询——没有人类介入，它自己能发现并修正吗？：黑盒 → 入口 → 核心机制 → 三层实现 → 锚点前三篇我们做了三件事：给 Agent 装上了大脑（ReAct 的推理循环）、装上了计划能力（PtE 的规划执行分离）、以及看清了它们的 Token 账单。Agent 从"能回答问题"进化到了"能完成多步任务"。ReAct 每步都推理但不会检查推理对不对。PtE 先规划再执行但不会验证计划合不合理。]]></description><category></category></item><item><title><![CDATA[把 Agent 的推理从循环体内拉到循环体外]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163581577</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163581577</guid><author>qq_35107975</author><pubDate>Mon, 17 Aug 2026 06:42:19 +0800</pubDate><description><![CDATA[ReAct 每一步都做"推理→行动"循环，Token 消耗大、执行慢。Plan-then-Execute 把推理集中到规划阶段，一次性制定完整计划再执行。：理解了"规划与执行分离"，你就知道为什么有些场景 Token 可以省一半。上篇我们把 ReAct 拆成了"推理→行动"的每步循环——每一步 LLM 都先想再干。这篇我们来看一个反直觉的进化：如果让 Agent 先一次性规划好所有步骤再执行，Token 能省多少？]]></description><category></category></item><item><title><![CDATA[ReAct 原理深度拆解：12 行代码到生产部署的完整指南]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163581564</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163581564</guid><author>qq_35107975</author><pubDate>Fri, 14 Aug 2026 11:16:58 +0800</pubDate><description><![CDATA[LLM 能回答问题但无法完成多步任务——ReAct 给 LLM 装上了"思考→行动→验证"的试错循环：一个答不出的问题 → 最简实现 → 每轮 Token 账单 → 决策框架 → 一句话锚点上篇我们提到 ReAct 是 Agent 最核心的执行模式——看一眼三元组图就懂了。但一张图能告诉你的事太少了；它不告诉你每轮消耗多少 Token、不告诉你什么情况下会死循环、不告诉你生产实现和教程实现差了多远。]]></description><category></category></item><item><title><![CDATA[ConcurrentHashMap 面试八股 vs 生产踩坑：三个事故让你重新理解线程安全]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163551847</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163551847</guid><author>qq_35107975</author><pubDate>Fri, 14 Aug 2026 11:16:23 +0800</pubDate><description><![CDATA[上篇讲了线程池参数面试和生产场景的落差，这篇我们来看另一道高频面试题——ConcurrentHashMap。线程安全？标准答案背得滚瓜烂熟，但组合操作照样翻车。]]></description><category></category></item><item><title><![CDATA[Dubbo 服务版本管理不善导致灰度失败]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163551839</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163551839</guid><author>qq_35107975</author><pubDate>Wed, 12 Aug 2026 08:37:28 +0800</pubDate><description><![CDATA[灰度发布流量全量走到旧版本，新版本 Provider 零流量，registry 机器齐全却路由不到→→→→。]]></description><category></category></item><item><title><![CDATA[日志凭空消失？Filter 顺序错了——Dubbo 一个 order 值让 ExceptionFilter 成了摆设]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163522241</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163522241</guid><author>qq_35107975</author><pubDate>Wed, 12 Aug 2026 08:37:00 +0800</pubDate><description><![CDATA[Provider 端 SecurityFilter 拦截了非法请求，返回了错误——但 ExceptionFilter 没写那行日志。]]></description><category></category></item><item><title><![CDATA[BeanDefinitionOverrideException 排查：Dubbo dubboBootstrapApplicationListener 重复注册]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163522231</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163522231</guid><author>qq_35107975</author><pubDate>Tue, 11 Aug 2026 07:59:43 +0800</pubDate><description><![CDATA[Spring Boot 2.1.5 + Dubbo 2.7.6，启动报 BeanDefinitionOverrideException，bean 名称 ‘dubboBootstrapApplicationListener’]]></description><category></category></item><item><title><![CDATA[Dubbo LeastActive 负载均衡新节点被打满？源码解析 active 计数器陷阱]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163491468</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163491468</guid><author>qq_35107975</author><pubDate>Tue, 11 Aug 2026 07:59:10 +0800</pubDate><description><![CDATA[追根溯源：Consumer 发起 RPC 调用时，经过进入集群层的负载均衡选择（AbstractClusterInvoker.java#L253-L266根据 Consumer URL 的参数实例化对应的策略实现。如果配了，就走#L40-L114）：L63——获取每个 Provider 当前活跃请求数L69-L75: 找到活跃数最低的 Provider——每次找到更低值就重置选中的节点集合L95-L97: 如果只有一个 Provider 活跃数最低，直接返回，忽略权重第三行是关键。]]></description><category></category></item><item><title><![CDATA[排查 3 小时，问题竟在 Dubbo 路由规则：一个 force 的坑]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163491457</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163491457</guid><author>qq_35107975</author><pubDate>Mon, 10 Aug 2026 07:40:29 +0800</pubDate><description><![CDATA[上篇讲了 Dubbo 异步调用回调未执行的源码追踪，这篇来看另一个同样反直觉的问题。Dubbo（2.7.23）报错 ——但注册中心 Provider 明明在线。翻到  的源码才发现——路由规则把 Provider 全过滤了。凌晨 2 点，线上报警：Consumer 调用远程服务超时。查看日志，堆栈里躺着一条干巴巴的异常：
这条规则的意思是"只允许调用  网段的 Provider"。但这次灰度发布的机器全在 ——加上 ，Consumer 直接拿不到任何 Provider。【直觉 vs 现实】：大多数人看到"N]]></description><category></category></item><item><title><![CDATA[Dubbo 2.7.5 的线程上下文陷阱：从版本演进看 AllChannelHandler 的设计之痛]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163430073</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163430073</guid><author>qq_35107975</author><pubDate>Mon, 10 Aug 2026 07:40:05 +0800</pubDate><description><![CDATA[Dubbo 消费端配置 async=true 异步调用，通过 RpcContext.getFuture() 拿到 CompletableFuture 注册 whenComplete 回调，但回调始终不执行。100 QPS 时正常，500 QPS 时大面积静默，滚动重启恢复，15 分钟后又复现。：Dubbo 2.7.5 DubboInvoker → AllChannelHandler 线程池排队 → DefaultFuture.complete → ThreadlessExecutor 副作用。]]></description><category></category></item><item><title><![CDATA[Dubbo 泛化调用参数序列化异常排查：PojoUtils 的三个隐匿陷阱]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163430059</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163430059</guid><author>qq_35107975</author><pubDate>Sun, 09 Aug 2026 09:08:06 +0800</pubDate><description><![CDATA[网关层泛化调用$invoke批量调用 Provider，时偶出现 ClassCastException / InstantiationException / StackOverflowError→ 3 个陷阱各自的源码位置上篇讲了 Dubbo 线程池满，根因在 Linux 用户线程数限制。这次 Dubbo 泛化调用又报了一个异常——。第一反应是 Hessian2 序列化问题，检查了一圈序列化配置，全是正常的。不是序列化的问题。]]></description><category></category></item><item><title><![CDATA[源码级排查：Dubbo 线程池爆满的另类根因——Linux nproc 限制]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163408209</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163408209</guid><author>qq_35107975</author><pubDate>Sun, 09 Aug 2026 09:07:26 +0800</pubDate><description><![CDATA[Dubbo Provider 报，线程池配置合理、QPS 正常：Dubbo 拒绝策略源码 → ThreadPoolExecutor.addWorker() → JVM pthread_create 失败 → ulimit -u 限制上篇我们排查了 Dubbo 直连模式调用失败的问题，根源是 URL 构建少了一个参数。这次 Dubbo 又报了另一个经典错误——线程池爆满，但这次根因不在 Dubbo 代码里。]]></description><category></category></item><item><title><![CDATA[DaemonSet 滚动更新导致 Prometheus 采集中断——优雅终止排查实录]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163408191</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163408191</guid><author>qq_35107975</author><pubDate>Sat, 08 Aug 2026 08:37:10 +0800</pubDate><description><![CDATA[DaemonSet RollingUpdate 过程中旧 Pod 被 SIGTERM → 进程不优雅退出 → Prometheus 采集链路断裂: Pod(优雅终止机制) → CRI(信号转发) → Node(kubelet 驱逐) → 集群(PDB 边界)上篇讲了 DaemonSet 更新策略的选择陷阱——OnDelete 和 RollingUpdate 各有适用场景。这篇我们来看 RollingUpdate 本身的一个更隐蔽的问题：更新过程中服务中断。]]></description><category></category></item><item><title><![CDATA[DaemonSet OnDelete 策略详解：为何 rollout restart 无效及正确迁移方案]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163322154</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163322154</guid><author>qq_35107975</author><pubDate>Sat, 08 Aug 2026 08:36:20 +0800</pubDate><description><![CDATA[给 fluent-bit DaemonSet 改了镜像版本，命令成功了——但 Pod 一个都没重启: Pod 状态 → 策略分层对比 → Node 版本漂移 → 集群策略选择上篇讲了 DaemonSet RollingUpdate 导致节点逐个宕机——原因是 CNI Pod 被终止后节点网络断连，kubelet 无法上报心跳，node controller 直接判 NotReady。教训是"关键基础设施 DaemonSet 别用 RollingUpdate"。]]></description><category></category></item><item><title><![CDATA[DaemonSet 滚动更新：节点一台接一台宕机，根因在更新策略]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163322153</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163322153</guid><author>qq_35107975</author><pubDate>Fri, 07 Aug 2026 08:32:46 +0800</pubDate><description><![CDATA[DaemonSet 滚动更新 CNI 配置 → DaemonSet Pod 逐节点终止重建 → 节点逐台 NotReady: Pod → CRI → Node → 集群 逐层排查上篇讲了 Pod 调度不均衡问题——nodeAffinity 配置写反导致 Pod 挤在同一台节点，资源利用率一边倒。这篇我们来看另一个因配置引发的连锁反应：DaemonSet 滚动更新导致节点逐个宕机。]]></description><category></category></item><item><title><![CDATA[K8s 调度不均衡排查实录：required 和 preferred 选错引发的连锁反应]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163290878</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163290878</guid><author>qq_35107975</author><pubDate>Fri, 07 Aug 2026 08:31:56 +0800</pubDate><description><![CDATA[上篇我们聊了 Pod CrashLoopBackOff 时日志拿不到的排查思路，用 crictl 绕过 kubectl 直接读容器运行时日志。这篇看一个完全不同的方向——Pod 不是起不来，是起来了但分布不均衡。：Deployment 20 副本上线后，Pod 全堆在 2 台 Node，其余 Node 资源充裕但无 Pod 被调度：Events 发现 FailedScheduling → 统计匹配标签的 Node 数 → 审阅亲和性配置 → 修正为 preferred → Pod 分布均匀。]]></description><category></category></item><item><title><![CDATA[K8s 实战：CrashLoopBackOff 状态下 kubectl logs 拿不到日志的三层排查方案]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163290872</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163290872</guid><author>qq_35107975</author><pubDate>Thu, 06 Aug 2026 08:52:45 +0800</pubDate><description><![CDATA[Pod 一直 CrashLoopBackOff，kubectl logs 看不到崩溃前的错误日志：坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25，容器运行时为 containerd v1.6。crictl 命令在 containerd v1.6+ 支持-a参数查看所有容器。]]></description><category></category></item><item><title><![CDATA[Pod 启动慢排查实录：Init Container + ImagePullPolicy 双重优化]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163262503</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163262503</guid><author>qq_35107975</author><pubDate>Thu, 06 Aug 2026 08:52:05 +0800</pubDate><description><![CDATA[灰度 5% 流量 → 超时率飙升 → 回滚 → 新版 Pod 启动慢了 3 分钟：坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25，容器运行时为 containerd 1.6。]]></description><category></category></item><item><title><![CDATA[Nginx upstream keepalive 连接池中毒排查实录]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163262448</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163262448</guid><author>qq_35107975</author><pubDate>Wed, 05 Aug 2026 08:42:26 +0800</pubDate><description><![CDATA[Nginx 反代部分请求 502 / body 错乱 / 上游报"invalid header field" |：tcpdump → keepalive 连接请求边界错位 → Content-Length 不匹配 → Nginx event-driven state machine 未校验 socket 残留上篇我们看了中间层通过 conntrack 超时静默发 RST 导致连接断裂的情况，这篇来看另一种连接异常——连接没断，但数据被悄无声息地污染了。]]></description><category></category></item><item><title><![CDATA[TCP keepalive 与 conntrack 超时不一致导致连接 RST——排查全过程]]></title><link>https://blog.youkuaiyun.com/qq_35107975/article/details/163231219</link><guid>https://blog.youkuaiyun.com/qq_35107975/article/details/163231219</guid><author>qq_35107975</author><pubDate>Wed, 05 Aug 2026 08:41:37 +0800</pubDate><description><![CDATA[连接空闲 30 分钟后复用报错 |上篇我们分析了 TCP RST 包的常见原因——端口未监听、防火墙拦截、应用层主动关闭。这篇来看一个更隐蔽的场景：两端连接都是 ESTABLISHED，中间层却悄悄断了。T0.000 客户端发出业务数据。T0.001 中间设备回了 RST——中间这 1ms，数据包在 conntrack 表里查无此人。不是端口问题，不是进程挂了——是内核的 conntrack 表项被清了，而两端都不知道。]]></description><category></category></item></channel></rss>