Spring Boot 集成 Elasticsearch 的生产实践：客户端选型、索引生命周期与批量写入容错

Spring Boot 集成 Elasticsearch 的生产实践：客户端选型、索引生命周期与批量写入容错

1. 先看一个真实场景：搜索为什么突然变慢、数据为什么偶尔丢

假设你负责一个订单搜索服务：每天有几百万条订单写入 Elasticsearch，运营后台按关键词、时间范围、状态做组合查询。上线三个月后出现两类问题。第一类问题是查询延迟从 80 毫秒涨到 2 秒，而且集中在上午十点。第二类问题是每日对账时发现，数据库里有 12 万条订单，索引里只查到 11.7 万条，差了三千条，日志里偶尔出现一行 bulk response has failures 但没有引起任何人注意。

这两个问题看起来一个偏查询、一个偏写入，根因却常常不在"Elasticsearch 慢"或"网络抖动"这种模糊结论上。查询变慢往往和索引生命周期策略缺位有关：历史索引副本数过多、分片过大导致查询要跨很多分片、或者冷热数据没有分离。写入丢数据往往和 bulk 容错缺位有关：客户端把批量请求发出去后只判断了 HTTP 状态码，没有逐条检查响应里的失败项，也没有重试或落库补偿。

这篇文章不打算从倒排索引的定义讲起，而是先把 Spring Boot 与 Elasticsearch 协作的整体模型讲清楚，再围绕客户端选型、索引生命周期、批量写入容错和连接池调优这四件事，逐层给出可以直接落地的判断方法。读者读完后，应该能回答三个问题：我的服务该用哪个客户端；我的索引该怎么按时间滚动和清理；我的批量写入在部分失败时该怎么补救。

2. 一句话模型与全局框架

可以先记住一个最小模型：Spring Boot 应用是"提问的人"，Elasticsearch 集群是"图书馆"，客户端是"借书证和检索规则"，索引生命周期是"书架怎么按年份归档和淘汰"，bulk 是"一次推一车书进去，但每本书是否上架成功要逐本核对"。 这个类比能帮助你理解角色分工，但它不能替代真实机制：Elasticsearch 内部还有分片、副本、段合并、refresh 这些物理过程，图书馆里没有对应物。

把整体拆成四部分来看它们怎样串起来：第一层是客户端层，运行在 Spring Boot 进程内，负责序列化请求、维护连接池、重试和负载均衡；第二层是协调层，请求先到达某个协调节点，它把查询拆到各个分片再把结果合并；第三层是数据层，分片是数据的最小存储单元，副本分片提供高可用和读吞吐；第四层是治理层，包括索引模板、ILM（索引生命周期管理）、别名和监控，它们决定数据如何被组织、迁移和删除。

一次查询的流转顺序大致是这样：应用调用客户端方法，客户端把请求发给集群中的某个节点，该节点作为协调节点把查询广播到相关分片，各分片本地执行查询并返回文档 ID 和排序值，协调节点做全局排序后，再回到相关分片取回完整文档，最后返回给应用。一次写入的流转顺序则是：应用调用 bulk，请求被路由到包含目标分片主分片的节点，主分片写入成功后同步到副本分片，副本确认后返回成功。理解这两条链路，后面的所有调优和容错都有落脚点。

下边用一张文本流程图把"一次 bulk 写入 + 容错判断"的关键路径画出来，后面几个章节会反复引用这条链路。

[业务数据 List<Order>]
        |
        v
[组装 BulkRequest，每批 500~1000 条]
        |
        v
[Java API Client 连接池取连接] --> [发送 _bulk 请求]
        |
        v
[协调节点路由到主分片] --> [主分片写 translog + 内存 buffer]
        |
        v
[同步到副本分片] --> [返回 BulkResponse]
        |
        v
[逐条检查 item.error] -- 有失败 --> [分类重试 / 落失败表]
        |
        no failure
        v
[记录成功条数，推进 offset]

3. 客户端选型：Java API Client 与 Spring Data ES 怎么选

Elasticsearch 官方在 7.15 之后主推 Java API Client ，它是基于 JSON 映射生成的强类型客户端，替代了旧的 RestHighLevelClient。它解决了什么问题？简单说，旧客户端大量使用 Map 和字符串拼装请求，字段名写错只能等运行时才发现；新客户端为每种请求生成对应类型，比如 SearchRequest、BulkRequest，写错字段编译期就报错。与此同时，Spring 生态提供了 Spring Data Elasticsearch ，它把 Repository 模式和 Elasticsearch 操作结合起来，让开发者像写 JPA 一样写 findByOrderNo。

两者不是替代关系，而是分工关系。Java API Client 更贴近原生 DSL，适合复杂查询、聚合、批量写入和需要精细控制刷新策略、路由、超时的场景。Spring Data Elasticsearch 适合标准 CRUD、简单派生查询和快速搭建原型，它底层通常也委托给某个客户端实现。当查询需要三层嵌套聚合、按条件切换 track_total_hits、或者要手工控制 bulk 分片时，直接使用 Java API Client 更省心。

选型的判断条件可以写得更具体：如果团队希望代码里尽量少出现字段名字符串、查询需要强类型和自动补全、写入量单日超过百万条，优先 Java API Client；如果项目以简单实体存取为主、开发者更熟悉 Spring Data 抽象、查询条件不超过两三个字段组合，Spring Data Elasticsearch 更高效；如果两者都要用，可以让 Spring Data 负责实体映射和简单查询，把复杂查询和 bulk 下沉到 Java API Client。这里最容易误解的是：用了 Spring Data 就不能用原生客户端。实际上它们可以在同一个项目中共存，只是要注意连接和线程池不要重复配置。

对比维度	Java API Client	Spring Data Elasticsearch
抽象层级	贴近原生 REST DSL，强类型请求	Repository 抽象，派生查询
学习成本	需要了解 Query DSL 与生成类型	熟悉 Spring Data 即可上手
复杂聚合	表达能力完整	复杂聚合需要自定义实现
批量写入	手工控制批量、刷新、路由	提供 saveAll 等封装
适合场景	搜索中台、写入量大、查询复杂	简单 CRUD、快速原型

4. 第一条完整链路：一个可运行的最小 Spring Boot + Java API Client 示例

下面这个示例的目标是：用 Spring Boot 3 加 Java API Client，连接本地 Elasticsearch 8.x，创建一个订单索引、写入一条订单、再按订单号查回来。前置环境是 JDK 17、Maven、本地已启动 Elasticsearch 8.x（默认 9200 端口）。之所以从最小示例开始，是为了先证明核心规则：强类型客户端如何把 Java 对象转成 DSL 请求，以及响应如何映射回对象。

<!-- pom.xml 关键依赖，简化片段 -->
<dependency>
    <groupId>co.elastic.clients</groupId>
    <artifactId>elasticsearch-java</artifactId>
    <version>8.13.4</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <version>3.2.5</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.15.4</version>
</dependency>

// OrderSearchService.java：最小可运行的检索与写入示例
import co.elastic.clients.elasticsearch.ElasticsearchClient;
import co.elastic.clients.elasticsearch.core.IndexResponse;
import co.elastic.clients.elasticsearch.core.SearchResponse;
import co.elastic.clients.json.jackson.JacksonJsonpMapper;
import co.elastic.clients.transport.rest_client.RestClientTransport;
import org.apache.http.HttpHost;
import org.elasticsearch.client.RestClient;

import java.io.IOException;
import java.util.Map;

public class OrderSearchService implements AutoCloseable {

    private final RestClient restClient;
    private final ElasticsearchClient client;

    public OrderSearchService() {
        // 一个最小连接：真实生产应配置多节点和连接池
        this.restClient = RestClient.builder(new HttpHost("localhost", 9200, "http"))
                .build();
        this.client = new ElasticsearchClient(
                new RestClientTransport(restClient, new JacksonJsonpMapper()));
    }

    public void createIndexIfAbsent() throws IOException {
        boolean exists = client.indices().exists(e -> e.index("order_v1")).value();
        if (exists) {
            return;
        }
        client.indices().create(c -> c
                .index("order_v1")
                .mappings(m -> m
                        .properties("orderNo", p -> p.keyword(k -> k))
                        .properties("userName", p -> p.text(t -> t))
                        .properties("amount", p -> p.double_(d -> d))
                        .properties("createdAt", p -> p.date(d -> d))));
    }

    public String saveOrder(String orderNo, String userName, double amount) throws IOException {
        Map<String, Object> doc = Map.of(
                "orderNo", orderNo,
                "userName", userName,
                "amount", amount,
                "createdAt", "2024-05-01T10:00:00Z");
        IndexResponse resp = client.index(i -> i
                .index("order_v1")
                .id(orderNo)
                .document(doc));
        return resp.result().jsonValue();
    }

    public long countByOrderNo(String orderNo) throws IOException {
        SearchResponse<Map> resp = client.search(s -> s
                .index("order_v1")
                .query(q -> q.term(t -> t.field("orderNo").value(orderNo)))
                .size(1), Map.class);
        return resp.hits().total().value();
    }

    @Override
    public void close() throws IOException {
        restClient.close();
    }

    public static void main(String[] args) throws IOException {
        try (OrderSearchService service = new OrderSearchService()) {
            service.createIndexIfAbsent();
            String result = service.saveOrder("ORD-20240501-001", "张三", 199.5);
            System.out.println("写入结果: " + result);
            long total = service.countByOrderNo("ORD-20240501-001");
            System.out.println("命中条数: " + total);
        }
    }
}

运行 main 方法后的预期输出是：写入结果: created 和 命中条数: 1。这里的关键步骤有三处：第一，mappings 把 orderNo 定义为 keyword，因为订单号需要精确匹配而不是分词匹配，如果误设为 text，term 查询可能查不到，这是最常见的改错点；第二，写入用 id(orderNo) 让同一订单号覆盖写，幂等性由文档 ID 保证；第三，close() 关闭底层 RestClient，否则进程可能无法正常退出。这个示例只适合验证链路，不能直接当生产代码，因为连接配置、异常分类和重试都还没有。

5. 索引生命周期：让索引像日志一样按时间滚动而不是无限膨胀

索引生命周期管理要解决的问题是：数据不会只增不减。订单搜索索引如果三年都不滚动，单索引会变得非常大，一次查询要扫很多分片；而日志类数据超过 30 天基本不再查询，却仍然占用磁盘和内存。ILM（Index Lifecycle Management）把索引的一生划分为几个阶段，每个阶段可以配置不同动作，比如热阶段保持高副本、温阶段缩小副本、冷阶段迁移到慢盘、删除阶段到期清理。

一个标准的四阶段策略可以这样理解：hot（热） 阶段索引正在被高频写入和查询，副本数保持 1 到 2，滚动条件是主分片大小达到 30GB 或文档数达到某个阈值；warm（温） 阶段写入停止、查询变少，可以把副本降到 1 并强制段合并；cold（冷） 阶段数据基本只读，可以迁移到低配节点；delete（删除） 阶段按保留期删除。如果用一句话概括，ILM 是"把索引当消耗品，按时间或大小生产新索引，旧索引自动降级和删除"。

在 Spring Boot 项目中，ILM 策略本身通常通过 Elasticsearch API 或 Kibana 创建，而不是写死在 Java 代码里，因为策略变更不应触发应用发版。应用侧要做的是配合策略：给索引使用统一命名前缀加日期后缀，例如 order-2024.05.01，写入时通过索引别名 order_write 指向当前索引，查询时通过读别名 order_read 覆盖所有历史索引。这样应用不需要知道今天到底写哪个物理索引，滚动和删除对业务透明。

// 创建 ILM 策略的请求体，简化示例
PUT _ilm/policy/order_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_primary_shard_size": "30gb", "max_age": "7d" },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

这里最容易误解的是滚动和删除的关系。滚动只是"到条件就开新索引"，并不会自动删除旧索引；删除必须显式配置 delete 阶段。另一个边界是 min_age 从滚动完成的时刻开始计算，不是从索引领创建时算起，所以"保留 90 天"实际会比预期略长。工程上建议先用一个非核心索引试跑策略，用 GET index/_ilm/explain 观察每个索引当前处于哪个阶段、下一步动作是什么。

阶段	典型数据特征	常见动作	常见错误
hot	高频写入与查询	rollover、保持高副本	只滚动不删旧索引
warm	写入停止、查询减少	forcemerge、降副本	在写入索引上 forcemerge
cold	基本只读	迁移慢节点、降优先级	冷节点磁盘仍满
delete	超过保留期	删除索引	误删仍在用的索引

6. 第二条完整链路：bulk 批量写入与逐条容错

批量写入要解决的问题是网络往返开销：一条一条写，每条都要一次 HTTP 请求，吞吐上不去。_bulk 允许把成百上千条操作放在一次请求里，显著减少往返。但它带来一个新风险：HTTP 返回 200 不代表全部成功。响应体里有一个 errors 字段，如果为 true，说明其中至少有一条失败，必须逐条检查 items 数组里每个操作的 error。很多团队丢数据就是因为只判断了 HTTP 状态码。

下面这个示例的目标是：把一批订单写入 order_write 别名，逐条检查失败项，把可重试的失败和不可重试的失败分开处理。前置条件是索引和别名已存在，且每条订单有一个稳定的业务主键。示例使用 Java API Client 的 BulkRequest 和 BulkResponse，这是生产中最常见的写法。

// BulkOrderWriter.java：带逐条容错的批量写入
import co.elastic.clients.elasticsearch.ElasticsearchClient;
import co.elastic.clients.elasticsearch.core.BulkRequest;
import co.elastic.clients.elasticsearch.core.BulkResponse;
import co.elastic.clients.elasticsearch.core.bulk.BulkResponseItem;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

public class BulkOrderWriter {

    private final ElasticsearchClient client;
    private final FailedRecordStore failedStore;

    public BulkOrderWriter(ElasticsearchClient client, FailedRecordStore failedStore) {
        this.client = client;
        this.failedStore = failedStore;
    }

    public BulkWriteResult writeBatch(List<OrderDoc> orders) throws IOException {
        BulkRequest.Builder builder = new BulkRequest.Builder();
        for (OrderDoc order : orders) {
            builder.operations(op -> op.index(idx -> idx
                    .index("order_write")
                    .id(order.orderNo())
                    .document(order)));
        }

        BulkResponse response = client.bulk(builder.build());
        int success = 0;
        List<OrderDoc> retryable = new ArrayList<>();
        List<OrderDoc> dead = new ArrayList<>();

        int i = 0;
        for (BulkResponseItem item : response.items()) {
            OrderDoc current = orders.get(i++);
            if (item.error() == null) {
                success++;
                continue;
            }
            int status = item.status();
            // 429 表示限流，5xx 表示服务端临时故障，可以重试
            if (status == 429 || status >= 500) {
                retryable.add(current);
            } else {
                // 400 多为映射冲突或数据格式问题，重试无意义
                dead.add(current);
            }
        }

        if (!dead.isEmpty()) {
            failedStore.saveDead(dead);
        }
        if (!retryable.isEmpty()) {
            failedStore.saveRetry(retryable);
        }
        return new BulkWriteResult(success, retryable.size(), dead.size());
    }
}

这段代码的关键步骤有四个。第一，逐条构造 index 操作并指定文档 ID，保证重复写入时是覆盖而不是新增。第二，遍历 response.items()，下标与输入列表一一对应，所以能精确定位到是哪条订单失败。第三，按状态码分流：429 和 5xx 进入重试队列，4xx 进入死信表。第四，把两类失败分别落库，而不是只打日志。

预期的可观察结果是：当你故意让一条文档的映射类型冲突时，success 会比输入条数少，dead 至少为 1，死信表里出现这条订单。常见的改错点是：有人用 response.errors() 为 false 就直接认为全部成功，其实要结合 items 逐条判断；还有人把 400 也放进重试队列，结果同一批坏数据反复重试，把集群压垮。批量大小建议从 500 到 1000 条或 5 到 15MB 之间起步，再根据节点写入能力和拒绝率调整。

7. 连接池调优：瓶颈常常在客户端而不是集群

连接池要解决的问题是：频繁创建和销毁 TCP 连接成本高，但连接太少又会让请求排队。Elasticsearch 的 Java 客户端底层基于 HTTP，连接池配置不当会出现两类现象：高并发下大量请求在客户端排队，表现为应用侧 RT 升高但集群 CPU 不高；或者连接数配置过大，把节点连接数打满，触发拒绝。

调优前先分清几个限制点。第一是客户端连接池上限，也就是最多能同时发出多少请求；第二是集群端每个节点的搜索线程池和写入线程池队列，队列满了会返回 429；第三是 refresh 频率，默认每秒一次，过于频繁的 refresh 会产生大量小段，拖慢查询和写入。理解了这三层，才能判断一个超时到底是客户端排队、集群拒绝，还是段合并压力。

一个务实的做法是：客户端连接数按"单个实例并发请求数上限"设置，不要盲目调大；同时给 bulk 请求设置明确超时，并在收到 429 时退避重试而不是立即重试。下面这段是简化配置片段，展示如何在一个 Spring Boot 配置类中集中管理客户端和连接参数。

// EsClientConfig.java：连接池与客户端的集中配置，简化代码
import co.elastic.clients.elasticsearch.ElasticsearchClient;
import co.elastic.clients.json.jackson.JacksonJsonpMapper;
import co.elastic.clients.transport.rest_client.RestClientTransport;
import org.apache.http.HttpHost;
import org.apache.http.impl.nio.client.HttpAsyncClientBuilder;
import org.elasticsearch.client.RestClient;
import org.elasticsearch.client.RestClientBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class EsClientConfig {

    @Bean(destroyMethod = "close")
    public RestClient restClient() {
        return RestClient.builder(
                        new HttpHost("es-node-1", 9200, "http"),
                        new HttpHost("es-node-2", 9200, "http"))
                .setRequestConfigCallback(cfg -> cfg
                        .setConnectTimeout(2000)
                        .setSocketTimeout(30000))
                .setHttpClientConfigCallback(this::tunePool)
                .build();
    }

    private HttpAsyncClientBuilder tunePool(HttpAsyncClientBuilder builder) {
        // 连接池上限要和实例并发能力匹配，不是越大越好
        return builder.setMaxConnTotal(200)
                .setMaxConnPerRoute(50);
    }

    @Bean
    public ElasticsearchClient elasticsearchClient(RestClient restClient) {
        return new ElasticsearchClient(
                new RestClientTransport(restClient, new JacksonJsonpMapper()));
    }
}

这段配置的工程含义是：连接超时 2 秒适合内网，Socket 超时 30 秒给批量写入留出空间；总连接数 200、单路由 50，意味着对两个节点的集群最多各维持约 50 条常用连接。适用场景是单实例 QPS 在几百量级的搜索服务。边界在于：如果实例很多，每个实例都开 200 连接，集群端连接数会线性增长，需要结合节点数和 http.max_open_connections 一起评估；把连接数当成性能开关盲目调大，往往只是把压力从客户端转移到集群。

8. 第三条完整链路：一次超时与 429 的排障推演

这个排障案例的输入是：某天上午十点，搜索接口 P99 从 200 毫秒涨到 3 秒，同时监控显示写入端出现持续 429。目标是定位到底是查询问题还是写入问题，以及它们的先后顺序。步骤是先从应用侧日志确认错误类型，再看集群线程池和节点指标，最后回到连接池与批量参数。

第一步，在应用日志中检索 429、timeout、rejected 三个关键词。如果 429 集中在 bulk 请求，说明写入线程池队列满；如果 timeout 集中在 search 请求，说明查询侧排队或分片过多。第二步，调用 GET _nodes/stats/thread_pool 观察 write 和 search 队列的 rejected 计数是否持续增长。第三步，用 GET _cat/indices?v 看是否有异常大的索引，比如单个索引超过 100GB、分片数过百。第四步，检查最近是否有 ILM 策略缺失导致历史索引未清理。

[P99 升高 + 429]
        |
        +--> 应用日志大量 bulk 429 --> 写入线程池排队
        |           |
        |           +--> 批量过大或 refresh 过频 --> 调整批量、降低 refresh
        |           +--> 连接数过大压满节点 --> 下调 maxConnTotal
        |
        +--> 应用日志大量 search timeout --> 查询侧问题
                    |
                    +--> 索引过多、分片过大 --> 启用 ILM 滚动与删除
                    +--> 深度分页 from+size --> 改用 search_after

一个常见的结果是：上午十点是数据同步任务高峰，同步任务一次性 bulk 写入 2 万条，触发了写入线程池拒绝，拒绝又导致重试风暴，重试占用连接池，间接拖慢了同时段的搜索请求。解决办法通常不是加节点，而是把批量拆小、增加退避重试、并检查是否对写入索引使用了 refresh=wait_for 之外的高频刷新。这里的边界是：线程池拒绝数要看增长速率而不是瞬时值，偶发的个位数拒绝是正常的背压信号。

9. 常见误区：看起来相同，但区别在机制

第一个误区是把"HTTP 200"当成"写入成功"。bulk 是批处理协议，单条失败不会改变整体状态码，必须逐条看 items。第二个误区是认为副本越多查询越快。副本能提升读吞吐，但每个副本都要占用存储和写入成本，副本数过多会让写入放大。第三个误区是在写入频繁的索引上做 forcemerge，这会消耗大量 IO 并可能阻塞查询，forcemerge 应该只对不再写入的索引执行。

第四个误区是沿用 RestHighLevelClient 的旧代码不做迁移评估。旧客户端在新版本中已不推荐，切换到 Java API Client 时，请求和响应的构造方式变化较大，尤其是查询和聚合。第五个误区是为了解决深度分页直接把 from 调大，from + size 超过 index.max_result_window 会直接报错，正确做法是用 search_after 或 scroll。第六个误区是把 ILM 策略只建在模板上就以为万事大吉，模板只负责新索引，已有索引不会被追溯应用。

误区	表面现象	真实机制	正确做法
200 即成功	批量后数据缺失	部分 item 失败	逐条检查 items
副本越多越快	读快写慢	写入放大	按读吞吐需求设副本
频繁 forcemerge	段变少但变慢	IO 与合并竞争	只对只读索引执行
深度分页调大 from	报错或内存高	全局排序开销	用 search_after

10. 生产实践建议：把参数和业务结果对应起来

第一，客户端层要做隔离。搜索请求和写入请求共享同一个 ElasticsearchClient 是可以的，但要分别设置超时和并发上限，避免批量写入挤占搜索连接。第二，所有 bulk 写入都必须有失败分类和补偿路径：可重试的进重试队列并配退避，不可重试的进死信表并告警。第三，索引命名和别名规范要固定下来，写入用单一写别名，查询用读别名，滚动由 ILM 完成。

第四，连接池参数要按实例数与集群容量核算。一个简单的估算是：集群总可用写入连接预算除以应用实例数，得到单实例连接上限，再留出 20% 余量。第五，观测要覆盖客户端和集群两侧：客户端记录 bulk 成功率、重试次数、P99 耗时；集群侧看线程池拒绝、段合并、refresh 频率。第六，任何调优都要有对照指标，比如把批量从 2000 降到 500 后，观察拒绝率是否下降而整体吞吐是否仍然满足。

11. 排障清单：从现象到动作

现象	优先检查	可能原因	处理动作
bulk 后数据缺失	响应 items 与日志	未处理部分失败	增加逐条容错
写入持续 429	线程池 rejected 计数	批量过大、重试风暴	拆小批量、退避重试
查询 P99 升高	索引大小与分片数	ILM 缺失、分片过多	启用滚动与删除
深度分页报错	max_result_window	from 过大	改用 search_after
节点连接被打满	http 连接与池配置	客户端连接数过大	下调连接上限
集群 CPU 高但写入慢	refresh 与段合并	刷新过频	调整 refresh_interval

12. 面试/复盘问题

1. Java API Client 和 Spring Data Elasticsearch 的职责边界是什么，什么情况下两者共存更合适？
2. 为什么 bulk 请求返回 200 仍可能丢数据，逐条容错的关键字段是什么？
3. ILM 的滚动和删除分别解决什么问题，为什么滚动后还必须配置删除阶段？
4. 连接池上限调大为什么可能让集群更慢，估算依据是什么？
5. 面对深度分页，from + size、search_after、scroll 三种方式各自适合什么场景？
6. 如果让你为一个日均千万写入的订单索引设计索引生命周期，你会如何划分阶段和滚动条件？

13. 总结

回到开头的两个问题。搜索变慢，通常是索引组织方式的问题，用 ILM 把数据按时间和大小滚动、给旧索引降级和清理，配合别名让应用无感，这是治理层要做的事。数据偶发丢失，通常是写入容错缺位，用 bulk 逐条检查、按状态码分类重试、把不可重试的数据落死信表，这是客户端层要做的事。连接池调优则是把客户端和集群的容量对齐，避免把压力在两侧之间来回转移。

把全文收成一张决策清单：写入量大且查询复杂时选 Java API Client；简单实体存取和原型阶段可以用 Spring Data Elasticsearch；索引必须配 ILM，滚动和删除要成对配置；bulk 必须逐条判断并分类处理失败；连接池按实例数和集群预算设置而不是越大越好。把这五条落到代码和监控里，Spring Boot 与 Elasticsearch 的协作才能从"能跑"走到"跑得稳"。

14. 参考资料

• Elasticsearch 官方文档：Java API Client 使用指南
• Elasticsearch 官方文档：Index Lifecycle Management（ILM）
• Elasticsearch 官方文档：Bulk API 与响应结构
• Elasticsearch 官方文档：Thread pools 与搜索、写入线程池
• Spring Data Elasticsearch 官方参考文档
• Spring Boot 官方参考文档：Spring Boot 3.x 与依赖管理
• 《Elasticsearch 权威指南》（Elasticsearch: The Definitive Guide）