Elasticsearch创建索引报resource_already_exists_exception但确认索引不存在求助

• 重复请求触发：你猜测的多节点请求是大概率原因。k8s环境下主节点Service如果没有配置会话保持，或者你的ES客户端开启了节点嗅探/自动重试机制，会导致同一条创建请求在极短时间内被多次发往不同主节点，毫秒级时间戳完全无法区分这种同毫秒的重复请求。
• 时间戳重复：仅依靠毫秒级时间戳作为唯一标识不可靠，高并发场景下同服务多实例、同实例同毫秒内多次调用import_index方法，都会生成完全相同的索引名。
• 超时重试触发：第一次创建请求已经在ES侧执行成功，但客户端因为网络延迟、ES元数据同步耗时太长没有收到成功响应，触发了客户端的自动重试逻辑，第二次请求就会报索引已存在。

1. 查看ES集群的访问日志，搜索报错的索引名brands_1637707367610，确认是否有2条及以上的创建请求记录，且请求来源IP/时间差符合重复请求特征。
2. 查看你的应用服务日志，确认creating new index: brands_1637707367610这条日志是否出现了多次，直接验证客户端是否重复触发了创建逻辑。
3. 检查ES客户端配置，确认是否开启了节点嗅探（sniff）、自动重试功能，k8s环境下开启嗅探会导致客户端绕过Service直接访问PodIP，很容易出现请求重复、路由异常问题。

• 优化索引名生成规则：在时间戳后追加随机字符串避免重名，示例代码如下：

const index = `${alias_name}_${+new Date()}_${Math.random().toString(36).slice(2, 8)}`

• 调整ES客户端配置：关闭节点嗅探功能，仅配置k8s Service地址作为唯一的ES接入地址，关闭非必要的自动重试规则。
• 创建逻辑做幂等处理：捕获resource_already_exists_exception异常后，先校验目标索引是否存在、mapping是否符合预期，如果符合要求就直接复用该索引继续后续流程，不用抛出异常中断执行。
• 调长创建请求的超时时间：给indices.create接口增加master_timeout、timeout参数，避免因为集群元数据同步慢导致的超时重试：

await this.esService.indices.create({
    index: index,
    master_timeout: "30s",
    timeout: "30s",
    body: {
        "settings": this.index_settings(),
        "mappings": mappings
    }
})

内容的提问来源于stack exchange，提问作者NeverBe