Redis原理-源码解析：数据结构2 list
Redis原理-源码解析：数据结构2 list所有原理实现基于Redis版本6.0.9 Redis中的list采用的是链表，在开始前，我们先看看list的最基本指令实现 t-list.c 由此可知，Redis的List底层数据结构都是基于quickList的 这是list所依赖的数据结构： quicklist.h 我们注意到其是由quicklistNode所构成的链表，而其中的数据实则为zl(ziplist)或是bookmark，在大多时候quicklistNode都使用ziplist存储数据 在上文中lpush执行了一个插入方法quicklistPush，在quicklist.c中有他的实现： quicklist真正存储数据的结构是ziplist，所以倒不如说，在Redis中，list是一个由ziplist节点构成的链表
2020-11-28鱼鱼
多步骤 Agent 的评估集怎么搭：黄金任务、回归与失败分类
多步骤 Agent 的评估集怎么搭：黄金任务、回归与失败分类Agent 一上多步骤，主观 demo 就变得不太可信：今天跑通一个订票流程，明天换一句用户说法就卡在第二步 团队里开始出现两种声音——“再换个更强的模型”和“再加点提示词” 我两边都试过，最后稳住质量的，反而是一套看起来很土的东西：评估集 这篇文章分享我搭多步骤 Agent 评估集时的具体做法：黄金任务怎么选、怎么跑回归、失败怎么分类，以及哪些指标有用、哪些容易自我安慰 没有标准答案，只有可复用的骨架 图片来源：原创示意图 单轮问答还能靠抽查 多步骤 Agent 的失败常常是路径型的： 没有固定任务集，你很难区分“模型今天运气好”还是“我们真的改进了” 评估集的首要价值不是刷分，而是给改动一个可重复的对手
2026-10-10鱼鱼
并发之AQS全解析
并发之AQS全解析我们知道juc(java.util.concurrent)包下有很多实用的类，提供了很多并发工具，例如线程池、原子类、并发工具、信号量工具、锁等，可以说基本实现都为悲观锁，底层原理基本都使用了AQS(AbstractQueuedSynchronizer)，AQS不是一种概念，是并发中实打实的工具类 本篇文章针对AQS做解析 AQS是多线程访问共享资源的同步器框架 AQS的资源可以是独占的也可以是共享的 我们先来简单看一下它的使用方式和ApI（因为是抽象类，是不能直接使用的）,下图是AQS的整体脉络 AQS核心就是一个状态值state，同时维护了一个线程的阻塞队列，队列的节点为有两种状态：SHARED(共享)和EXCLUSIVE(独占)，节点状态有五种：
![并发之AQS全解析]()
2021-03-12鱼鱼
ELK全家桶基本使用（I）文件收集Filebeat
ELK全家桶基本使用（I）文件收集FilebeatFilebeat是Elastic中的轻量文件收集系统，相比于功能更强悍的Logstash，当我们需求很单一，读取文件内容且对文件内容没有过多复杂处理时，最好使用FileBeat取代Logstash，以免造成不必要的内存开销 文档链接 Filebeat负责收集文件并发送给下游服务 核心行为包含输入、处理过滤和输出 当然也有集成好配置的模块，通过模块与Es和Kibana链接可以直接在Kibana上看到组件的可视化 同时不难看出Filebeat其实对数据库的支持不是很健壮 截止7.6版本，开源的Filebeat可支持以下几种消息输入类型： log 用得最多的输入类型； stdin 标准的输入，从process或是piepline读取（可理解为脚本运行通道直接输入），一旦配置了这种input方式，其他 input将不再生效文档地址；
2020-03-16鱼鱼
算法：广度优先搜索（BFS）（最短路径）
算法：广度优先搜索（BFS）（最短路径）我们先看一个案例： 遍历一个树结构，按层次输出树的节点内容，即：欲求 A B C D E F 实现方式便是从根节点（A）向下遍历，先获取A，其次是A的子节点B和C，其次是B的子节点D…… 这种遍历树结构或者图结构的方法被称作广度优先搜索（BFS），与之对应的先遍历到最下层子节点的是深度优先 BFS核心采用队列的数据结构，例如上面的树结构中，解法为： A进队列->A出队列 B、C进队列->B出队列 D进队列 ->C出队列 E、F进队列-> D、E、F出队列 如果想要区分层次边缘，使用count参数即可 解法步骤（蓝色部分为已经处理完的节点）：
2020-06-05鱼鱼
数据库的并发、锁机制与MVCC
数据库的并发、锁机制与MVCC在日常开发中，经常遇到数据库进行高并发操作的情况，但是我们处理并发一般都只在代码范畴而并不处理具体的数据库操作，这是因为数据库对基本的数据库操作做了锁处理，让我们可以忽略这一层的并发问题 详细可以参考Mysql的官方文档 注意：这一篇博客是针对MySQL数据库，且实用默认的 引擎InnoDb，使用其他数据库可能存在略微的差异 MySQL默认的数据库引擎InnoDB中Autocommit值为0（即自动提交事务）执行SQL语句的时候，每一条SQL语句都是一条单独的事务，所以并不存在并发的问题，数据库的锁机制已经做了很好的处理 但是当我们开启事务时，若不加处理，可能会产生一系列并发带来的问题
2021-01-24鱼鱼
AI 编程工程化迭代中的混沌风险：从规格熵到四个工程控制面
AI 编程工程化迭代中的混沌风险：从规格熵到四个工程控制面过去两年，我们团队把 AI 编程工具真正用进了日常研发：补全式的 Copilot、IDE 里的对话助手，以及能自己读写文件、跑命令的 Agent 收益是实打实的，样板代码、单元测试、脚本、联调、陌生框架的第一版实现，速度都明显提升 但用得越深，我越确信一件事：AI 工程化迭代最危险的地方，不是它“不会写代码”，而是它太会写了 在缺少稳定工程约束的时候，它会持续、高速地产出“单独看都挺合理，放在一起却彼此矛盾”的局部方案 这些矛盾的方案不会立刻表现为一个 Bug 它们表现为一种缓慢累积的混乱：同一个纠正反复被推翻，数据库越改越别扭，代码里一个概念长出两三个名字，线上出事时拼不出一条完整的因果链
2026-10-08鱼鱼
用 AI 写代码越久，我越怕自己“手生”
用 AI 写代码越久，我越怕自己“手生”先说一个可能很多人都有过的瞬间：公司网络抽风，或者 AI 插件突然登录失效，你对着一个空白文件准备写点东西，然后发现自己卡住了 不是不会写，是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿 以前这些东西是肌肉记忆，现在得想一想 我第一次意识到这件事的时候，心里咯噔了一下 倒不是怕失业，那个话题太大了，轮不到我在这儿焦虑 我怕的是更具体的东西：当 AI 给出的代码出了问题，我还看不看得出来 这篇文章不打算劝谁少用 AI 我自己每天都在用，而且用得挺开心 我只是想把这种“手生”的感觉拆开看看，它到底是错觉还是真的，以及我目前摸索出来的一些应对办法 说是办法，其实也就是一些习惯，不一定对，供参考
2026-10-08鱼鱼
Redis原理-源码解析：数据结构3 sorted set(zset))
Redis原理-源码解析：数据结构3 sorted set(zset))Redis的set数据结构在此不多讲，同Java中原理一样，set也可以理解为是hash剥离了value的数据结构，即同为dic 但是zset（有序集合）其实在底层原理上完全不同于set 所有原理实现基于Redis版本6.0.9 先看一下基本的指令实现，着重注意中文注解的地方 t_zset.c 可以看出zset的数据结构不是固定的，在其元素数或是元素的字符串过长时，其结构为zset；否则使用ziplist数据结构（像hash一样为了节省空间），二者的创建方法如下： ziplist的代码和原理可以参考我的博客Redis原理-源码解析：数据结构2 list-鱼鱼的Java小站，就是一个节省内存的压缩的链表结构
2021-02-28鱼鱼
[Quick Start]RedisTemplate的bean手动配置
[Quick Start]RedisTemplate的bean手动配置 有时我们可能需要手动配置Redis的连接，例如动态修改或是从特殊的参数中获取，而不是使用SpringBoot的自有配置，此篇文章意在快速指引redis的手动配置 基于Spring项目和Jedis的底层，使用RedisTemplate； 通过Maven引入相关依赖，可以的话spring-data-redis选择2.0.0以上版本，较低版本需要的依赖： 如果使用了Spring-boot并且要使用较高的版本（例如在2.1.0后才有的某些API-putIfAbsent带有超时时间的版本），我们直接修改starter的版本是不够的，二者版本并不对称，我们需要去掉其中的redis依赖并单独引入 建议保持良好的依赖管理习惯，显式的移除依赖，而不是任其覆盖，如：
2020-02-24鱼鱼
接手陌生代码库的第一周，我让 AI 当向导
接手陌生代码库的第一周，我让 AI 当向导前阵子我接手了一个老服务 说它老，不是说技术栈有多古早，而是它经历过好几拨人：最早写它的人早就转岗了，中间有人加过功能，也有人做过“临时方案”，README 停留在两年前的某次重构之前 给我的熟悉时间大概是一周，之后就要开始接需求 以前遇到这种情况，我的套路是从启动类开始一路点进去，点到头晕，再去翻提交记录，看看谁改得最多，厚着脸皮去问 这次我换了个方式：让 AI 陪我读 一周下来，感受挺复杂的——它确实让我快了不少，但也有几次差点把我带进沟里 这篇就记一下我是怎么用的，哪些地方好用，哪些地方我后来学乖了 我犯的第一个错，就是一上来问它：“帮我介绍一下这个项目的整体架构 ”
2026-10-10鱼鱼
分布式系统一致性的分类
分布式系统一致性的分类在分布式系统中的CAP理论中有C(一致性)，大郅表示分布式系统中节点状态或数据具有一致的特性 但一致性有着不同的分类，例如常见的用于取代CAP理论的BASE中的E，最终一致性，不同于强一致性，他强调着事务最终状态趋于一致，但中间态可能不一致，利用此篇文章总结一下分布式系统的一致性分类 根据实际系统的要求，分布式系统的一致性可以大致分为四类： 严格一致性 强一致性（线性一致/原子一致） 顺序一致性 弱一致性（最终一致性） 一个理想概念上的一致性，节点间数据完全一致，对外可表现为单个节点 由于网络延迟和通信等因素的存在，现实中这种一致性不可能存在 强一致性要求在全局时钟相同的条件下，对任何节点的读都相同且等于最后一次写成功的数据，这也就意味着仅仅在所有节点同步到数据后才会被标记为同步成功
2021-03-13鱼鱼
