上一篇【第27篇】灵活索引与定制存储结构下一篇【第29篇】索引文件格式详解Lucene 磁盘上的秘密摘要前面咱们都是单线程 demo真实世界里建索引基本是多线程甚至多进程狂写。Lucene 的 IndexWriter 天生线程安全多个线程共用一个实例并发 add 是标准姿势。这回讲清楚它的并发模型、近实时读者NRT Reader怎么做到写入即可见、索引万一损坏了怎么用 CheckIndex 救命以及怎么把一套索引拷到多台机器去服务。一、IndexWriter 的并发模型先给结论IndexWriter 是线程安全的你完全可以让 N 个线程拿着同一个 writer 实例往里 addDocument。Lucene 内部用一个线程安全的缓冲区 后台刷盘来消化并发写入你不用自己加锁。但要注意一个索引目录同一时刻只能有一个 IndexWriter 打开靠 write.lock 文件保证。这是为了防止两个进程各自写把段文件写花。所以多进程写同一目录这条路被堵死了多进程场景要么每人写自己的目录再合并要么走网络层的协调后面 SolrCloud/ES 就是这么干的。【多线程写同一个 IndexWriter】 线程A ─┐ 线程B ─┼─▶ 同一个 IndexWriter ─▶ 内部缓冲 ─▶ 刷盘成段 线程C ─┘ (线程安全) (串行化落盘) ❌ 两个进程各开一个 IndexWriter 写同目录 → write.lock 冲突我刚用时犯过傻为了提速给每台机器都开 writer 写共享 NFS 上的同一目录结果直接 lock 报错。多线程用一个 writer 是对的多进程写同目录是错的这个边界一定划清。二、近实时搜索写入即可见传统认知里“建了索引要重新打开 reader 才能看到新数据”。Lucene 的近实时NRT把这个延迟压到秒级你写完提交调用DirectoryReader.openIfChanged(oldReader)拿到一个新 reader新段立刻可见不用重建整个索引。DirectoryReaderreaderDirectoryReader.open(dir);// ... 写入并提交 ...DirectoryReadernewReaderDirectoryReader.openIfChanged(reader);if(newReader!null){reader.close();// 关掉旧的readernewReader;// 换成能看到新数据的IndexSearchersearchernewIndexSearcher(reader);}这里的精髓是 openIfChanged 只加载变化的段没变的段复用所以重开极快。这就是搜索框里刚发的帖子马上能搜到的底层支撑。对比咱们手写玩具每次都得把整个 HashMap 重读一遍数据一大就卡这就是工业级和玩具的差距。【NRT 可见性时间线】 t0 写入缓冲 t1 flush 成新段磁盘上 t2 commit 登记 t3 openIfChanged → 新 reader 看到新段 可见延迟 ≈ 从 t0 到 t3通常秒级需要提醒NRT 的实时是相对的默认 commit/refresh 有间隔。你想更实时就调短间隔但代价是段更碎、IO 更频繁又是那套权衡。后面讲 ES 的 refresh 还会碰到它。三、索引损坏了怎么办CheckIndex再稳的系统也架不住断电、磁盘坏道、误删文件。Lucene 索引一旦某个段文件残缺打开时可能直接抛异常。这时候别慌它自带一个体检工具 CheckIndex。// 命令行用法javaorg.apache.lucene.index.CheckIndex/data/idx// 代码里也能调CheckIndexcinewCheckIndex(dir);CheckIndex.Statusstatusci.checkIndex();if(!status.clean){// 有损坏可以尝试修复谨慎会丢弃坏段里的文档ci.exorciseIndex();// 把检查不通过的段剔除}CheckIndex 会逐个段校验词典和倒排对不对得上、文档计数准不准、各个文件 checksum 是否一致。它能干两件事诊断告诉你哪个段坏在哪不动数据先看清病情。修复exorcise把检查不过的段直接剔除。注意这是丢卒保车坏段里的文档会丢但至少救回其余健康的段让索引重新能打开。【索引损坏应急流程】 发现打不开 / 报错 │ ▼ CheckIndex.checkIndex() ── 诊断不破坏 │ ├─ cleantrue → 其实没坏查别的原因 │ └─ cleanfalse → 备份后 exorciseIndex() 剔除坏段 坏段文档丢失健康段保住我建议任何生产索引都定期跑 CheckIndex 做体检尤其在大版本升级、迁移磁盘之后。它就像给索引做胃镜花不了多少时间能提前发现隐患。四、把索引分发到多台机器索引建在一次服务要扛高并发常见套路是在一台机器上把索引建好然后原样拷贝分发到 N 台搜索节点每台本地开 FSDirectory 服务。因为 Lucene 的索引就是一串普通的段文件拷贝即可用不需要什么特殊协议。【索引分发雏形】 建索引机 ──生成段文件──▶ 拷贝/rsync ──▶ 节点A(/data/idx) ──▶ 节点B(/data/idx) ──▶ 节点C(/data/idx) 每台节点: DirectoryReader.open(本地 idx) → 独立服务这种建好再分发的模式简单可靠适合只读型索引比如词典、商品目录。它的问题是更新麻烦改了数据得全量重发或增量补段。更动态的边写边多机协同就超出了裸 Lucene 的能力要靠 SolrCloud、ES 的分片和副本机制那是以后的事。但今天这篇你记住两点就够第一Lucene 自身的并发模型是单 writer 多线程禁止多进程写同目录第二索引文件就是普通文件可拷贝、可分发、可体检修复。这两点正是裸 Lucene 和分布式搜索之间的桥。本篇小结IndexWriter 线程安全多线程共用一个实例是标准写法但一个目录同一时刻只能有一个 writerwrite.lock 兜底多进程写同目录行不通。近实时靠 openIfChanged 秒级看到新段不用重建索引。索引坏了用 CheckIndex 体检必要时 exorcise 丢卒保车。索引文件是普通段文件可直接拷贝分发到多机。下一篇我们把镜头拉到磁盘上逐文件拆开 Lucene 的索引格式看看这些段到底长什么样。上一篇【第27篇】灵活索引与定制存储结构下一篇【第29篇】索引文件格式详解Lucene 磁盘上的秘密
上一篇【第27篇】灵活索引与定制存储结构下一篇【第29篇】索引文件格式详解Lucene 磁盘上的秘密摘要前面咱们都是单线程 demo真实世界里建索引基本是多线程甚至多进程狂写。Lucene 的 IndexWriter 天生线程安全多个线程共用一个实例并发 add 是标准姿势。这回讲清楚它的并发模型、近实时读者NRT Reader怎么做到写入即可见、索引万一损坏了怎么用 CheckIndex 救命以及怎么把一套索引拷到多台机器去服务。一、IndexWriter 的并发模型先给结论IndexWriter 是线程安全的你完全可以让 N 个线程拿着同一个 writer 实例往里 addDocument。Lucene 内部用一个线程安全的缓冲区 后台刷盘来消化并发写入你不用自己加锁。但要注意一个索引目录同一时刻只能有一个 IndexWriter 打开靠 write.lock 文件保证。这是为了防止两个进程各自写把段文件写花。所以多进程写同一目录这条路被堵死了多进程场景要么每人写自己的目录再合并要么走网络层的协调后面 SolrCloud/ES 就是这么干的。【多线程写同一个 IndexWriter】 线程A ─┐ 线程B ─┼─▶ 同一个 IndexWriter ─▶ 内部缓冲 ─▶ 刷盘成段 线程C ─┘ (线程安全) (串行化落盘) ❌ 两个进程各开一个 IndexWriter 写同目录 → write.lock 冲突我刚用时犯过傻为了提速给每台机器都开 writer 写共享 NFS 上的同一目录结果直接 lock 报错。多线程用一个 writer 是对的多进程写同目录是错的这个边界一定划清。二、近实时搜索写入即可见传统认知里“建了索引要重新打开 reader 才能看到新数据”。Lucene 的近实时NRT把这个延迟压到秒级你写完提交调用DirectoryReader.openIfChanged(oldReader)拿到一个新 reader新段立刻可见不用重建整个索引。DirectoryReaderreaderDirectoryReader.open(dir);// ... 写入并提交 ...DirectoryReadernewReaderDirectoryReader.openIfChanged(reader);if(newReader!null){reader.close();// 关掉旧的readernewReader;// 换成能看到新数据的IndexSearchersearchernewIndexSearcher(reader);}这里的精髓是 openIfChanged 只加载变化的段没变的段复用所以重开极快。这就是搜索框里刚发的帖子马上能搜到的底层支撑。对比咱们手写玩具每次都得把整个 HashMap 重读一遍数据一大就卡这就是工业级和玩具的差距。【NRT 可见性时间线】 t0 写入缓冲 t1 flush 成新段磁盘上 t2 commit 登记 t3 openIfChanged → 新 reader 看到新段 可见延迟 ≈ 从 t0 到 t3通常秒级需要提醒NRT 的实时是相对的默认 commit/refresh 有间隔。你想更实时就调短间隔但代价是段更碎、IO 更频繁又是那套权衡。后面讲 ES 的 refresh 还会碰到它。三、索引损坏了怎么办CheckIndex再稳的系统也架不住断电、磁盘坏道、误删文件。Lucene 索引一旦某个段文件残缺打开时可能直接抛异常。这时候别慌它自带一个体检工具 CheckIndex。// 命令行用法javaorg.apache.lucene.index.CheckIndex/data/idx// 代码里也能调CheckIndexcinewCheckIndex(dir);CheckIndex.Statusstatusci.checkIndex();if(!status.clean){// 有损坏可以尝试修复谨慎会丢弃坏段里的文档ci.exorciseIndex();// 把检查不通过的段剔除}CheckIndex 会逐个段校验词典和倒排对不对得上、文档计数准不准、各个文件 checksum 是否一致。它能干两件事诊断告诉你哪个段坏在哪不动数据先看清病情。修复exorcise把检查不过的段直接剔除。注意这是丢卒保车坏段里的文档会丢但至少救回其余健康的段让索引重新能打开。【索引损坏应急流程】 发现打不开 / 报错 │ ▼ CheckIndex.checkIndex() ── 诊断不破坏 │ ├─ cleantrue → 其实没坏查别的原因 │ └─ cleanfalse → 备份后 exorciseIndex() 剔除坏段 坏段文档丢失健康段保住我建议任何生产索引都定期跑 CheckIndex 做体检尤其在大版本升级、迁移磁盘之后。它就像给索引做胃镜花不了多少时间能提前发现隐患。四、把索引分发到多台机器索引建在一次服务要扛高并发常见套路是在一台机器上把索引建好然后原样拷贝分发到 N 台搜索节点每台本地开 FSDirectory 服务。因为 Lucene 的索引就是一串普通的段文件拷贝即可用不需要什么特殊协议。【索引分发雏形】 建索引机 ──生成段文件──▶ 拷贝/rsync ──▶ 节点A(/data/idx) ──▶ 节点B(/data/idx) ──▶ 节点C(/data/idx) 每台节点: DirectoryReader.open(本地 idx) → 独立服务这种建好再分发的模式简单可靠适合只读型索引比如词典、商品目录。它的问题是更新麻烦改了数据得全量重发或增量补段。更动态的边写边多机协同就超出了裸 Lucene 的能力要靠 SolrCloud、ES 的分片和副本机制那是以后的事。但今天这篇你记住两点就够第一Lucene 自身的并发模型是单 writer 多线程禁止多进程写同目录第二索引文件就是普通文件可拷贝、可分发、可体检修复。这两点正是裸 Lucene 和分布式搜索之间的桥。本篇小结IndexWriter 线程安全多线程共用一个实例是标准写法但一个目录同一时刻只能有一个 writerwrite.lock 兜底多进程写同目录行不通。近实时靠 openIfChanged 秒级看到新段不用重建索引。索引坏了用 CheckIndex 体检必要时 exorcise 丢卒保车。索引文件是普通段文件可直接拷贝分发到多机。下一篇我们把镜头拉到磁盘上逐文件拆开 Lucene 的索引格式看看这些段到底长什么样。上一篇【第27篇】灵活索引与定制存储结构下一篇【第29篇】索引文件格式详解Lucene 磁盘上的秘密
![打卡信奥刷题（3668）用C++实现信奥题 P12234 [蓝桥杯 2023 国 Java A] 最大算式](http://pic.xiahunao.cn/yaotu/打卡信奥刷题（3668）用C++实现信奥题 P12234 [蓝桥杯 2023 国 Java A] 最大算式)
