鱼说，你看不到我眼中的泪，因为我在水中。水说，我能感觉到你的泪，因为你在我心中。 -村上春树
在分布式系统中，多个并发操作对同一资源的修改可能导致数据不一致。为了解决这种问题，Elasticsearch 提供了乐观锁（Optimistic Locking）机制，通过控制文档的 _seq_no 和 _primary_term 来确保更新的原子性。本文将通过 Postman 对 Elasticsearch 进行一次乐观锁机制的测试，模拟多个并发请求对同一文档的操作场景。
1.环境配置
在本文的测试中，使用的 Elasticsearch 服务地址为：http://192.168.56.100:9200。
首先，我们通过 Postman 来测试乐观锁的应用场景。这里假设你已经安装并配置好了 Elasticsearch。
Step 1: 创建文档
通过 POST 请求在 Elasticsearch 中创建一个新的文档：
URL:http://192.168.56.100:9200/chhei/system/100
请求方式： POST
请求体：
{ "name": "chhei"
}
输出结果：
{"_index": "chhei","_type": "system","_id": "100","_version": 1,"result": "created","_shards": {"total": 2,"successful": 1,"failed": 0},"_seq_no": 2,"_primary_term": 1
}
通过上面的请求，成功创建了一个名为 chhei 的文档，并分配了文档的 _seq_no 和 _primary_term，这是乐观锁机制中的关键部分。初始版本号为 1，_seq_no 为 2，_primary_term 为 1。
Step 2: 乐观请求 1 —— 更新文档
模拟一次乐观锁请求，通过控制 _seq_no 和 _primary_term 来进行文档更新：
URL: http://192.168.56.100:9200/chhei/system/100?if_seq_no=2&if_primary_term=1
请求方式： POST
请求体：
{"name": "chhei01"
}查询文档： 接下来通过 GET 请求查看文档更新后的状态：
URL: http://192.168.56.100:9200/chhei/system/100
请求方式： GET
输出结果：
{"_index": "chhei","_type": "system","_id": "100","_version": 2,"_seq_no": 3,"_primary_term": 1,"found": true,"_source": {"name": "chhei01"}
}
可以看到，文档的 name 字段成功更新为了 chhei01，文档版本号增加到 2，_seq_no 变为 3，_primary_term 保持为 1。
Step 3: 乐观请求 2 —— 模拟版本冲突
尝试使用过期的 _seq_no 和 _primary_term 再次更新文档，模拟一次乐观锁冲突：
URL: http://192.168.56.100:9200/chhei/system/100?if_seq_no=2&if_primary_term=1
请求方式： POST
请求体：
{"name": "chhei02"
}
输出结果：
{"error": {"root_cause": [{"type": "version_conflict_engine_exception","reason": "[100]: version conflict, required seqNo [2], primary term [1]. current document has seqNo [3] and primary term [1]","index_uuid": "ChcNr4J8QzyOk1SuFzvzdQ","shard": "0","index": "chhei"}],"type": "version_conflict_engine_exception","reason": "[100]: version conflict, required seqNo [2], primary term [1]. current document has seqNo [3] and primary term [1]","index_uuid": "ChcNr4J8QzyOk1SuFzvzdQ","shard": "0","index": "chhei"},"status": 409
}
从返回的错误信息中可以看到，Elasticsearch 检测到当前文档的 _seq_no 已经变为 3，而请求中的 _seq_no 仍然是 2，因此产生了 409 Conflict 错误，提示版本冲突。