IO多路复用模型：select、poll、epoll对比
IO多路复用模型：select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型，譬如网络请求的socket IO，在数据返回前，相应的线程或是进程将会一直 阻塞直到数据返回，比较直接的处理便是针对IO流一对一的监听，但在IO返回前，相应的系统资源会平白无故的浪费，这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO，就能实现对系统资源的更好利用，在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用，在Linux系统中，实现IO多路复用的方式（从古老到新）有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
2020-08-11鱼鱼
改了一句系统提示词，Agent 就变了个样：我开始给提示词做版本管理
改了一句系统提示词，Agent 就变了个样：我开始给提示词做版本管理先说一次让我印象很深的翻车 我维护着一个内部用的小 Agent，帮同事查工单、查日志、整理排查结论 有段时间有人反馈它“太啰嗦”，每次回答都要铺垫好几段 我就去后台的配置里，在系统提示词末尾加了一句：“回答尽量简洁 ” 改完自己试了两个问题，回答确实短了，挺满意，就没再管 过了几天，陆续有同事说它“变笨了”：以前问它某个工单的状态，它会先调用查询工具，再基于查到的结果回答；现在它经常不查，直接根据对话里的只言片语给个结论 还有一个多步骤的排查任务，它以前会一步步来，现在倾向于一步跳到结论 我一开始完全没往那句“尽量简洁”上想，在日志里找了半天别的原因 更尴尬的是，我想看看“几天前的提示词长什么样”，发现做不到——提示词存在配置后台，直接在线改，改完就覆盖了，没有历史
2026-10-14鱼鱼
让 AI 起变量名和函数名，我留下的几条品味规矩
让 AI 起变量名和函数名，我留下的几条品味规矩命名一直是我写代码时最磨蹭的环节之一 名字起糊了，后面读代码的人（包括一个月后的我）会一直付税 AI 很擅长甩出一串候选名，也很容易甩出看起来专业、读起来空洞的名字 这篇文章记我让它起名时留下的几条规矩——不是语法规范全文，是品味上的取舍 我愿意让 AI 起名，前提是： 我已经能用一句话说明“这个东西在业务里干什么” 我要的是 3–5 个候选，不是一个“最佳答案” 最终选定权在我，尤其是会进公共 API、表字段、事件名的那些 一上来就说“给个好名字”，它常会给你 handleUserData、processInfo、manageService 这类语法正确但语义稀释的词 候选机模式能逼它发散，也逼我比较
2026-10-14鱼鱼
浅析RPC框架Thrift
浅析RPC框架ThriftThrift是由Facebook开发的 RPC远程调用的框架，使用独有的Thrift协议进行可跨语言的远程调用 有点类似protobuf 无论使用何种语言，首先要准备Thrift编译环境，可以去官网下载相应的Thrift执行文件，下文均以Windows为例 下载后可以选择性的配置环境变量，最终在shell中可执行Thrift 在项目中，预先准备好libthrift依赖，maven写法： 例如： 定义一个testService.thrift（idl文件名不重要），一般都会定义在resources的thrift文件夹下： 这里定义了两个方法，分别返回字符串和int类型，在thrift的idl中，对于变量的定义如下：
2022-03-04鱼鱼
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解CAT是美团点评的一个基于Java开发的异常和性能监控项目，github地址：https://github.com/dianping/cat 本篇文章不是对CAT本身的源码拆解，而是基于本人依赖CAT client开发的代理项目进行拆解，但是并不会纰漏任何技术细节 CAT当前已有很多不同语言的Client，当然暂且是不 CAT本身是通过CAT client收集数据并上报至CAT server，server会进行并，共有六种常见数据格式：Transaction、Event、Problem、Metric、HeartBeat、调用链标记，其实如果不考虑复杂的处理（譬如Metric是可以基于指标生成折线图，Problem可以根据具体的异常类型追溯到相应的会话Track）除去Transaction剩余的数据格式都可以理解为特殊的Event
2020-07-19鱼鱼
用 AI 代替搜索引擎一阵子之后，我又把搜索框请了回来
用 AI 代替搜索引擎一阵子之后，我又把搜索框请了回来有一段时间，我几乎不打开搜索引擎了 遇到不会的东西，第一反应是切到 AI 对话框，把问题一贴，等它给我一段整理好的答案 说实话，这个体验太舒服了：不用在十个标签页之间来回翻，不用忍受广告和那种互相抄来抄去的“技术博客”，看不懂还可以接着追问，它也不会嫌我烦 那阵子我甚至跟同事开玩笑说，搜索框可以退休了 后来发生了几件小事，让我又把搜索框请了回来 现在我两样都用，只是分工比以前清楚多了 这篇就聊聊这个过程，没什么高深的东西，都是日常里的小体会 那天升级了一个依赖的小版本，项目启动直接报错 我把报错堆栈贴给 AI，它很快给了一个解释：大概是某个类加载顺序的问题，建议我调整一下配置，再加一个排除项
2026-10-14鱼鱼
Agent 跑批任务时我盯的几个「仪表盘」指标
Agent 跑批任务时我盯的几个「仪表盘」指标把 Agent 丢进一批任务里跑，最容易犯的错是：只盯最终答案 答案对了就庆祝，错了再翻日志 跑多了你会发现——很多失败在中途就已经写在仪表盘上了，只是你没看 这篇文章记我跑批（批量任务、夜间任务、评测集重跑）时会盯的几类指标 不是定行业标准，是我个人反复被坑后留下的观察清单 如果你也在用 Agent 刷题集、批量修测试、批量整理仓库，希望能少踩一点「早上起来只看见成功率」的坑 最终答案是结果，不是过程健康度 两类任务都可能「答对」： 走了一条干净路径，三步完成 绕了四十步，失败重试一堆，最后撞对 只看答案，你会把第二种也当成可上线策略 成本、稳定性、可复现性全被藏起来了
2026-10-15鱼鱼
AI 建议装新依赖时，我怎么查验再动手
AI 建议装新依赖时，我怎么查验再动手结对写代码时，AI 很爱给一种“干净解法”：装一个库，三行调用，问题消失 有时这确实是正道；有时则是把一个五分钟能写完的小函数，换成十年后还要付账的依赖 我吃过亏：当时图省事装了包，后来发现维护停滞、传递依赖一堆、许可证也不理想 卸载比安装痛 所以现在但凡 AI 说“建议安装某某”，我会先走一套很短的查验，再决定装不装 查验的第零步不是搜包，而是判断需求本身 若是加密、图像处理、成熟协议实现——自己造轮子风险更大，倾向用维护良好的库 若是拼接查询字符串、简单重试、薄封装——先看标准库或现有工具能不能扛 我会明确问 AI：“不用新依赖，用标准库怎么写？代价是什么？”它若给不出合理的无依赖方案，只是单方面推销某个包，我反而更警惕
2026-10-14鱼鱼
提示词工程与上下文工程：让模型看到“对的信息”
提示词工程与上下文工程：让模型看到“对的信息”写 Agent 时，很多人把精力放在“提示词怎么写得更花哨”上 实际上，更影响效果的往往是：在每一步，模型的上下文里究竟放了什么 这就是近来常被提起的“上下文工程（Context Engineering）” 本文先区分提示词工程与上下文工程，再讲系统提示的结构、上下文的选择/压缩/隔离/外置四种手段，提供一个带 token 预算的上下文组装器（Python）与结构化输出校验（Python + Java），最后总结常见错误、检查清单与 FAQ 上下文窗口里的六个组成部分 很多团队有过这样的经历：换了更强的模型，效果只提升了一点；而把检索结果排序调整了一下、把冗长的工具输出裁剪了一下，效果反而明显改善
2026-10-14鱼鱼
AI大模型定价对比
AI大模型定价对比https://open.bigmodel.cn/pricing 火山方舟也提供端点（GLM3 0.001） https://openai.com/ja-JP/api/pricing/ 出入价格不一样 官网和火山都有 另外有免费版本的
2024-12-18鱼鱼
接手陌生代码库的第一周，我让 AI 当向导
接手陌生代码库的第一周，我让 AI 当向导前阵子我接手了一个老服务 说它老，不是说技术栈有多古早，而是它经历过好几拨人：最早写它的人早就转岗了，中间有人加过功能，也有人做过“临时方案”，README 停留在两年前的某次重构之前 给我的熟悉时间大概是一周，之后就要开始接需求 以前遇到这种情况，我的套路是从启动类开始一路点进去，点到头晕，再去翻提交记录，看看谁改得最多，厚着脸皮去问 这次我换了个方式：让 AI 陪我读 一周下来，感受挺复杂的——它确实让我快了不少，但也有几次差点把我带进沟里 这篇就记一下我是怎么用的，哪些地方好用，哪些地方我后来学乖了 我犯的第一个错，就是一上来问它：“帮我介绍一下这个项目的整体架构 ”
2026-10-14鱼鱼
动态路由数据源（多租户）解决方案
动态路由数据源（多租户）解决方案当下有很多服务都使用了多数据源，或是出于跨库查询或是分库分表、读写分离等，多数据源解决方案早已不是稀罕事 常见的解决方案包括使用多数据源框架(例如Shareding-Jdbc)、在数据库端做代理（例如MYCAT）、对于固定的几个数据源连接，也可以直接手动配置多个数据源，这种相关处理有很多源码，我在github上也有简单的实现：fishstormX/dynamicDataSource: 动态数据源的实现，基于maven自定义多模块骨架 Spring Boot2.0.x，本文实现的是动态数据源，主要为了解决 多租户问题（不同的用户群组有不同的数据源和配置，强调数据的隔离性） 本文技术能实现的是动态数据源，基于Spring框架，即能够将注入的Datasource根据租户不同使用不同的来源，同时根据租户增减动态的增删和缓存数据源（增是因为会有新增租户可能使用到项目启动后的数据源，减是因为租户数不可预料，不可直接缓存所有的数据源）
2021-01-07鱼鱼
