Blog

关于逆向项目的一些想法

2026年6月12日 · 约 6 分钟阅读

继上一次爬虫架构设计的博客记录，回顾写一写当时做逆向项目的一些经历和感受。肯定没有当时那样的心情了，但还是想把一些想法记录下来，算是对这个项目的一个总结和反思。

为什么想写这篇

最近看到不少分享逆向的文章，感觉挺有意思，也想记录一下自己在做这类项目时的一些想法和体会。这个项目还是比较典型的逆向项目，涉及到代码分析、参数破解、请求模拟、数据处理等多个环节。也是AI协助下的一种风口和未来趋势，虽然AI不能完全替代人工判断，但确实能加速很多分析和调试的过程。

背景

某游戏大厂的虚拟物品交易平台。需要从这个平台上获取一些数据，但官方没有提供公开的API接口。所以只能通过逆向分析前端代码和网络请求，来找到合适的接口和参数，再模拟请求获取数据。接口返回的数据分成两部分：一部分是基本的列表数据，另一部分是需要额外请求才能拿到的详细数据。 js的代码是经过混淆的，参数生成也比较复杂，涉及到一些加密和动态生成的逻辑。

标注：这篇博客不粘贴代码，只使用文字的方式来描述分析和思考的过程，避免泄露任何敏感信息（🐶狗头保命）。

先聊聊开始前的准备和事项

使用的浏览器 Network，看 XHR 、 Fetch、resource，进行断点调试，分析。再分析请求参数、Headers、Cookie、响应结构。尝试请求接口，看看能不能拿到数据。分析 JavaScript 代码，找到请求相关的函数，看看参数是怎么生成的，是否有加密、混淆、动态生成等。

关键点：

请求的大致流程
解密放在哪个环节
需要哪些参数，参数是怎么生成的，有没有解密方法

可以先对请求附近的函数入手，虽然被加密，整体逻辑还是可以拎得清楚的。探查逻辑后，对关键函数进行断点。全局搜索可疑函数。最先知道的应该是解密函数，找到它的调用关系，看看它的输入输出是什么。也可以在请求的过程中，在控制台打印一些参数，调用方法，看看它们的变化。

开始

总计耗时三天，第一天主要是分析请求，参数，熟悉请求流程和代码，第二天主要是分析代码和找到解密方法，第三天主要是把请求流程跑通。

第一天不用急着找解密逻辑，先把请求流程摸清楚，得先了解项目，为什么要加密，加密的目的是什么？

只是为了防止被爬
还是保护数据
还是为了压缩数据大小以方便传输

如果是第三种，只是为了方便传输，那么解密方法可能就是一个简单的压缩算法，或者是一个常见的加密算法，可能在网上就能找到相关的解密方法。需要注意的就是前后会有一些步骤，是否需要配合渲染流程，进行一些前置处理，或者是后续的处理。

逆向不只是找接口

很多时候，逆向项目的第一步确实是抓包。

但这只是开始。

真正麻烦的地方往往在后面：

参数是不是动态生成的
Token 是否有时效
Cookie 是否会失效
请求频率是否有限制
数据结构是否会变化
失败任务能不能恢复

先跑通一次流程，后续的流程会很快

项目里最考验人的地方

我觉得逆向项目里最考验人的，不是某一次成功请求。

而是你能不能把它从“脚本”做成一个能运行的系统。

比如：

失败要能重试
账号要能管理
Cookie 要能维护
请求要控制频率
数据要能落库
异常要能被发现
任务要能继续跑

这些东西看起来不如破解一个参数酷，但它们才决定项目能不能真正用起来。

GPT 能帮忙，但不能替你判断

现在做这类项目，AI 工具确实能帮很多忙。

它可以帮你分析代码片段，解释混淆逻辑，整理调试思路，甚至帮你把 JavaScript 逻辑改写成 Python。甚至可以将加密的数据给AI看一下，确定加密的类型，或者帮你分析加密算法的逻辑。

但它也有局限。

它不知道真实请求环境，不知道站点当时的状态，也不知道你的 Cookie、代理、网络和账号到底发生了什么。

所以最后还是要自己判断。

AI 可以加速排查，但不能代替现场判断。同理，AI 也会犯错。

写在末尾

逆向项目很容易让人沉迷在某个技术细节里，非常容易上瘾。

但值得沉淀的，不是某一次参数破解成功，而是过程中形成的分析方法和工程意识。

技术会变，接口会变，规则也会变。

但观察问题、拆解问题、验证问题的能力，会一直留下来。

Vibe Coding 一段时间后，我的一些新感受

2026年6月10日 · 约 5 分钟阅读

Vibe Coding 又用了有一段时间。

一开始接触它的时候，更多是新鲜感。看到 AI 能读项目、改文件、跑命令、修问题，会觉得这东西多少有点离谱。

但用久一点之后，新鲜感会慢慢退下去，剩下的就是一些更真实的体感。

它确实提高了效率。

但它也不是魔法。

它让开发变快了

以前做一个功能，很多时间会花在重复劳动上。

比如找文件、改样式、补类型、处理小 bug、跑构建、看报错。

这些事情不难，但很碎。

碎事情多了，人就容易烦。

Vibe Coding 最大的变化，是它把这些碎事情接过去了一部分。很多时候，我只需要描述清楚目标，它就可以帮我把第一版做出来。

这带来的不是简单的“少写几行代码”。

而是反馈变快了。

以前一个想法可能要等自己慢慢写完，才能知道效果行不行。现在可以更快看到一个版本，然后再判断它是不是对。

这点很重要。

因为很多想法不是想出来的，是做出来之后才知道哪里不对。

但快不等于稳

AI 写代码很快。

有时候快得让我有点不放心。

它会非常自信地修改文件，也会非常自然地补一些它认为合理的逻辑。

问题是，它的“合理”不一定等于我的“合适”。

比如一个页面，它可能会加很多解释文案，让功能看起来更完整；但我的博客更适合保持安静、简洁。

比如一个样式，它可能会顺手加背景、卡片、动效；但我可能只需要一个很轻的交互反馈。

所以用 Vibe Coding 越久，我越觉得验收很重要。

不是它写完就结束了。

而是它写完之后，我要重新看一遍：

有没有改过头
有没有偏离原来的设计
有没有引入不必要的复杂度
有没有破坏已有习惯
有没有只是“看起来很努力”

有时候 AI 的代码没错，但气质不对。

这就需要人来判断。

上下文比提示词更重要

以前我会觉得提示词很重要。

现在我觉得，上下文更重要。

一个项目里已经有自己的结构、命名、样式、内容风格和取舍习惯。如果 AI 不理解这些，它就很容易写出一个“能跑但不像这个项目”的东西。

所以我现在更愿意先让它读代码。

先看现有文件。

先理解已有逻辑。

再让它动手。

这和人接手项目其实是一样的。一个靠谱的人不会上来就重构，他会先看看这个项目原来是怎么长出来的。

AI 也一样。

给它足够的上下文，它会更像协作者。

不给上下文，它就更像一个手很快的陌生人。

人的判断没有变少

Vibe Coding 用得越多，我越不觉得人会变得不重要。

相反，人要负责的东西变得更靠前了。

以前我主要关心“怎么实现”。

现在我更多关心：

要不要做
做到什么程度
放在哪里合适
会不会影响长期维护
这个功能是不是符合产品气质

AI 可以帮我往前推，但方向还是要自己定。

如果方向不清楚，AI 只会更快地把混乱实现出来。

这也是我最近很明显的感受：Vibe Coding 不是让人不用思考，而是把思考的位置往上抬。

以前卡在代码细节里。

现在卡在产品判断里。

听起来好像还是会卡。

但卡得高级一点。

它也会制造整理需求

还有一个很现实的问题：AI 参与越多，项目越需要规则。

比如文件怎么命名，文章放哪里，数据抽到哪里，样式怎么复用，哪些信息不能写进仓库。

如果这些规则不清楚，AI 每次都会根据当下情况做一个“看起来可以”的选择。

短期没问题。

长期就会慢慢乱。

所以我最近反而更重视项目规范。

比如博客按年份月份归档，URL 用 slug 固定；友链和技术栈抽到 data；部署信息用 .env；新增文章用脚本生成。

这些事情看起来不酷。

但它们能让 AI 更好地工作，也能让未来的自己少骂几句过去的自己。

最后

现在再看 Vibe Coding，我已经不太把它当成一个炫技词了。

它更像一种新的工作方式。

不是我把所有事情交给 AI。

而是我负责目标、边界、判断和验收，AI 负责承担大量具体执行。

这个分工如果配合得好，效率确实会高很多。

但如果人自己没想清楚，它也会很快把问题放大。

所以我现在对 Vibe Coding 的感受很简单：

它不是让开发变得不用动脑。

它是让开发者必须更清楚地知道，自己到底想要什么。

决策会变得越来越重要。

第一次迁移生产服务器

2026年6月7日 · 约 3 分钟阅读

好消息，服务器迁移完成了。

坏消息，迁移服务器花了近四小时。这要是生产停机迁移，这不事不得凌晨干。

但我没有，这是一次停机的迁移…

这还是我第一次遇到服务商要跑路。有一说一，机器很稳，也会提前30天发公告，如此的一家服务商就这样没了，挺可惜的，我倒是希望你活下去。

以前总觉得服务器迁移这种事离我挺远，直到通知的时候，才发现：哦，倒霉事落到我身上了。

搬了什么

这次主要迁移的是一些 Web 服务、数据卷。

大部分都跑在 Docker 里，包括：

cpa
new-api
博客
PostgreSQL
Redis
Nginx
SSL 证书

需要备份data volume，重新部署 Docker Compose，重新配置 Nginx，重新申请 SSL 证书。

每一层看起来都不复杂，但它们连在一起，就开始有点会折磨人了。

没经验，所以慢

这次耗时比较长，主要还是因为没什么服务器迁移经验。

平时部署一个服务还好，看文档，用docker-compose。

但迁移不一样。

迁移是你要先把旧环境拆开，再在新环境里重新拼起来。

比如 Docker volume 看起来恢复了，但数据库不一定真的恢复对了。

Nginx 配置看起来写了，但请求不一定真的进了你想要的 server block。

SSL 证书看起来签了，但域名不一定都覆盖到了。

这几个“不一定”，加起来就是一个下午。

Nginx 是这次的重点嘉宾

整个过程中最让我头大的还是 Nginx。

主域名访问时，一直出现 nginx welcome page。

二级域名访问却没问题。

这个页面真的很神奇。

就是这个熟悉的家伙：

/etc/nginx/sites-enabled/default

删掉默认站点，再 reload Nginx，主域名才终于正常。

这件事给我的感觉就是：有时候不是你没配置，而是有默认配置。

GPT 也会帮倒忙

这次迁移过程中，我也一直在让 GPT 帮我看问题。

它确实很有用。

尤其是排查方向、解释报错、整理命令的时候，可以节省不少时间。

但它也会帮倒忙。

比如有些时候，它会默认你的服务器结构是标准的。

但实际情况是：你的服务器可能有 conf.d，也可能有 sites-enabled，还可能有 certbot 自动生成的配置。

它说得很有道理。

但是服务器情况不一定是gpt说的那样。

所以最后还是要自己去看：

nginx -T

真实配置永远比想象中的配置重要。

最后还是跑起来了

折腾了几个小时后，服务终于都恢复了。

博客可以访问，new-api 正常，cpa的数据没丢，统计服务也能起来，主域名和二级域名都能用，SSL 证书也处理好了。

那一刻没有什么特别激动的感觉。

更多是松了一口气。

这次的收获

这次最大的感受是：

时间的流逝，非常快。折腾一会，几个小时没了。

需要树立工程意识，迁移服务的环节流程需要熟悉，才能避免踩坑。要有自己的判断，不能轻易全部的交给 GPT。

服务器迁移不是单纯的搬数据，更是一个重新搭建环境的过程。每个单独的docker容器挂在的数据卷。在备份项目和数据卷的时候注意有没有嵌套的卷。运维也不容易…

AI 编辑器工具的一点观察

2026年6月1日 · 约 5 分钟阅读

最近一直在想一类工具。

类似 Cursor 这样的 AI 编辑器工具平台。

从去年开始，市面上出现了很多新的编辑器产品。它们大多不是从零开始做一个全新的 IDE，而是选择基于开源的 VS Code 平台继续往上搭。

这个选择其实很现实。

VS Code 已经有成熟的编辑体验、插件生态、终端、调试、文件管理和开发者习惯。重新做一套编辑器，成本太高，也很难让开发者迁移。

所以大家更愿意站在 VS Code 的基础上，把真正的差异放到 AI 能力上。

VS Code 成了底座

我用过一些类似工具，比如腾讯的 CodeBuddy、阿里的 Qoder，还有字节的 Trae。

它们给人的第一感觉都很熟悉。

因为底层体验都绕不开 VS Code。

文件树、编辑区、终端、快捷键、插件习惯，这些东西不用重新教育用户。开发者打开之后，不会有太强的陌生感。

所以现在这类工具的竞争，已经不太是“谁更像一个编辑器”。

大家的地基差不多，真正的差异开始出现在 AI 层：

谁能更好地理解项目。
谁能更稳地修改多文件。
谁能把任务拆得更清楚。
谁能在执行过程中少犯错。
谁能把结果验证到位。

这些问题，开始比传统编辑器功能更重要。

差异点变成 Agent

每个平台都会有自己想强调的 Agent 能力。

比如阿里的 Qoder，有“专家执行团”这种偏多角色协作的设计。

Trae 里也有 Solo 这种更偏独立执行任务的模式。

这些名字背后，其实都在回答一个问题：

AI 到底应该以什么方式参与开发？

是作为一个回答问题的助手？

还是作为一个能拆任务、改代码、跑命令、检查结果的执行者？

我感觉现在的趋势很明显：大家都不满足于“问答式 AI 编程”了。

单纯聊天已经不够。

开发者真正想要的是：

我给你一个目标，你能不能理解项目，然后一步步把事情做完？

这就是 Agent 开始变重要的原因。

从补全到执行

最早 AI 编程给人的印象，更多是代码补全。

写一半，它补一半。

后来变成 Chat。

你问它一个问题，它回答你一段解释，或者给一段代码。

现在越来越多工具在往执行系统走。

也就是：

读项目 -> 理解需求 -> 修改文件 -> 运行检查 -> 根据结果继续调整

这个变化很大。

因为它改变的不只是“写代码速度”，而是开发流程本身。

以前 AI 像是一个在旁边回答问题的人。

现在它开始像一个能参与工作的协作者。

当然，这并不意味着可以完全放手。

Agent 越强，人越需要判断方向。

它可以帮你做很多具体事情，但你仍然要知道目标是什么、边界在哪里、什么东西不能乱改、结果是否真的符合需求。

移动端成为新入口

最近还有一个新的趋势：很多平台开始推出移动端。

这件事挺有意思。

以前开发工具基本都绑定在电脑上。哪怕是 AI 编辑器，本质上也还是一个桌面工作台：打开项目、读文件、改代码、跑命令。

但移动端出来之后，入口变了。

它更像是把 Agent 从编辑器里拆出来，放到一个随时可以对话的地方。

有些未完成的工作，或者临时想到的事情，不一定非要坐到电脑前才能处理。

比如：

路上想到一个需求，让 Agent 先整理方案。
临时发现一个 bug，让 Agent 先定位可能原因。
让它继续某个没做完的任务。
让它总结项目状态。
让它根据上下文生成一个待办清单。

这时候手机不是用来完整开发的。

它更像一个轻量入口。

真正的执行可能还是在云端、远程环境或者本地项目里完成，但人和 Agent 的交互，不再必须发生在电脑前。

这会让 AI 编程工具从“编辑器产品”继续往“工作流产品”走。

桌面端负责深度开发，移动端负责随时调度。

平台竞争的核心

我觉得这类工具后面的竞争，可能不只是模型本身。

模型当然重要。

但真正拉开差距的，可能还有这些东西：

上下文组织能力。
项目索引能力。
多文件修改能力。
终端和测试集成。
Agent 任务规划。
错误恢复能力。
UI 和交互设计。
对开发者工作流的理解。

如果只是接入一个模型，其实很容易被复制。

但如果一个工具能把模型、编辑器、终端、文件系统、Git、测试和任务流整合得很顺，那它就会变成真正的平台。

这也是为什么大家都在做自己的 Agent。

模型是发动机，但工具平台决定这辆车怎么开。

我自己的判断

用这些工具的时候，我有一个很明显的感受：

它们都还在快速变化。

有些时候很惊艳，一个任务丢进去，它可以读项目、改文件、跑检查，最后给出还不错的结果。

有些时候也会很狼狈，改一半跑偏，理解错上下文，或者给出看似完整但实际没验证过的结果。

所以我现在更愿意把它们看成一种新的工作流，而不是一个稳定成熟的终点。

它们正在把开发者从“每一行都自己写”推向“定义目标、审查过程、把控结果”。

这和我之前接触 Vibe Coding 的感受也能连起来。

AI 工具越强，人的角色越往上移。

不是不写代码了，而是不再只盯着代码本身。

如果移动端这个方向走通，开发者和工具的关系会再变一次。

以前是：

我打开编辑器，然后开始工作。

以后可能会变成：

我想到一个任务，先丢给 Agent，让它继续推进。

这也是为什么移动端值得关注。

它不一定是为了在手机上写代码，而是为了让 AI 参与工作的入口变得更随身。

下一个 AI 编辑器工具平台会是什么样子？

从对话到主动编辑，现在把 Agent 装进口袋，下一个阶段呢？

我觉得它可能不只是更聪明的聊天窗口，也不只是更强的代码补全。

AI 编辑器正在从“写代码的工具”，变成“管理开发过程的入口”。

如果说过去的编辑器是人操作代码的地方，那么下一代 AI 编辑器，可能会变成 Agent 和人一起推进项目的地方。人不再只是盯着每一行代码，而是更多地定义目标、判断方向、确认结果。

六一这天，云服务商给我开了个玩笑

2026年6月1日 · 约 3 分钟阅读

六一这天，云服务商给我开了个天大的玩笑。

AI爆发，硬件暴涨，云服务商的成本也在暴涨，撑不住的已经倒下。这股风也吹到了我这里。

怎么说呢。

儿童节，成年人收到的是服务器搬家通知。

服务商还是比较良心，提前30天发布了公告。

博客搬家

接下来这段时间，我会把博客迁移到新的服务器上。

迁移后域名仍然保持不变：

blog.veyliss.top

所以已经添加友链的伙伴，不需要修改链接。

如果中途出现短暂无法访问、解析异常、证书刷新、服务重启之类的问题，也不要惊慌。

不是我跑路了。

是我的服务器先跑路了。

最后

这次也算给我提了个醒：个人博客看起来只是一个小站，但只要还在持续更新，它就不是随手放在那里的页面。

域名、服务器、证书、备份，这些平时不太显眼的东西，也在支撑它继续跑下去。

总之，友链伙伴如果发现本站偶尔打不开，不用紧张。

我还在。

只是服务器在搬家。

七年后和初中同学小聚

2026年5月31日 · 约 4 分钟阅读

周六，和初中一位同学小聚了一下。

算起来，这是七年后第一次见面。

时间过得真的很快。快到有时候会觉得，中间这些年像是被按了快进键。以前还在同一个教室里上课，后来各自读书、工作、生活，再见面的时候，已经隔了这么久。

但很奇妙的是，有些人很久不见，再坐下来聊天，也不会觉得完全陌生。

只是大家身上都多了一些时间留下来的东西。

聊到 AI

他是动漫专业的。

我们聊着聊着，很自然地就聊到了 AI。

聊到 AI 对行业的冲击时，能感觉到那种复杂的情绪。

一方面，AI 确实很强。图片生成、视频生成、分镜、角色设计、动作参考，这些东西正在变得越来越快。很多过去需要大量时间打磨的环节，现在似乎被压缩了。

另一方面，这种强也会让人不安。

不是简单地说“AI 会不会取代谁”，而是整个行业的工作方式正在被改变。学了很多年的技能，突然要面对一个速度极快的新工具，这种感觉并不轻松。

聊这些的时候，我也会想到自己的行业。

IT 这边其实也一样。

代码生成、Agent、自动化测试、需求分析、文档总结，AI 也在一点点进入开发流程。它不是停在旁边给建议，而是开始坐到工作台上，参与具体的产出。

所以我们虽然专业不同，但聊到 AI 的时候，感受是相通的。

大家都在面对同一个问题：

当 AI 开始参与创作和工作，我们到底应该怎么重新理解自己的能力？

聊了很多

那天聊了很多。

聊学习，聊生活，聊以前的同学，也聊未来。

有些话题其实很普通，但因为很久没见，反而显得珍贵。

我们会聊以前谁去了哪里，谁现在在做什么，也会聊这些年自己经历了什么。很多事情说出来的时候，好像只是几句话，但背后其实已经走过很长一段路。

我发现，和老同学聊天有一种特别的感觉。

老同学知道我很早之前的样子。

不是现在这个写代码、做项目、折腾博客、学习 AI 的我，而是更早一点、更青涩一点的我。

所以重逢时，会有一种时间被拉开的感觉。

我能从对方身上看到过去，也能从彼此现在的状态里看到这些年各自的变化。

生活不是支线

回来的时候，心里有一点感慨。

这段时间我好像一直在写技术、折腾项目、看 AI、做博客。

这些东西当然重要。

但那天和同学坐下来聊天，突然又觉得，生活本身也很重要。

很多时候，我们会把生活当成技术之外的“空白时间”。写完代码，修完 bug，部署完服务，学习完一个概念，剩下的才叫生活。

但其实不是。

生活不是支线。

它不是等工作和学习都完成后才出现的东西。

和朋友见面，聊一些没有明确产出的事情，回忆过去，想想未来，这些也都是很重要的部分。

小结

这次小聚没有什么特别宏大的主题。

就是七年后见了一位初中同学，聊了很多，也感受到 AI 对不同行业都在产生影响。

动漫也好，IT 也好，大家都在重新适应这个变化很快的时代。

最后还是想感叹一句：

IT 除了代码，还有生活。

技术会一直往前走，项目也会继续做，AI 也会越来越强。

但人不能只活在代码里。

偶尔见见老朋友，聊聊过去和以后，也挺好。

做 AI 本地优先知识库三个月后，我发现 RAG 没那么简单

2026年5月29日 · 约 5 分钟阅读

上周基本都在更新我的 AI 本地优先知识库。

说是更新，其实更像是把一个放了一个多月的项目重新捡起来，拍掉灰，再试着往前推几步。

从发布到现在，差不多快三个月了。

项目地址是：veyliss/ai-localbase。

Star 到了 300+。这个数字说大不大，说小也不小。对一个个人项目来说，能被三百多人点一下星，已经说明它至少击中过一小部分人的需求。

但我也很清楚，中间有一个多月没怎么更新，所以 Star 涨得慢下来也很正常。

开源项目有时候像一条很细的火线。你持续更新，它就偶尔亮一下；你停下来，它就慢慢变暗。不是项目突然没价值了，而是互联网上每天都有太多新的东西流过去。

还是 Demo

重新看这个项目的时候，第一感觉是：

它还是一个 Demo。

不是不能用，也不是只有一个空壳。

它已经能跑起来，方向也比较明确：本地优先、知识库、AI 问答、RAG、个人数据掌控。

但离“一个成熟产品”还有距离。

Bug 还不少，体验也不算很好。有些流程能走通，但不够顺。有些功能看起来有了，但真的连续使用时，边角问题会一个个冒出来。

这也是个人项目很真实的一面。

发出来的时候，更多是在表达一个想法：

我想做一个本地优先的 AI 知识库。

但真正要让别人舒服地用起来，靠一个想法远远不够。

补了一些体验

这次回来更新，主要做了两件事：优化 UI，优化检索。

UI 的问题比较直观。一个工具能不能让人继续用下去，很多时候不是取决于它有没有某个大功能，而是打开之后顺不顺、清不清楚、有没有那种“我愿意继续点下去”的感觉。

检索就更核心了。一个知识库项目，如果检索不准，后面 AI 回答再漂亮也没有意义。

RAG 的链路里，LLM 往往是最显眼的部分，但真正影响回答质量的，很多时候是前面的检索。

这也是我这几天最明显的感受：

RAG 不是接一个模型，再塞一点文档，就自然变聪明。

RAG 比想象中难

真正做起来才发现，RAG 的难点不只在“调用大模型”。

模型只是最后一步。

前面还有一整套不太显眼、但很要命的链路：

文档怎么解析。
内容怎么切分。
怎么向量化。
怎么检索。
怎么重排序。
怎么拼上下文。
怎么让答案有依据。

以前看 RAG 的概念图，会觉得它很清晰：

用户问题 -> 检索资料 -> 交给模型 -> 生成答案

但真正落到项目里，它就不是一条那么干净的线了。

文档内容可能很乱，切分可能切断语义，向量检索可能召回不准，模型可能忽略上下文，回答可能没有引用依据。这些问题不会在 Demo 截图里出现，但会在真实使用里一点点暴露。

也正因为这样，我越来越觉得 RAG 是一个工程问题，不只是一个 AI 概念。

本地优先和现实

这个项目一开始很强调本地优先。

我很喜欢这个方向。

知识库本来就带有很强的个人属性。笔记、文档、想法、项目资料，这些东西放在本地，用户自己掌控，会让人更安心。

所以最开始我很自然地选择了 Ollama。

本地模型、本地运行、本地数据，听起来非常完整。

但现实很快给了我一巴掌。

太慢了。

在普通机器上，本地模型的体验并不好。回复一次两次都很勉强，更不用说连续对话、长上下文、知识库检索之后再生成回答。

本地优先的理念是好的，但如果体验慢到让人不想继续用，那它就会从“安全感”变成“阻力”。

这件事让我重新思考一个问题：

本地优先是不是等于只能使用本地模型？

后来我觉得，不一定。本地优先更重要的是数据和控制权。用户的数据应该尽量保存在本地，知识库应该由用户自己掌控，项目不应该强绑定某个平台。

加入 API 接入

后面我加入了 API 接入能力。

这样项目不再只依赖 Ollama，也可以接入市面上很多模型。

这不是放弃本地优先，更像是给项目留出两个出口：

想要完全本地，可以走 Ollama。
想要更好体验，可以走 API。

我现在更愿意把它理解成：

数据本地优先，模型选择开放。

这个取舍比一开始更现实，也更接近一个工具真的要被使用时的样子。

知识储备不太够

这几天还有一个很强烈的感受：自己的知识储备还不太够。

以前以为做一个 AI 知识库，重点是把产品形态搭起来。现在发现，产品形态只是外壳。里面真正难的是检索、向量化、上下文组织和回答质量。

向量化这块尤其明显。Embedding 模型怎么选？中文效果怎么样？切片多大合适？什么时候只用向量检索，什么时候要结合关键词检索？要不要重排序？

这些问题都不是一句“接入向量数据库”就能解决的。它们需要实验，也需要积累。

我现在还在补这些东西。

三个月后的状态

所以，如果给这个项目现在的状态做一个描述，我会这样写：

方向是对的，但还不够好用。

它已经证明了一些事情：

本地优先知识库是有需求的。
AI 问答和个人知识库结合是有吸引力的。
但体验、速度、检索质量和稳定性都还需要继续打磨。

Star 300+ 当然让我开心。

但我也知道，Star 不是产品成熟的证明。

真正的证明是：有人能把它装起来，导入自己的资料，连续用几天，还愿意继续打开。

这比 Star 更难。

继续往前

写到这里，感觉这不是一篇项目总结，更像是给自己留的一张便签。

提醒自己不要被概念骗得太轻松。

RAG 很热，本地优先也很好听，AI 知识库也很有想象空间。

但真正做起来，还是那些很具体的东西：

一个按钮是否清楚。
一次检索是否准确。
一段回答是否有依据。
一个模型是否太慢。
一个新用户能不能顺利跑起来。

这些东西不酷，但它们决定项目能不能从 Demo 往前走。

项目现在还不成熟。

但至少，它还在往前。

这几天重新更新它的时候，我又找回了一点刚开始做它时的感觉：不是很确定，但挺想继续看看它能长成什么样。

软考高级架构师考试后的一个感受

2026年5月24日 · 约 5 分钟阅读

昨天，也就是 2026 年 5 月 23 日，去参加了软考高级系统架构设计师考试。

考完之后最明显的感受是：这类考试真的在越来越快地贴近新的技术趋势。以前提到架构，更多想到的是分层、缓存、消息队列、高并发、数据库、微服务这些传统工程问题；但这次做题时，AI、模型、多模态这些内容已经很自然地出现在题目里了。

这种感觉还挺直接的。

不是那种“AI 作为热点，被强行塞进试卷”的感觉，而是它开始变成架构师应该了解的背景知识之一。

选择题：整体还可以

上午选择题做下来，感觉整体还可以。

时间上比较充裕，没有那种一路卡住、最后疯狂赶题的感觉。很多题还是围绕软件工程、架构设计、数据库、网络、安全、项目管理这些基础内容展开，只要平时有积累，大多数题都能比较顺地往下做。

比较有意思的是，题型很快就来到了 AI 和模型相关内容。

印象里有一道和 Transformer 相关的题，也有一道涉及多模态的题。看到这些题的时候，会明显感觉到考试范围已经不只是传统软件架构知识了。

这其实也合理。

现在很多系统已经不只是“业务系统 + 数据库 + 缓存 + 接口”这么简单。越来越多项目会接入大模型能力，可能涉及文本生成、向量检索、多模态理解、智能测试、智能客服、知识库问答等场景。

架构师如果完全不了解这些内容，后面做系统设计时确实会越来越吃力。

案例题：对我来说还是有难度

案例题对我来说还是有一些难。

选择题更多是知识点识别和判断，案例题则更像是把知识放进一个具体场景里，让你分析系统问题、补全架构设计、选择方案、说明理由。

这个部分很考验表达能力，也考验对架构方法的熟练程度。

有时候不是完全不知道，而是知道一些点，但要在有限时间里组织成比较完整、规范、有条理的答案，并不容易。

这也提醒我，备考不能只停留在“看过概念”。案例题需要练的是：

能不能看懂业务场景。
能不能识别系统中的关键矛盾。
能不能把架构方案和问题对应起来。
能不能用比较规范的语言写出答案。

这和实际做架构也很像。真实工作里，知道某个技术名词没有太大意义，关键还是能不能把它放到合适的系统问题里。

AI 含量越来越高

这次考试让我比较在意的一点，是 AI 相关内容的出现频率。

选择题里出现了 Transformer、多模态，论文题里也直接出现了“向量数据库”和“多模态大模型在移动智能测试框架中的应用”。

这说明考试已经不只是把 AI 当成一个新名词，而是在尝试把它放进架构设计语境里。

比如向量数据库不是单独存在的知识点，它背后对应的是：

文本向量化。
相似度检索。
RAG 检索增强生成。
知识库问答。
语义搜索。
大模型应用的数据底座。

多模态大模型也不是简单知道“能处理图片和文本”就够了。它进入移动智能测试框架时，可能会涉及：

UI 截图理解。
测试步骤生成。
异常页面识别。
测试用例自动补全。
文本、图像、操作行为的联合分析。

这些东西已经开始和软件工程、测试框架、系统架构结合起来了。

论文题：四个方向都挺有代表性

这次论文题是四选一，题目大概是：

六边形架构设计。
向量数据库。
论高并发系统设计。
论多模态大模型在移动智能测试框架中的应用。

这四个题其实很有代表性。

六边形架构偏架构思想，重点是领域逻辑和外部依赖的隔离。

高并发系统设计是传统架构高频题，缓存、限流、削峰、异步、分库分表、读写分离、降级熔断这些内容都能展开。

向量数据库和多模态大模型则明显代表新趋势，考察的是架构师能不能把 AI 相关能力纳入系统设计。

如果从稳妥角度看，高并发系统设计可能是很多人比较熟悉的方向。它素材多、案例多，也比较容易结合实际项目经验展开。

但从趋势角度看，向量数据库和多模态大模型这两个题很值得重视。

它们释放了一个信号：以后软考高级架构师可能会越来越多地考察 AI 时代下的软件架构能力。

考完之后的想法

这次考完，最大的感受不是某一道题难不难，而是知识体系真的需要更新。

传统架构能力还是基础。数据库、缓存、消息队列、微服务、高并发、安全、可用性、可扩展性，这些东西不会过时。

但只靠这些已经不够了。

现在还要补上大模型相关的工程知识：

Transformer 的基本概念。
向量数据库和语义检索。
RAG 应用架构。
多模态模型的输入输出方式。
AI 能力如何接入现有业务系统。
模型服务的成本、延迟、稳定性和安全边界。

这些内容不一定都要学到算法研究层面，但作为架构师，至少要知道它们能做什么、不能做什么、适合放在系统里的哪个位置、会带来哪些工程风险。

小结

这次软考高级架构师考试给我的一个提醒是：

架构师的知识边界正在被 AI 拉宽。

选择题里出现 Transformer 和多模态，论文题里出现向量数据库和多模态大模型，这些都说明 AI 已经逐渐进入软件架构的主干知识里。

对我来说，选择题感觉还可以，案例题仍然需要继续练。更重要的是，后面复习和学习时，不能只看传统架构内容，也要把 AI 工程化、大模型应用架构、向量检索和多模态场景补起来。

考试只是一个节点。

真正值得记录的，是它让我看到技术趋势已经走到试卷上了。

大规模无状态爬虫系统设计

2026年5月22日 · 约 9 分钟阅读

这篇文章记录的是一套大规模无状态爬虫系统的设计。

先说明一下参与边界：这套系统不是我一个人独立设计完成的。我主要负责爬虫端的核心设计和实现，另一位同事是项目主要负责人，他有十余年的架构设计经验，整体系统设计、调度中心以及很多关键取舍都由他主导。我在这个系统里更多是站在爬虫端视角，参与了一套大规模无状态爬虫体系的落地。

也正因为那时自己还是初入职场，所以这套设计对我的意义不只是“写了一个爬虫”，而是第一次比较完整地看到：爬虫在工程系统里不应该只是脚本，它可以是一个被调度、被扩容、被监控、可替换的采集节点。

本文只讨论在授权和合规范围内的数据采集系统设计，不涉及绕过站点安全机制或采集敏感数据。

为什么没有继续用 Scrapy

在做这个项目之前，Scrapy 是很自然会被想到的方案。

它有成熟的爬虫生命周期、调度器、下载器、中间件、管道、去重、状态管理等能力。对于中小规模、结构清晰、业务变化不频繁的采集任务来说，Scrapy 确实是一套完整方案。

但这套系统面对的问题不太一样。

我们更关注的是大规模任务下的采集吞吐、任务调度、账号分配、异常处理和快速扩容。Scrapy 自带的体系虽然完整，但学习成本较高，入手较慢，架构也相对复杂。尤其当系统需要把任务状态、账号状态、异常流转、代理分配、补偿处理这些能力统一放到一个调度中心管理时，爬虫本身再保留太多状态，反而会让边界变得不清楚。

所以最后的方向是：不沿用 Scrapy 的架构模式，而是结合现有高并发框架，设计一套更轻、更快、更容易水平扩展的无状态爬虫系统。

爬虫核心只负责一件事：拿到任务后尽快完成数据抓取，包括必要的增量更新，然后把结果交给后续链路。

系统整体结构

按当时的架构草图抽象后，整体链路大概是这样：

大规模无状态爬虫系统架构图 — 任务、账号、代理由调度中心统一下发；爬虫节点保持无状态，采集结果进入 Kafka、Flink、ES 数据链路。

在这个体系里，Java 服务承担调度中心的角色。它负责任务协调、账号分配、账号状态管理、异常状态流转、代理下发等能力。

爬虫端则被刻意设计得很薄。

爬虫启动后向调度中心领取任务。调度中心在下发任务时，会同时给出这次采集所需的账号和代理。爬虫拿到这些一次性上下文后开始采集，采集完成后把数据写入 Kafka，并向调度中心汇报任务结果和心跳状态。

这里的“一次性”不是指账号用一次就丢弃，而是指一次采集任务内绑定一次任务、账号和代理。任务结束后，账号会根据结果重新回到有效账号池，或者进入异常账号池，等待专门的登录模块重新处理。

为什么要让爬虫无状态

我觉得这套系统里最关键的设计，就是把爬虫做成无状态。

传统爬虫经常会在自己内部维护很多信息：当前任务跑到哪一步、账号是否可用、代理是否失效、失败后要不要重试、异常应该怎么处理、下次从哪里继续等。

这些能力当然有价值，但如果所有爬虫节点都各自维护状态，系统规模一大，就会出现几个问题：

单个爬虫节点变重，扩容和迁移成本变高。
账号、代理、任务状态分散在各处，难以统一判断。
某个节点异常退出后，恢复逻辑复杂。
错误处理混在采集逻辑里，爬虫代码越来越难维护。

无状态的思路是反过来的：爬虫只负责执行当前任务，不负责长期持有状态。

它不决定一个账号后续应该怎么处理，也不决定一个异常任务最终怎么补偿。它只把采集过程中的结果、错误和心跳上报给调度中心，由调度中心再调度给对应的处理模块。

这样做以后，爬虫端会变得非常轻。

如果某个爬虫节点挂了，系统只需要感知它心跳消失，再把未完成任务重新调度出去。爬虫本身不需要承担复杂恢复逻辑。对于我当时负责的爬虫端来说，这个设计最大的好处就是：代码目标非常明确，采集就是采集，错误就是上报。

单次任务为什么能做到很快

这套系统里，爬虫单次采集任务大约 15 秒左右就可以完成。

它能快起来，原因不只是“并发写得高”，更重要的是系统边界清楚。

调度中心已经提前准备好了任务、账号和代理，爬虫不需要在执行过程中再做大量决策。拿到任务后，爬虫可以直接进入采集流程。它只处理当前任务所需的请求、解析、增量判断和结果投递。

采集结果进入 Kafka 后，后面的清洗、聚合、存储交给 Flink 和 ES 链路。爬虫不在本地做过多处理，也不会把数据链路和采集链路耦合在一起。

从工程上看，这其实是在减少爬虫节点的职责。

节点职责越少，单次任务越短，失败成本也越低。即使某个任务失败，也可以快速上报并进入调度中心的异常处理流程，而不是让爬虫自己在本地反复纠缠。

为什么用 Docker 部署爬虫

爬虫选择 Docker 部署，是因为这个系统天然需要横向扩容。

如果爬虫直接跑在固定机器上，扩容会比较麻烦。新机器环境要配置，依赖要安装，版本要对齐，启动方式也容易不一致。Docker 把运行环境打包后，爬虫就可以在任意一台机器上快速启动。

这带来了两个非常直接的好处。

第一，可以一键扩容。

当采集任务变多，或者需要在短时间内提高吞吐时，只需要增加爬虫容器数量。因为爬虫是无状态的，新启动的容器不需要同步复杂上下文，只要能连上调度中心，就可以开始领取任务。

第二，可以按数据采集情况动态调整数量。

任务高峰期增加爬虫节点，任务低谷期减少节点。爬虫节点本身不保存长期状态，所以扩容和缩容都比较自然。

这也是无状态设计和容器化部署非常契合的地方：一个节点随时可以来，也随时可以走，系统的长期状态不依赖它。

为什么架构图里没有代理模块

从图上看，可能会有一个疑问：代理池去哪了？

实际设计里，代理也由调度中心负责。

爬虫在领取任务时，调度中心会把任务、账号、代理一起下发。对于爬虫来说，它不需要自己去代理池里挑选代理，也不需要判断某个代理是否还应该继续使用。它只需要使用调度中心给出的代理完成当前任务，并把结果反馈回去。

这样设计的好处是统一。

任务、账号、代理在一次采集里是绑定关系。如果采集失败，调度中心可以结合错误类型判断问题出在哪里：可能是任务本身异常，可能是账号失效，也可能是代理不可用。爬虫端只提供事实，不做最终裁判。

这让异常处理有了更清晰的入口。

账号池和异常流转

账号管理是这个系统里非常重要的一部分。

有效账号池保存当前可用账号。调度中心给爬虫下发任务时，会从有效账号池里分配账号。任务完成后，如果账号表现正常，就重新回到有效账号池，等待后续继续使用。

如果采集过程中发现账号异常，爬虫不会自己尝试修复账号，而是把异常上报给调度中心。调度中心再把账号放入异常账号池，由账号登录模块或专门处理模块去恢复。

恢复成功后，账号重新进入有效账号池；恢复失败，则继续留在异常状态，等待后续处理或下线。

这套流转看起来绕了一步，但它让职责非常清楚：

爬虫负责发现和上报异常。
调度中心负责状态流转和资源分配。
账号登录模块负责账号恢复。
有效账号池只保留可用于任务分配的账号。

当系统规模变大时，这种职责拆分会比“爬虫自己判断一切”更稳。

数据链路：Kafka、Flink 和 ES

爬虫采集到的数据不会直接写入最终存储，而是先进入 Kafka。

Kafka 在这里承担缓冲和解耦作用。爬虫只需要稳定地把采集结果投递出去，不需要关心后续清洗、转换和索引写入的具体细节。

Flink 负责消费 Kafka 中的数据，做实时清洗、转换、去重或补充处理。处理后的数据再写入 ES，供后续检索和查询使用。

这条链路的好处是采集和处理分离。

爬虫节点只追求采集效率，数据处理链路则可以按自己的节奏扩展。如果后续清洗逻辑变复杂，也不会直接拖慢爬虫侧的执行。

设计总结

这套设计对我最大的影响，是让我第一次真正理解“少做一点”有时候是更好的工程设计。

刚开始做爬虫时，很容易觉得爬虫应该什么都管：任务、状态、账号、代理、重试、异常、存储，最好都封装在一个完整框架里。但在大规模系统里，爬虫越重，越容易变成难以扩展的节点。

这套系统反而让我看到另一种思路：

爬虫不需要成为系统中心。它可以只是一个高性能、可替换、可扩容的执行单元。真正的状态和调度逻辑，应该放到更适合统一管理的位置。

对当时初入职场的我来说，这个认知很重要。

我开始意识到，架构设计不是把所有能力都堆进一个模块里，而是决定每个模块应该知道什么、不应该知道什么。一个模块越清楚自己不负责什么，边界往往越稳定。

回头看，这套无状态爬虫体系最让我印象深刻的地方，就是它把复杂性从爬虫端拿走了。

爬虫只领取任务、执行采集、上报结果；调度中心统一管理任务、账号、代理和异常；数据进入 Kafka、Flink、ES 组成的后续链路。每一层都有自己的职责，每一层也都可以独立扩展。

这比单纯写一个“能跑的爬虫”要更接近真正的工程系统。

redis核心原理与实战应用

2026年5月20日 · 约 10 分钟阅读

Redis 常被用作缓存、分布式锁、排行榜、计数器和会话存储。它的核心优势不是“能存数据”这么简单，而是用内存访问、丰富数据结构、持久化和高可用机制，支撑高并发场景下的读写性能与系统稳定性。

这篇文章按实际使用路径整理 Redis：先看基础能力，再看高可用与缓存问题，最后整理一致性、性能优化和典型场景。

一、Redis 基础概念

数据类型支持

Redis 支持多种常用数据结构：

String：适合缓存简单值、计数器、分布式锁标记。
Hash：适合存储对象字段，例如用户信息。
List：适合队列、消息列表、时间线等场景。
Set：适合去重、集合交并差。
Sorted Set（ZSet）：适合排行榜、权重排序、延迟队列。

这些结构让 Redis 不只是一个 Key-Value 缓存，而是可以承接一部分高频读写业务逻辑。

持久化机制

Redis 主要有两种持久化方式：RDB 和 AOF。

RDB（快照）

定期生成内存快照，例如通过 bgsave 命令。
优点：文件体积较小，数据恢复速度快。
缺点：如果 Redis 异常退出，可能丢失最后一次快照之后的数据。

AOF（追加日志）

记录每一次写操作命令，例如 SET key value。
优点：数据安全性更高，可以配置更高频率的落盘。
缺点：文件体积更大，恢复速度通常慢于 RDB。

实际生产中常见策略是 RDB + AOF 组合使用：RDB 用于快速恢复，AOF 用于降低数据丢失风险。

二、主从同步与高可用

主从同步方式

Redis 主从同步分为全量同步和增量同步。

全量同步

通常发生在从节点初次连接主节点，或断线时间过长无法增量追赶时：

主节点生成 RDB 文件。
主节点把 RDB 文件发送给从节点。
从节点清空旧数据并加载 RDB。
主节点继续把同步期间缓冲区中的写操作发送给从节点。

增量同步

当从节点短暂断线后重新连接，可以通过 psync 根据复制偏移量（offset）同步缺失的写操作，避免重新做一次全量同步。

高可用实现

Redis 常见高可用方案主要有两类：

哨兵模式（Sentinel）：监控主从节点状态，在主节点故障时自动完成故障转移。
集群模式（Cluster）：通过分片存储数据，提升容量上限，并支持水平扩展。

哨兵更偏向主从高可用，集群更偏向容量扩展和分片治理。

三、缓存问题与解决方案

缓存击穿

缓存击穿指的是一个热点 Key 在高并发访问时突然过期，大量请求同时打到数据库。

常见解决方案：

热点 Key 不设置过期时间，通过后台任务主动刷新。
互斥锁或分布式锁，只允许一个请求回源重建缓存。
逻辑过期，缓存中保存过期时间，由后台异步刷新数据。

缓存穿透

缓存穿透指的是大量请求访问不存在的数据，缓存无法命中，请求直接落到数据库。

常见解决方案：

布隆过滤器：在请求进入缓存和数据库之前过滤明显不存在的 Key。
缓存空对象：对不存在的数据短时间缓存空值，避免重复打到数据库。
参数校验：拦截非法 ID、异常参数和明显无效请求。

缓存雪崩

缓存雪崩指的是大量 Key 在同一时间过期，导致请求集中打到数据库。

常见解决方案：

随机过期时间，避免大量 Key 同时失效。
限流降级，在数据库压力过高时保护核心服务。
多级缓存或集群部署，减少单点缓存失效带来的冲击。

四、数据一致性与 Redis-MySQL 同步

双写一致性方案

业务中常见的数据源组合是 MySQL 存储主数据，Redis 作为缓存。这里的核心问题是：数据库更新后，缓存如何保持一致。

常见方案：

先写 MySQL，再更新 Redis：逻辑直接，但并发下可能出现旧值覆盖新值。
先写 MySQL，再删除 Redis：更常见，后续请求回源数据库并重建缓存。
延迟双删：写库后删除缓存，短暂延迟后再次删除，降低并发读写导致的脏缓存概率。
最终一致性：通过消息队列或 Canal 监听 MySQL Binlog，把数据变更异步同步到 Redis。

业务场景适配

对实时一致性要求很高的场景，需要更严格的事务或强一致方案。
对短暂延迟可接受的场景，通常使用缓存删除、消息队列、Binlog 同步等最终一致性方案。

缓存一致性没有绝对通用答案，重点是结合业务对“延迟、正确性、复杂度”的要求做取舍。

五、Redis 性能优化

慢查询排查

Redis 提供 slowlog 用于排查慢查询。常见优化方向：

避免 KEYS *、SORT、大范围 SUNION 等高复杂度命令。
对批量操作使用 Pipeline，减少网络往返。
控制单次命令处理的数据规模，避免阻塞主线程。

内存淘汰策略

当内存达到 maxmemory 限制时，Redis 会根据配置的淘汰策略处理 Key。

常见策略：

noeviction：内存不足时拒绝写入。
volatile-lru：只在设置了过期时间的 Key 中淘汰最近最少使用的 Key。
volatile-lfu：只在设置了过期时间的 Key 中淘汰最近最不常用的 Key。
allkeys-lru：在所有 Key 中淘汰最近最少使用的 Key。
allkeys-lfu：在所有 Key 中淘汰最近最不常用的 Key。
allkeys-random：在所有 Key 中随机淘汰。

缓存场景通常更常见 allkeys-lru 或 allkeys-lfu，但具体选择要看访问分布和业务容忍度。

BigKey 与 HotKey

BigKey 指单个 Key 占用过大内存或包含过多元素，会导致网络传输、删除、迁移和持久化变慢。

HotKey 指少数 Key 被高频访问，容易造成单点压力。

优化方向：

拆分过大的 Hash、List、Set、ZSet。
避免一次性读取或删除大 Key。
对热点数据做本地缓存、多副本缓存或请求合并。

六、线程模型与内存管理

单线程模型

Redis 的命令执行主要是单线程模型，这让它避免了大量锁竞争，命令执行顺序也更容易理解。

Redis 6.0 之后引入多线程处理网络 I/O，但命令执行本身仍然保持单线程语义。因此，慢命令、大 Key 操作、复杂聚合仍然可能阻塞 Redis。

过期键删除策略

Redis 对过期 Key 主要使用两种删除策略：

惰性删除

获取 Key 时检查是否过期，过期则删除。
优点：不主动消耗额外资源。
缺点：如果过期 Key 长时间不被访问，可能继续占用内存。

定期删除

Redis 定期随机抽样部分 Key，删除其中已经过期的 Key。
优点：可以主动清理过期数据。
缺点：不保证所有过期 Key 都会立刻被删除。

Redis 默认使用 惰性删除 + 定期删除 的组合策略。

七、Redis 变慢的排查方向

Redis 变慢时，可以从以下方向排查：

硬件资源

检查内存是否耗尽，是否发生 Swap，例如使用 free -m。
检查磁盘 I/O，尤其是 AOF 写入和重写期间。
使用 SSD 替代传统磁盘，降低持久化带来的 I/O 压力。

命令复杂度

排查是否使用了 KEYS、SORT、SUNION 等高复杂度命令。
检查是否存在大批量读取、大批量删除或大集合遍历。
对批量请求使用 Pipeline，减少网络延迟。

AOF 重写阻塞

AOF 重写期间可能与 fsync 竞争磁盘资源。可以根据场景配置：

no-appendfsync-on-rewrite yes

这个配置可以降低 AOF 重写期间的写入阻塞风险，但也会增加极端情况下的数据丢失窗口，需要结合业务容忍度评估。

缓存雪崩或击穿

如果数据库和 Redis 同时出现压力波动，需要排查是否存在：

大量 Key 同时过期。
热点 Key 突然失效。
缓存重建逻辑没有互斥保护。

八、Redis vs Memcached

特性	Redis	Memcached
数据类型	String、Hash、List、Set、ZSet 等	主要支持简单 Key-Value
持久化	支持 RDB、AOF	不支持持久化
内存回收	支持多种淘汰策略	支持 LRU 等缓存淘汰机制
原子操作	支持较丰富的原子操作	支持有限原子操作
线程模型	命令执行以单线程为主，Redis 6.0 后支持 I/O 多线程	多线程网络模型
场景适用	复杂缓存、计数、排行榜、分布式锁	简单缓存、高吞吐 Key-Value

简单说：如果只是做非常简单的缓存，Memcached 也可以胜任；如果需要更丰富的数据结构、持久化、高可用和分布式能力，Redis 更适合。

九、典型场景应用

Redis 常见业务场景包括：

缓存：存储热点数据，减少数据库压力。
会话保持：存储用户 Session 或登录态。
排行榜：通过 ZSet 实现 Top N 榜单。
限流降级：通过计数器、滑动窗口或令牌桶实现接口限流。
分布式锁：使用 SET key value NX PX 等命令实现基础锁能力。
延迟队列：通过 ZSet 分数存储执行时间，实现定时任务调度。

总结

Redis 的核心价值在于 高性能访问、灵活数据结构、持久化能力和分布式支持。

实际使用 Redis 时，需要重点关注四件事：

数据结构是否选对。
缓存异常场景是否有兜底方案。
Redis 与数据库之间是否能接受最终一致性。
是否避免了慢命令、BigKey、HotKey 和集中过期。

理解这些核心机制后，Redis 就不只是一个缓存组件，而是高并发系统中非常重要的性能与稳定性基础设施。