@@ -14,19 +14,19 @@ head:
1414
1515![ 读者留言希望实测 MiniMax M3] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/image-20260604122811898.png )
1616
17- 根据官方介绍 ，M3 是首个同时具备 ** Coding Frontier/SOTA ** ** + ** ** 1M 上下文窗口 ** ** + ** ** 原生多模态 ** 三个核心能力的开源模型，直接把闭源模型级别的编程与长任务能力开放出来 。
17+ 根据 MiniMax 官方介绍 ，M3 是其首个同时提供 1M 上下文、原生多模态和前沿 Coding 能力的开放权重模型。这是厂商对产品的定位，是否适合具体代码库仍要靠任务验证 。
1818
19- 实测分数：项目级修复 59.0%，终端任务 66.0%， MCP 工具链 74.2%。
19+ 官方公布的基准结果包括：SWE-Bench Pro 59.0%、Terminal-Bench 2.1 66.0%、 MCP Atlas 74.2%。这些数字对应指定评测集和评测配置，不是本文独立复测结果 。
2020
2121![ MiniMax M3 官方能力介绍：Coding Frontier/SOTA + 1M 上下文 + 原生多模态] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/HJsWydIbIAAFAZL.jpeg )
2222
23- 但 Benchmark 分数归分数，真实工程场景里表现如何才是最应该关心的，大家都清楚这个道理 。
23+ 我更关心它进入真实工程后的表现 。
2424
25- 对此 ，我用一个过去遇到的线上故障来检验——一个业务高峰期因隐藏颇深的后台异步任务中的一次 Redis SCAN 操作引发的事故来测评 。
25+ 因此 ，我用一个过去遇到的线上故障来检验。已知现象是业务高峰期前台请求受影响，排查线索指向后台异步任务中的完整 Redis ` SCAN ` 循环；它是否因长期占用连接而构成主因，还要结合监控和复现验证 。
2626
2727该案例涉及复杂业务链路推理和全局诊断。同时，我会在完成故障定位和止血后，继续用 M3 尝试 Redis 源码（C）到 Go 的功能复刻、以及前后端 Redis 监控面板搭建，从异构语言重构和全链路交付两个维度继续观察。
2828
29- 下面按如下顺序展开 ：
29+ 文章按三个任务展开 ：
3030
31311 . 故障排查
32322 . 底层复刻
5050
5151![ 在 Claude Code 中验证 MiniMax M3 模型已生效] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/claude-code-verify-model.png )
5252
53- ## 故障排查：线上 Redis SCAN 指令引发的性能雪崩
53+ ## 故障排查：围绕应用层 SCAN 循环验证性能问题
5454
5555第一个案例复刻自我过去经历过的一次线上故障。为降低理解负担，这里用一个经典的电商场景来还原：该场景是大促期间“超时订单自动取消”的异步任务在跑，同时大量用户正在浏览商品。某一刻，页面大面积超时——已售、库存、浏览、收藏，所有热点数据全加载不出来：
5656
@@ -60,35 +60,35 @@ head:
6060
6161![ 将故障表象截图和错误描述一并提交给 M3] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/submit-error-to-m3.png )
6262
63- 经过片刻分析，MiniMax M3 结合代码上下文中所有涉及 Redis 操作的链路进行推断，直接定位到根因： SCAN 操作导致 Redis 服务端阻塞，进而引发日常读写操作大面积排队：
63+ 经过片刻分析，MiniMax M3 将问题定位到后台任务中的完整 ` SCAN ` 循环。它最初把原因概括成“ SCAN 导致 Redis 服务端阻塞”，这个说法不够准确： ` SCAN ` 单次调用是增量迭代，设计目的正是避免 ` KEYS ` 一类长时间阻塞；真正需要检查的是循环次数、 ` COUNT ` 、Keyspace 大小、单次延迟，以及应用是否长期占用连接。
6464
6565![ M3 定位到根因：SCAN 操作导致 Redis 阻塞，引发读写排队] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/m3-root-cause-scan-blocking.png )
6666
67- 为进一步验证其对业务链路的理解程度 ，我要求 MiniMax M3 用 ASCII 图绘制故障流转链路。M3 梳理出了完整的调用链——从超时订单异步任务触发 SCAN，到 keyspace 遍历阻塞主线程，再到页面请求排队超时——非零散症状罗列，而是一条端到端的因果链 ：
67+ 为进一步核对业务链路 ，我要求 MiniMax M3 用 ASCII 图画出故障过程。图里从超时订单任务进入 ` SCAN ` 循环，再到连接池可用连接下降和页面请求排队。这里应把“Keyspace 遍历阻塞主线程”理解为需要验证的假设，而不是 ` SCAN ` 的固定行为 ：
6868
6969![ M3 绘制的故障流转链路 ASCII 图：从 SCAN 触发到页面超时的端到端因果链] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/fault-chain-ascii-diagram.png )
7070
71- 解决方案方面， M3 没有止步于“换一个数据结构”，而是从四个维度同时给出建议——Redis 层面的数据结构调整、接口层面的原子性优化与降级策略 ：
71+ M3 随后给出数据结构调整、原子操作、降级和监控四类建议 ：
7272
7373![ M3 从数据结构、原子性、降级、监控四个维度同时给出修复建议] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/m3-four-dimension-fix.png )
7474
7575针对受影响的业务接口，M3 将串行 Redis 指令优化为一条原子操作，并附上降级策略，以控制极端情况下的影响面：
7676
7777![ 串行 Redis 指令优化为一条原子操作，并附上降级策略] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/atomic-operation-optimization.png )
7878
79- 在工程侧，M3 还给出了监控埋点建议和告警阈值参考，例如将 SCAN 操作的监控红线设在 200 ms——人类感知停顿的最大延时阈值——超出即触发告警 ：
79+ 在工程侧，M3 还给出了监控埋点建议，并把 200 ms 作为示例告警值。这个数字不能用“人类感知停顿”来证明；Redis 后台任务的阈值应根据接口 SLO、连接池容量、任务频率和历史分位延迟确定 ：
8080
8181![ 监控埋点建议与告警阈值：SCAN 操作红线设为 200ms] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/monitoring-alert-thresholds.png )
8282
8383以下是本次修改的 diff：
8484
8585![ 修复代码的 diff，M3 在实现中体现了降级和监控的设计理念] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/fix-code-diff.png )
8686
87- 以下为核心降级代码。M3 使用并发原子类保障多级缓存操作链路的线程安全，并对缓存一致性的边界条件做了处理 ：
87+ 以下为核心降级代码。M3 使用并发原子类处理了部分并发状态，但这只能保证对应变量或单次操作的原子性，不能证明 Redis、本地缓存和数据库回源组成的整条链路线程安全或一致。缓存击穿、重复回源和旧值覆盖仍要通过同步协议、限流以及并发测试验证 ：
8888
8989![ 核心降级代码：使用并发原子类保障多级缓存操作的线程安全] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/degradation-code-atomic.png )
9090
91- M3 交付的不只是降级代码，还附带了一套测试用例——覆盖了正常降级路径、异常回退路径以及并发竞态场景。降级策略的逻辑覆盖达到 100%，用例结构工整。经调试与验收，编译通过、单测全绿 ：
91+ M3 同时生成了覆盖正常降级、异常回退和并发竞态的测试。截图显示相关用例编译通过、单测全绿；“ 100% 逻辑覆盖”只代表被统计代码的覆盖率，不能证明所有故障场景都已验证 ：
9292
9393![ M3 附带的测试用例：覆盖正常降级、异常回退和并发竞态，编译通过、单测全绿] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/test-cases-all-pass.png )
9494
@@ -98,7 +98,7 @@ M3 交付的不只是降级代码，还附带了一套测试用例——覆盖
9898
9999![ Addy Osmani《Don't Outsource the Learning》核心观点：工具不会替你学习，区别在于你的使用方式] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/addy-osmani-dont-outsource-learning.png )
100100
101- 回到本次事故。故障排查和降级止血是第一步，但如果不深入 SCAN 的底层实现，很多细节容易被忽略：SCAN 是如何对 dict 字典进行遍历的？count 设为 10 是否意味着只遍历 10 个元素？rev 二进制翻转在游标推进中到底起什么作用？这些问题靠读文档回答不了。所以我换了一种方式：借助 MiniMax M3 辅助复刻 Redis SCAN 的核心算法，从源码层面搞清楚 SCAN 在 dict 上的扫荡机制。正好我的好友 sharkchili 在维护 mini-redis 这个开源项目（一个用 Go 复刻 Redis 核心功能的学习型项目），我直接拉取其代码分支进行复刻 。
101+ 回到本次事故。故障排查和降级止血是第一步，但要理解 ` SCAN ` 如何遍历 dict、 ` COUNT ` 的真实含义，以及 rev 二进制翻转如何推进游标，还得继续读文档和源码。官方文档已经说明 ` COUNT ` 只是工作量提示，源码则能解释具体版本如何实现。我借助 MiniMax M3 复刻 ` SCAN ` 的核心算法，再把结果放进好友 sharkchili 维护的 mini-redis 学习项目中验证 。
102102
103103为了提供充足的上下文，我直接将 Redis SCAN 相关的源码文件通过 add-dir 传入 mini-redis 项目：
104104
@@ -112,7 +112,7 @@ M3 交付的不只是降级代码，还附带了一套测试用例——覆盖
112112
113113![ M3 主动发起需求澄清，确认复刻 SCAN 指令的范围] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/m3-clarify-requirements.png )
114114
115- 第二点是算法选型， M3 在扫描项目代码时发现， mini-redis 复刻了 Redis 的 dict 数据结构（而非直接使用 Go 原生 map）。基于这一发现，M3 推荐完整复刻 Redis 的 SCAN 游标实现——在已有 dict 的基础上做游标推进，保证了 SCAN 底层迭代的基调与 Redis 一致：同样的哈希桶遍历顺序、同样的内存局部性。如果另起一套独立的 map 做 SCAN 扫描，不仅增加非必要工作量，内存局部性也无法保证，迭代效率会明显下降 ：
115+ 第二点是算法选型。 M3 发现 mini-redis 已经复刻了 Redis 的 dict 数据结构，而不是直接使用 Go 原生 map，于是建议在现有 dict 上复刻游标推进。这能保留 Redis 算法的主要行为和学习价值。至于哈希桶顺序、内存局部性和性能是否一致，还取决于 Go 实现的数据布局和运行时，不能直接由数据结构名称推出 ：
116116
117117![ M3 推荐完整复刻 Redis SCAN 游标实现，基于已有 dict 而非另起 Go map] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/algorithm-selection-dict-vs-map.png )
118118
@@ -128,7 +128,7 @@ M3 交付的不只是降级代码，还附带了一套测试用例——覆盖
128128
129129![ M3 生成的 SCAN 实现代码结构：覆盖 match、count 参数解析和游标循环逻辑] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/scan-implementation-code.png )
130130
131- 通过这次复刻结合代码注释，我很直观地看到了 SCAN 的一些容易踩坑的细节——例如 dictScan 在扫描时会将实际遍历的桶数量扩大到 count × 10，以避免因非命中桶过多导致单次返回数量不足 ：
131+ 通过这次复刻结合代码注释，我看到了 ` SCAN ` 的一个实现细节：当前 Redis 源码在 ` scanGenericCommand ` 中将 ` count × 10 ` 设为最大迭代次数，用于限制稀疏哈希表上的单次工作量。它不是把“实际遍历桶数量固定扩大十倍”，也不保证凑够 ` COUNT ` 个返回值 ：
132132
133133![ dictScan 将实际遍历桶数量扩大到 count × 10 的细节] ( https://oss.javaguide.cn/github/javaguide/ai/coding/m3/dict-scan-count-detail.png )
134134
@@ -176,16 +176,14 @@ M3 交付的不只是降级代码，还附带了一套测试用例——覆盖
176176
177177## 小结
178178
179- 回顾这次完整闭环：从一个线上故障的表象截图出发，用 M3 完成了三件事——链路推理与根因定位、 Redis SCAN 核心算法的跨语言复刻、以及一套前后端联动的监控面板搭建。
179+ 这次用 M3 做了三个任务：分析 Redis 连接池故障、把 ` SCAN ` 游标算法从 C 复刻到 Go，以及搭建 Redis 监控面板。真正值得保留的是任务证据和暴露出的边界：
180180
181- 三个环节分别考验了模型的不同能力：
182-
183- 1 . 故障排查：长链路推理和多维度方案覆盖（数据结构 + 原子性 + 降级 + 监控，一个 prompt 下覆盖代码、架构、可观测性三个视角）
184- 2 . 底层复刻：跨语言上下文理解和代码实现的精准度（比如识别出项目复刻了 dict 而非使用 Go map，以及 Go 的 ` ^ ` 语义区分对算法的影响）
185- 3 . 监控面板：前后端全链路架构设计和完整交付能力（从采集层到缓冲层再到展示层，包括环形缓冲区的数据结构设计）
181+ 1 . 故障排查时，它给出了数据结构、原子性、降级和监控等候选方向，但对 ` SCAN ` 阻塞机制的最初解释不准确。
182+ 2 . 底层复刻时，它识别出项目使用了自研 dict，并区分了 Go 中 ` ^ ` 的异或与取反语义；实现仍要靠源码和测试验证。
183+ 3 . 监控面板覆盖了采集、缓冲和展示层，但环形缓冲区等设计取舍没有经过充分论证。
186184
187185在 Redis SCAN 从 C 到 Go 的复刻中，M3 识别出项目复刻了 dict 而非使用 Go map，并在此基础上推荐完整复刻 SCAN 游标；Go 语言 ` ^ ` 运算符兼具异或和取反两种语义，这部分也做了逐行区分。
188186
189187而在监控面板场景中，M3 暴露了一个值得注意的边界：from-0-to-1 阶段，它给出的架构选择是“能跑的稳妥方案”而非“经过权衡的最优方案”。以环形缓冲区为例，为什么是环形缓冲区而不是无锁队列？缓冲区满了覆盖最旧数据在高 QPS 下会不会丢关键指标？这些决策点 M3 默认了一个标准答案，没有主动提出 trade-off。如果开发者不具备相关领域的知识储备，就没法在头脑风暴阶段完成最佳方案决策——最终拿到的只是一个“能跑”的原型，而非“设计合理”的原型。
190188
191- 所以，还是回到 Addy Osmani 的观点—— 工具不会替你学习。M3 生成了降级代码和 rev 算法，但如果不去读源码、不理解 count × 10 的设计意图，这些知识就留不在脑子里。AI 是加速器，但底层思维和工程判断力必须由自己完成 。
189+ 这也回到了 Addy Osmani 的观点： 工具不会替你学习。M3 生成了降级代码和 rev 算法，但模型对 ` SCAN ` 阻塞和 ` count × 10 ` 的解释仍需要文档、源码和压测来校正。对我来说，这次实测的价值就在这里——它能加快阅读和实现，工程结论仍要自己验 。
0 commit comments