第2篇：SOLR 的架构总览
第2篇：SOLR 的架构总览
2.1 前言
在上一篇文章中，我们已经完成了 SOLR 的源码环境搭建，成功运行了一个简单的实例，并初步浏览了源码目录结构。现在，我们将目光转向 SOLR 的整体架构，探索它如何将复杂的功能组织成一个高效的搜索系统。通过本篇，你将了解 SOLR 的核心组件是如何协作的，请求是如何从客户端到达服务器并返回结果的，以及源码中哪些关键类扮演了重要角色。这不仅是后续深入分析的基础，也是理解 SOLR 设计思想的起点。
SOLR 的架构设计兼顾了性能、扩展性和易用性。无论是单机部署还是分布式环境（SolrCloud），其核心思想都围绕着“高效索引”和“快速查询”展开。本文将从高层视图逐步深入到源码细节，带你一窥 SOLR 的全貌。
2.2 SOLR 的整体架构
2.2.1 高层视图
SOLR 的架构可以分为三个主要层次：
- 客户端层：通过 HTTP 请求（通常是 RESTful API）与 SOLR 交互，支持多种语言（如 Java 的 SolrJ、Python 的 pysolr 等）。
- 服务端层：SOLR 的核心运行时，包括嵌入式 Jetty 服务器、请求分发逻辑和核心组件。
- 存储层：基于 Lucene 的索引文件系统，负责持久化数据。
从功能上看，SOLR 的架构可以用下图简要表示（文字描述替代图形）：
客户端请求（HTTP） → SolrDispatchFilter（请求入口） → CoreContainer（核心容器） → SolrCore（具体核心） → Lucene（索引与搜索）
2.2.2 核心概念解析
在深入源码之前，我们需要理解 SOLR 中的几个关键概念，它们贯穿整个架构：
- Core：一个独立的核心，包含自己的索引、配置（
solrconfig.xml和schema.xml）和数据。通常用于单机模式。 - Collection：分布式环境下的逻辑概念，一个 Collection 可以分布在多个节点上，包含多个 Shard。
- Shard：Collection 的分片，每个 Shard 是一个独立的索引单元。
- Replica：Shard 的副本，用于高可用性和负载均衡。
- SolrCloud：SOLR 的分布式模式，通过 ZooKeeper 管理集群状态。
这些概念在源码中以类和数据结构的形式体现，后文会逐一分析。
2.2.3 单机 vs 分布式
- 单机模式：一个 SOLR 实例运行多个 Core，所有数据存储在本地。
- 分布式模式（SolrCloud）：多个 SOLR 节点组成集群，通过 ZooKeeper 协调分片和副本，数据分布存储。
本篇将以单机模式为主，逐步引入分布式概念，为后续专门的 SolrCloud 篇章做铺垫。
2.3 请求处理流程：从 HTTP 到响应
SOLR 的核心工作是处理客户端请求。无论是索引文档还是查询数据，SOLR 都通过 HTTP 接口接收请求，经过一系列组件处理后返回结果。以下是请求处理的高层流程：
- 客户端发送请求：如
http://localhost:8983/solr/mycore/update。 - 请求抵达服务器：Jetty 接收并交给 SOLR 的过滤器。
- 请求分发：根据路径（如
/update或/select）路由到对应处理器。 - 核心处理：调用 SolrCore 执行索引或查询操作。
- 结果返回：封装响应（如 JSON）返回客户端。
接下来，我们通过源码逐步剖析这一流程。
2.4 源码入口：SolrDispatchFilter
SolrDispatchFilter 是 SOLR 处理 HTTP 请求的起点，位于 solr/server/solr-webapp/webapp/WEB-INF/web.xml 中定义，作为 Servlet 过滤器拦截所有请求。
2.4.1 初始化
SolrDispatchFilter 的初始化发生在 SOLR 启动时：
public void init(FilterConfig config) throws ServletException {
this.config = config;
this.pathPrefix = config.getInitParameter("path-prefix");
coreContainer = createCoreContainer(