核心是复用Lucene索引能力+基于NIO构建轻量可控通信层；用Selector管理万级连接、DirectByteBuffer零拷贝、二进制协议路由、线程池隔离Lucene阻塞操作。
Java 用 NIO 实现分布式搜索引擎的网络层，核心不是“从零造轮子”，而是**复用 Lucene 的索引能力 + 基于 NIO 构建轻量、可控的节点间通信层**。Elasticsearch 底层虽用 Netty（基于 NIO），但对多数自研场景，直接用 Java NIO Selector + ByteBuffer 就能支撑万级连接、毫秒级请求路由，关键在设计合理、规避常见陷阱。
用 Selector 管理海量连接，不为每个请求开线程
分布式搜索引擎节点（如协调节点、数据节点）需同时处理成百上千个查询请求或分片同步请求。传统 BIO 模式下，一个连接一个线程，内存和上下文切换成本爆炸。NIO 的 Selector 可让单线程监听成千上万个 Channel 的读写事件：
- 初始化一个 Selector，注册所有 SocketChannel 到它，并关注 OP_READ 或 OP_CONNECT
- 主循环调用 selector.select() 阻塞等待就绪事件，再遍历 selectedKeys 处理 —— 这就是“事件驱动”的本质
- 每个连接只占用一个 SocketChannel 和少量堆外缓冲区，连接数轻松突破 10w+
用 ByteBuffer 做零拷贝缓冲，避免频繁 GC
搜索请求（如 JSON 查询体）和响应（如 hits 数组）通常几百字节到几 MB 不等。NIO 要求手动管理 ByteBuffer，但恰恰因此可精细控制内存：
- 使用 DirectByteBuffer（堆外内存）存放网络数据，绕过 JVM 堆，减少 GC 压力；配合 MappedByteBuffer 加载本地索引文件，实现文件→内存零拷贝
- 严格遵循 “write → flip → read → clear” 流程：写入后调 flip() 切换读模式，读完 clear() 重置 position/limit，否则会读空或越界
- 对大响应（如聚合结果），可分片 write()，避免单次分配超大 buffer；小请求则复用池化 ByteBuffer（如使用 JCTools 的 MpscChunkedArrayQueue 管理 buffer 池）
请求路由与协议设计要简单、可扩展
网络层不负责业务逻辑，只做“快递员”。协议越轻，解析越快，延迟越低：
立即学习“Java免费学习笔记（深入）”；
- 定义二进制头结构：4 字节 magic（0xCAFEBABE）、2 字节 version、1 字节 type（QUERY/SEARCH_RESULT/SHARD_SYNC）、4 字节 body length —— 解析只需 11 字节，无字符串匹配开销
- 请求 ID 内置于 header，支持异步响应匹配；超时由客户端发起重试，服务端不维护请求状态，符合无状态设计原则
- 分片请求发往哪个节点，由一致性哈希（如 MurmurHash3）计算 shard_id % node_count，服务端只查本地倒排索引，不跨节点转发
与 Lucene 索引层解耦，用线程池隔离阻塞操作
NIO 线程必须非阻塞，但 Lucene 的 IndexSearcher.search() 是 CPU 密集型操作，可能耗时几十毫秒。不能在 Selector 线程里直接调用：
- Selector 线程只做 decode request → 提交任务到固定大小的 ForkJoinPool 或 ScheduledThreadPool（大小 ≈ CPU 核数 × 2）
- 工作线程执行 search() 后，将结果 encode 成 ByteBuffer，再通过原 SocketChannel 注册 OP_WRITE 事件回写
- 若写缓冲区满（write() 返回 0），暂存 buffer 并注册 OP_WRITE；下次 select 触发后再续写，避免阻塞
