tgrep架构解析HybridIndexLiveIndex覆盖层如何实现微秒级索引热更新【免费下载链接】tgrepTrigram-indexed grep with a client/server architecture for fast regex search in large codebases locally项目地址: https://gitcode.com/gh_mirrors/tg/tgreptgrep 是一款基于三元组trigram倒排索引的 grep 工具采用客户端/服务器client/server架构专为大型代码库中的快速正则搜索设计。当你运行tgrep serve .后编辑器里每一次保存都能在毫秒内反映到索引中而正在执行的搜索查询完全不受干扰——这一切都归功于它的核心设计HybridIndex把只读的磁盘索引与可变的内存覆盖层LiveIndex合并成一张逻辑索引。本文带你拆解这套热更新机制的实现原理。双层索引磁盘底座 内存覆盖层tgrep 的索引由两层组成各自职责分明层载体特点磁盘索引IndexReadermmap 只读内存映射一次构建长期有效查询走零拷贝读取覆盖层LiveIndex纯内存 HashMap记录索引构建之后所有文件的增、改、删两层在 tgrep-core/src/hybrid.rs 中被包装成同一个结构磁盘层放在RwLockArcIndexReader里——注意Arc的存在这是后文微秒级热切换的关键覆盖层LiveIndex定义在 tgrep-core/src/live.rs包含倒排表、路径映射、删除墓碑tombstone和脏计数。为什么不用单一的可变索引因为磁盘索引以 mmap 方式共享给大量并发查询线程如果它本身可变任何一次文件变更都会让所有查询加锁等待。把变更隔离到一个小小的内存覆盖层磁盘底座就永远是只读快照查询路径保持无锁读取。一次文件保存如何变成毫秒级更新 服务器端内置文件监听器基于notify监听流程被刻意拆成锁外重活 锁内轻活两步实现见 tgrep-cli/src/serve.rs锁外计算文件变更事件到达后先读取文件内容在不持有任何索引锁的情况下提取三元组并计算位置掩码compute_trigram_masks见 tgrep-core/src/live.rs。文件再大、内容再多都不会阻塞并发搜索。锁内提交拿到现成的三元组结果后才短暂获取索引写锁调用commit_upsert把条目插入覆盖层tgrep-core/src/live.rs。这一步只是几条 HashMap 插入耗时在微秒级。删除文件时则走delete_filetgrep-core/src/live.rs不直接改动磁盘索引而是在覆盖层记一条删除墓碑查询时用它把磁盘层的旧结果过滤掉。查询合并规则覆盖层永远优先 一次搜索的结果是两层的并集且覆盖层具有更高优先级。核心逻辑在 tgrep-core/src/hybrid.rs先用同一个ArcIndexReader快照查磁盘层的所有三元组保证一次查询内版本号一致不会遇到查询中途索引被换掉的竞态再查覆盖层把结果追加进来最后用reader_entry_active过滤凡是磁盘层中被覆盖层修改过或已删除的文件其旧结果直接丢弃。一个精巧的细节是文件 ID 命名空间隔离覆盖层的文件 ID 最高位被置为OVERLAY_BIT1 31定义在 tgrep-core/src/live.rs磁盘层 ID 天然从 0 递增两者永远不会碰撞。判断一个结果来自哪一层只需一次位运算file_id OVERLAY_BIT ! 0。微秒级热切换Arc RwLock 的读优化当服务器决定把覆盖层数据落盘持久化时需要整体替换磁盘层的IndexReader。tgrep 的做法tgrep-core/src/hybrid.rs在临时目录staging写新索引文件再原子 rename 到索引目录打开新的IndexReader调用swap_reader——它只把RwLock内的Arc指针替换掉耗时微秒级正在执行中的旧查询继续持有旧ArcIndexReader读完再释放旧 mmap 在最后一个引用消失时才真正解除映射。效果是flush 期间并发搜索不阻塞。因为swap_reader接收self而非mut self持读锁的调用者也能完成换读者搜索线程和发布线程只在几微秒的指针交换瞬间短暂相遇。这套逻辑的完整发布流程见 tgrep-cli/src/serve.rs在索引写锁内完成swap_reader 覆盖层剪枝 内容缓存失效保证新旧代索引对搜索表现为一次原子换代。后台落盘自动保存与覆盖层剪枝覆盖层不能无限膨胀服务器用一条后台线程自动维护tgrep-cli/src/serve.rs触发条件累积 5000 次变更AUTO_SAVE_MUTATIONS或距上次保存超过 10 分钟快照解耦昂贵的 ID 重映射工作通过clone_raw_data在锁内快速复制原始 HashMap 完成真正的排序、重映射放到后台线程tgrep-core/src/live.rs把持锁时间压到最短剪枝加速发布完成后调用prune_persisted_entries清除已落盘的覆盖层条目。其中快速路径try_drop_all_persistedtgrep-core/src/live.rs用std::mem::take在微秒内把旧 HashMap 整体换走再交给后台线程去释放——对 28 万文件的覆盖层光drop旧表就要约 1 秒把它移出写锁就把一次多秒级的搜索停顿变成了微秒级。总结值得参考的架构要点tgrep 的热更新设计可以归纳为四条经验对任何只读快照 增量更新的系统都有借鉴意义读写分离磁盘层只读mmap可变部分隔离进内存覆盖层锁外重活、锁内轻活三元组提取在锁外HashMap 插入在锁内指针级换代用Arc快照让读者随时看到一致版本换索引只换指针异步清理大内存块的释放推迟到后台线程写锁内只做换表。想继续深入源码可以从以下入口开始双层索引合并与查询执行tgrep-core/src/hybrid.rs覆盖层数据结构与持久化快照tgrep-core/src/live.rs磁盘索引序列化格式tgrep-core/src/ondisk.rs只读 mmap 读取器tgrep-core/src/reader.rs服务器主循环、监听器与自动保存tgrep-cli/src/serve.rs查询计划与执行tgrep-core/src/query.rs【免费下载链接】tgrepTrigram-indexed grep with a client/server architecture for fast regex search in large codebases locally项目地址: https://gitcode.com/gh_mirrors/tg/tgrep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 tgrep架构解析：HybridIndex+LiveIndex覆盖层如何实现微秒级索引热更新
tgrep架构解析HybridIndexLiveIndex覆盖层如何实现微秒级索引热更新【免费下载链接】tgrepTrigram-indexed grep with a client/server architecture for fast regex search in large codebases locally项目地址: https://gitcode.com/gh_mirrors/tg/tgreptgrep 是一款基于三元组trigram倒排索引的 grep 工具采用客户端/服务器client/server架构专为大型代码库中的快速正则搜索设计。当你运行tgrep serve .后编辑器里每一次保存都能在毫秒内反映到索引中而正在执行的搜索查询完全不受干扰——这一切都归功于它的核心设计HybridIndex把只读的磁盘索引与可变的内存覆盖层LiveIndex合并成一张逻辑索引。本文带你拆解这套热更新机制的实现原理。双层索引磁盘底座 内存覆盖层tgrep 的索引由两层组成各自职责分明层载体特点磁盘索引IndexReadermmap 只读内存映射一次构建长期有效查询走零拷贝读取覆盖层LiveIndex纯内存 HashMap记录索引构建之后所有文件的增、改、删两层在 tgrep-core/src/hybrid.rs 中被包装成同一个结构磁盘层放在RwLockArcIndexReader里——注意Arc的存在这是后文微秒级热切换的关键覆盖层LiveIndex定义在 tgrep-core/src/live.rs包含倒排表、路径映射、删除墓碑tombstone和脏计数。为什么不用单一的可变索引因为磁盘索引以 mmap 方式共享给大量并发查询线程如果它本身可变任何一次文件变更都会让所有查询加锁等待。把变更隔离到一个小小的内存覆盖层磁盘底座就永远是只读快照查询路径保持无锁读取。一次文件保存如何变成毫秒级更新 服务器端内置文件监听器基于notify监听流程被刻意拆成锁外重活 锁内轻活两步实现见 tgrep-cli/src/serve.rs锁外计算文件变更事件到达后先读取文件内容在不持有任何索引锁的情况下提取三元组并计算位置掩码compute_trigram_masks见 tgrep-core/src/live.rs。文件再大、内容再多都不会阻塞并发搜索。锁内提交拿到现成的三元组结果后才短暂获取索引写锁调用commit_upsert把条目插入覆盖层tgrep-core/src/live.rs。这一步只是几条 HashMap 插入耗时在微秒级。删除文件时则走delete_filetgrep-core/src/live.rs不直接改动磁盘索引而是在覆盖层记一条删除墓碑查询时用它把磁盘层的旧结果过滤掉。查询合并规则覆盖层永远优先 一次搜索的结果是两层的并集且覆盖层具有更高优先级。核心逻辑在 tgrep-core/src/hybrid.rs先用同一个ArcIndexReader快照查磁盘层的所有三元组保证一次查询内版本号一致不会遇到查询中途索引被换掉的竞态再查覆盖层把结果追加进来最后用reader_entry_active过滤凡是磁盘层中被覆盖层修改过或已删除的文件其旧结果直接丢弃。一个精巧的细节是文件 ID 命名空间隔离覆盖层的文件 ID 最高位被置为OVERLAY_BIT1 31定义在 tgrep-core/src/live.rs磁盘层 ID 天然从 0 递增两者永远不会碰撞。判断一个结果来自哪一层只需一次位运算file_id OVERLAY_BIT ! 0。微秒级热切换Arc RwLock 的读优化当服务器决定把覆盖层数据落盘持久化时需要整体替换磁盘层的IndexReader。tgrep 的做法tgrep-core/src/hybrid.rs在临时目录staging写新索引文件再原子 rename 到索引目录打开新的IndexReader调用swap_reader——它只把RwLock内的Arc指针替换掉耗时微秒级正在执行中的旧查询继续持有旧ArcIndexReader读完再释放旧 mmap 在最后一个引用消失时才真正解除映射。效果是flush 期间并发搜索不阻塞。因为swap_reader接收self而非mut self持读锁的调用者也能完成换读者搜索线程和发布线程只在几微秒的指针交换瞬间短暂相遇。这套逻辑的完整发布流程见 tgrep-cli/src/serve.rs在索引写锁内完成swap_reader 覆盖层剪枝 内容缓存失效保证新旧代索引对搜索表现为一次原子换代。后台落盘自动保存与覆盖层剪枝覆盖层不能无限膨胀服务器用一条后台线程自动维护tgrep-cli/src/serve.rs触发条件累积 5000 次变更AUTO_SAVE_MUTATIONS或距上次保存超过 10 分钟快照解耦昂贵的 ID 重映射工作通过clone_raw_data在锁内快速复制原始 HashMap 完成真正的排序、重映射放到后台线程tgrep-core/src/live.rs把持锁时间压到最短剪枝加速发布完成后调用prune_persisted_entries清除已落盘的覆盖层条目。其中快速路径try_drop_all_persistedtgrep-core/src/live.rs用std::mem::take在微秒内把旧 HashMap 整体换走再交给后台线程去释放——对 28 万文件的覆盖层光drop旧表就要约 1 秒把它移出写锁就把一次多秒级的搜索停顿变成了微秒级。总结值得参考的架构要点tgrep 的热更新设计可以归纳为四条经验对任何只读快照 增量更新的系统都有借鉴意义读写分离磁盘层只读mmap可变部分隔离进内存覆盖层锁外重活、锁内轻活三元组提取在锁外HashMap 插入在锁内指针级换代用Arc快照让读者随时看到一致版本换索引只换指针异步清理大内存块的释放推迟到后台线程写锁内只做换表。想继续深入源码可以从以下入口开始双层索引合并与查询执行tgrep-core/src/hybrid.rs覆盖层数据结构与持久化快照tgrep-core/src/live.rs磁盘索引序列化格式tgrep-core/src/ondisk.rs只读 mmap 读取器tgrep-core/src/reader.rs服务器主循环、监听器与自动保存tgrep-cli/src/serve.rs查询计划与执行tgrep-core/src/query.rs【免费下载链接】tgrepTrigram-indexed grep with a client/server architecture for fast regex search in large codebases locally项目地址: https://gitcode.com/gh_mirrors/tg/tgrep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考