[测试技术] Elasticsearch测试 - Refresh、Mapping 与深分页怎么测

原创内容未获授权禁止转载、转发、抄袭。接口返回201 Created商品详情按 ID 也能查到但搜索列表没有数据批量同步返回 HTTP 200第二天却发现少了几百条商品。这类问题通常不是“Elasticsearch 挂了”而是测试只检查了请求状态没有检查搜索可见性、单条执行结果和业务数据一致性。本文用商品搜索场景说明 Elasticsearch 应该怎么测。示例中单节点只验证 API 行为副本切换和节点故障需要在多节点测试集群完成。为便于阅读示例省略认证信息生产环境不能关闭 TLS 和访问控制。先建立一条可追踪的数据链测试前数据库记录、同步任务、Elasticsearch 文档和搜索接口之间至少要能关联以下信息信息用途业务主键如SKU-1001判断少数据、重复数据和错数据biz_version或更新时间判断 Elasticsearch 是否被旧数据覆盖目标 Index、Alias确认读写是否落到同一版本_seq_no、_primary_term判断 Elasticsearch 内部是否发生并发更新同步批次、traceId串联数据库、消息、Bulk 请求和失败重试只比较数据库和 Elasticsearch 的总数不够。总数相同也可能同时存在一条漏同步和一条脏数据至少还要比对主键集合、业务版本和关键字段。下面先创建测试索引。单节点功能验证将副本数设为 0多节点故障测试需要重新配置副本PUT products-v1 { settings: { number_of_shards: 1, number_of_replicas: 0 }, mappings: { dynamic: strict, properties: { product_name: { type: text, fields: { keyword: {type: keyword} } }, price: {type: double}, stock: {type: integer}, updated_at: {type: date}, biz_version: {type: long} } } }Bulk 返回 200不代表每条都成功生产系统通常使用 Bulk API 同步数据。下面的索引使用严格 Mapping第一条商品合法第二条多了未定义字段POST products-v1/_bulk Content-Type: application/x-ndjson {index:{_id:SKU-1002}} {product_name:Wireless Mouse,price:199.0,stock:50,biz_version:1} {index:{_id:SKU-1003}} {product_name:USB Hub,price:99.0,stock:30,unexpected_field:bad,biz_version:1}实际响应的 HTTP 状态是 200但结果并非全部成功{errors:true,items:[{index:{_id:SKU-1002,status:201}},{index:{_id:SKU-1003,status:400,error:{type:strict_dynamic_mapping_exception}}}]}因此Bulk 测试必须断言HTTP 请求成功后继续检查顶层errors遍历每个items记录失败文档的 ID、状态码和原因429 可按退避策略重试超时或部分 5xx 的执行结果可能不确定应先按业务主键和版本对账Mapping 错误等 400 问题应修正数据后再处理不能把已成功项整批重放避免重复覆盖和额外版本递增重试耗尽后进入明确的失败队列或人工补偿而不是只打印日志补偿完成后按业务主键和版本重新对账。Bulk 使用 NDJSON每个 Action 和文档必须各占一行最后一行也要以换行结束。使用文件配合curl时应使用--data-binary否则换行可能被破坏。GET 能查到Search 仍可能查不到Elasticsearch 是近实时搜索。文档写入成功后实时 GET 可以立即读取而_search通常要等 Refresh 后才能看到。为了稳定复现先暂时关闭周期 RefreshPUT products-v1/_settings { index: { refresh_interval: -1 } }然后写入一条商品PUT products-v1/_doc/SKU-1001 { product_name: Mechanical Keyboard, price: 399.0, stock: 20, biz_version: 1 }写入返回_seq_no0后实际查询结果如下GET products-v1/_doc/SKU-1001 - foundtrue POST products-v1/_search - hits.total.value0 POST products-v1/_refresh - successful1 POST products-v1/_search - hits.total.value1自动化测试需要“写完立即搜索”时可在写入请求中使用refreshwait_for等待下一次 Refresh 后再断言。若refresh_interval-1还需要其他请求显式触发 Refresh否则不能依赖周期刷新完成等待。不要在性能测试或每条生产写入中固定使用refreshtrue强制 Refresh 会改变系统负载显式 Refresh 本身也是资源密集操作。实验结束后应恢复周期 RefreshPUT products-v1/_settings { index: { refresh_interval: 1s } }还要区分 Refresh 和数据持久性Refresh 解决的是“能否被搜索”不是数据库到 Elasticsearch 的同步事务也不等同于 Flush。搜索可见后仍需验证源数据、同步状态和失败补偿。Mapping 正确查询方式也可能错已知业务字段应优先使用显式 Mapping。前面的索引把商品名同时映射为全文检索字段product_name和精确匹配字段product_name.keyword。针对Mechanical Keyboard本次实测结果是term 查询 product_name - 0 条 match 查询 product_name - 1 条 term 查询 product_name.keyword - 1 条text字段会经过分词适合match精确筛选、聚合和排序通常使用keyword。测试不能只准备一种英文短词还应覆盖中文、大小写、特殊字符、超长文本、空值、数组、非法日期和数值边界。金额字段还要验证小数精度。示例为方便演示使用double真实金额通常应根据业务选择整数最小货币单位或设置缩放因子的scaled_float不能只验证显示值。dynamic: strict可以让未知字段直接失败便于尽早发现上游字段漂移。若允许动态 Mapping则要检查错误类型推断和字段数量持续增长避免 Mapping Explosion。多数已存在字段不能直接改变类型升级时通常需要新建索引、Reindex再切换 Alias。并发更新要防止旧数据覆盖两个同步任务同时读取商品库存一个先更新成功另一个稍后写回旧值。如果只使用普通 Index API后到的旧数据可能覆盖新状态。读取文档时记录_seq_no和_primary_term更新时带回这两个值PUT products-v1/_doc/SKU-1001?if_seq_no0if_primary_term1 { product_name: Mechanical Keyboard, price: 399.0, stock: 19, biz_version: 2 }第一次更新返回 200仍使用旧版本再次更新时实测返回HTTP 409 version_conflict_engine_exception required seqNo [0], primary term [1] current document has seqNo [2], primary term [1]测试时不能把 409 简单改成无限重试。应重新读取最新数据并按业务规则合并因为_seq_no只能识别 Elasticsearch 内部文档是否变化不能证明数据库同步事件的业务先后。biz_version还应有明确的处理规则小于当前版本拒绝写入防止旧事件覆盖新数据等于当前版本且内容一致按幂等请求处理等于当前版本但内容不同拒绝并告警大于当前版本允许更新。数据一致性回归至少要覆盖数据库新增但 Elasticsearch 缺失数据库已更新但 Elasticsearch 仍是旧biz_version数据库已删除或下架但搜索仍返回全量同步与增量同步交叉执行旧快照覆盖新事件重试后同一业务主键出现重复文档字段值一致但搜索接口因过滤条件或 Alias 指向错误而不可见。深分页不能只把页码改大默认情况下from size不能超过 10000。本次发送from10000、size1实际返回 HTTP 400Result window is too large, from size must be less than or equal to: [10000] but was [10001]不要为了绕过报错直接调大index.max_result_window。深分页应使用search_after翻页期间索引仍在 Refresh 时再配合 Point in TimePIT固定搜索视图。POST /products-v1/_pit?keep_alive1m POST /_search { size: 100, pit: { id: pit_id, keep_alive: 1m }, sort: [ {biz_version: asc} ], search_after: [1, 0] }下一页必须使用上一页最后一条记录返回的完整sort数组并保持 Query 和 Sort 不变。PIT 会自动增加_shard_doc作为唯一的 Tie-breaker不使用 PIT 时应显式增加每条文档唯一的排序字段否则同值数据可能重复或遗漏。本次使用size1实测第一页返回SKU-1002、sort[1,0]把该数组传给search_after后第二页返回SKU-1001、sort[2,1]两页没有重复。分页测试应在翻页过程中持续新增、更新和删除文档检查以下结果同一个 PIT 内是否重复或漏掉记录PIT 过期后是否返回明确错误并重新开始排序字段相同时顺序是否稳定业务要求精确总数时是否正确处理hits.total.relation必要时启用track_total_hits。当前官方文档已不建议使用 Scroll 处理深分页搜索推荐search_after PIT。Scroll 更适合历史上的批量遍历场景不应直接用于面向用户的实时翻页。Reindex 后重点检查 Alias 切换字段类型无法直接修改时通常会创建products-v2把products-v1数据 Reindex 过去再切换业务 Alias。只检查 Reindex 任务failures[]仍不够还要核对新旧索引的主键、版本、关键字段和增量追平结果。Alias 的删除和新增应放在同一个请求中POST /_aliases { actions: [ { remove: { index: products-v1, alias: products-read, must_exist: true } }, {add: {index: products-v2, alias: products-read}} ] }基础切换实测返回acknowledgedtrue、errorsfalse随后_alias/products-read只指向products-v2上例进一步增加了官方支持的must_exist保护。测试还应覆盖删除的 Alias 不存在和某个 Action 失败当校验失败时整个请求应失败Alias 仍指向旧索引。若业务通过 Alias 写入还要保证它只对应一个明确的is_write_indextrue。黄灯能搜索不代表集群安全单节点索引配置一个副本后本次实测得到{status:yellow,active_primary_shards:1,unassigned_shards:1,unassigned_primary_shards:0}Yellow 表示主分片已分配、部分副本未分配搜索和写入可能仍可执行但冗余能力已经下降Red 表示存在未分配的主分片部分搜索或写入可能失败。测试不能把“接口还能用”当作集群健康。多节点故障测试至少需要两个数据节点并先确认索引为 Green、主分片与副本位于不同节点。基线满足后再停止数据节点、制造磁盘水位或关闭分片分配观察主分片能否由副本接管故障期间读写结果是否明确Search 响应中的_shards.failed是否为 0不允许部分结果的业务接口是否设置并验证allow_partial_search_resultsfalse节点恢复后 Unassigned Shard 是否下降并最终回到 GreenRecovery 期间查询延迟、写入拒绝和 JVM 压力是否超出阈值Alias、同步任务和业务对账在故障恢复后是否仍然正确。一套可落地的回归清单场景注入方式核心断言近实时搜索写入后立即 GET 和 Search区分写入成功与搜索可见Bulk 局部失败混入非法字段和错误类型检查errors与每个 Item并发覆盖使用同一版本并发更新旧更新返回 409新数据不回退查询语义对text执行term和match结果符合 Analyzer 与 Mapping数据漂移增删字段、改变字段类型严格拒绝或按约定兼容深分页超过 10000 并在翻页时写入使用 PIT 后无重复、无遗漏Reindex全量迁移期间持续增量写入新索引数据追平后再切 AliasAlias 异常删除不存在的 Alias切换不出现错误或部分指向副本丢失停止一个数据节点状态变化、主分片接管符合预期数据对账制造缺失、过期和多余文档主键、版本和关键字段差异可定位总结Elasticsearch 测试不能停在 HTTP 状态码和命中数量。写入成功后要检查 Refresh 可见性Bulk 要逐条判断结果查询要结合 Mapping 和 Analyzer并发同步要防止旧数据覆盖深分页要验证稳定排序和 PIT重建索引还要检查增量追平与 Alias 指向。最终判断标准仍然是业务数据该搜到的能搜到不该出现的不会出现故障恢复后数据不缺、不旧、不重复。把数据库主键、业务版本、Index、Alias 和分片状态串成证据链问题才能被稳定复现和定位。