你没有理由不成为你热爱领域的专家
-
一次生产 Redis 内存打满的排查、清理和复盘
线上 Redis 内存到了 99.98%,开始逐出数据。先用 SCAN 把内存分布摸清楚,再按 LRU 空闲时间清掉一半冷数据释放 4GB,最后复盘背后的几个架构问题
-
一次内存缓慢泄漏的排查:每次都 new 一个 OpenAI 客户端,问题出在事件循环上
排查一个服务的内存缓慢泄漏,翻到同事写的一段后台富化逻辑:每次调用都现造一个 AsyncOpenAI 客户端,连接池悄悄堆成了泄漏。想直接缓存客户端复用却发现根本行不通,根子出在事件循环的生命周期上
-
一次数据库雪崩排查记
被拉进事故群的第一句话是"所有接口都在超时"。先止损让数据库缓过来,再回头查为什么一条两天半前就埋下的隐患,会在这个时间点集中爆发——顺着查下去,是一条忘关的分析查询、一个缺索引的热点接口、外加一把分布式锁在错误的时机被释放,三个凑在一起的完整链条。
-
写了个 IDEA 插件,把 GitHub Actions 塞进了 Git 面板
每次为了看一眼 Action 跑没跑成都要切出去开浏览器,干脆自己写一个得了
-
写了个 IDEA 插件,把项目里的 REST 接口都拍平摆在一个面板里
大仓库里接口一多就靠猜,全局搜索还搜不了完整路径,干脆自己写一个
-
一次 SQS 消费者静默退出的排查:问题最后竟然出在日志里
Web 服务和消息生产都正常,唯独消费者处理一次业务异常后悄悄退出,最后发现真正杀死 Task 的不是业务代码,而是一行错误日志
精选文章
联想510smini小主机
自己总结的命名规范希望能给大家参考
为什么电子垃圾往往会有第二春
开源软件
自动缓存方法数据注解