文章目录
- 一,105-全文检索-ElasticSearch-入门-_cat
- 二,106-全文检索-ElasticSearch-入门-put&post新增数据
- 三,107-全文检索-ElasticSearch-入门-get查询数据&乐观锁字段
- 1,过时的乐观锁-version
- 2,Elasticsearch7的乐观锁
这篇内容是使用kibana学习elasticsearch的使用。
一,105-全文检索-ElasticSearch-入门-_cat
在kibana中打开devtools界面。
在代码的下面界面的左侧区域使用elasticsearch的API完成对elasticsearch的操作。
在DevTools左侧编辑界面输入命令,点击右侧三角按钮发出请求。
GET /_cat/nodes:查看所有节点
GET /_cat/health:查看 es 健康状况
GET /_cat/master:查看主节点
GET /_cat/indices:查看所有索引
-
GET /_cat/nodes
- 这个API端点用于列出Elasticsearch集群中的所有节点。它会返回节点的名称、角色、主机地址、版本等信息。
- 这个API端点用于列出Elasticsearch集群中的所有节点。它会返回节点的名称、角色、主机地址、版本等信息。
-
GET /_cat/health
- 这个API端点用于显示集群的健康状况。它会返回集群的总体状态(如green、yellow或red),以及关于分片和节点的详细信息。
-
GET /_cat/master
- 这个API端点用于显示当前集群的主节点信息。主节点负责管理集群状态和分片的分配。
-
GET /_cat/indices
- 这个API端点用于列出集群中所有的索引。它会返回索引的名称、文档数量、数据大小、索引状态等信息。
- 这个API端点用于列出集群中所有的索引。它会返回索引的名称、文档数量、数据大小、索引状态等信息。
要使用这些API,需要通过HTTP客户端(如curl、Postman或任何其他HTTP工具)向Elasticsearch服务发送GET请求。例如,使用curl工具,可以这样发送请求:
curl -X GET "localhost:9200/_cat/nodes"
会返回Elasticsearch集群中所有节点的信息。注意,需要将localhost:9200
替换为实际的Elasticsearch服务地址和端口。
二,106-全文检索-ElasticSearch-入门-put&post新增数据
保存一个数据,保存在哪个索引的哪个类型下,指定用哪个唯一标识。
// 在 customer 索引下保存 1 号数据为
POST customer/_doc/1
{
"name": "John Doe"
}
- customer,索引名称
- _doc,type名称,索引下最多有一个type
响应结果如下。
注意,如果没有对应的索引,会自动创建索引,然后在索引下插入数据。比如调用这个API向customer索引插入一条数据,虽然没有提前创建customer索引,但是服务端会先创建索引,然后在这个索引下创建文档。
PUT 和 POST 的区别:
- POST 可以新增可以修改。如果不指定 id,会自动生成 id。指定 id 就会修改这个数据,并新增版本号
- PUT 可以新增可以修改。PUT 必须指定 id;由于 PUT 需要指定 id,我们一般都用来做修改
操作,不指定 id 会报错。
三,107-全文检索-ElasticSearch-入门-get查询数据&乐观锁字段
查询一个id为1的文档。
GET customer/_doc/1
结果如下。
-
"_index" : "customer"
:这表示查询结果来自名为"customer"的索引。 -
"_type" : "_doc"
:这是文档的类型,在Elasticsearch 7.x版本之后,文档类型被废弃,统一使用_doc
作为文档类型。 -
"_id" : "1"
:这是文档的唯一标识符,在Elasticsearch中,每个文档都有一个唯一的ID。 -
"_version" : 5
:这表示文档的版本号,Elasticsearch使用版本号来处理文档更新和删除操作。 -
"_seq_no" : 8
:这是文档的序列号,用于追踪文档在索引中的顺序。 -
"_primary_term" : 1
:这是主分片的任期号,用于处理分片故障和恢复。 -
"found" : true
:这表明查询找到了匹配的文档。 -
"_source" : { "name" : "John Doe" }
:这是文档的原始数据部分,包含了文档的字段和值。在这个例子中,文档有一个字段name
,其值为"John Doe"。
1,过时的乐观锁-version
Elasticsearch6以前的乐观锁是通过版本号(_version
)来实现的。
乐观锁是一种并发控制机制,它假设在大多数情况下,多个进程或线程不会同时修改同一数据项。当一个进程或线程想要更新一个文档时,它会带上该文档的当前版本号。
如果在这个进程或线程读取文档之后,有其他进程或线程更新了该文档,导致版本号发生变化,那么Elasticsearch 会拒绝这个更新请求,并返回一个错误,提示版本冲突。
乐观锁的使用可以防止数据的并发更新导致的数据不一致问题。以下是如何使用Elasticsearch API 来构建一个测试用例的步骤:
-
创建索引:首先,你需要创建一个索引来存储文档。
PUT /my_index { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 0 } } }
-
索引文档:然后,索引一个文档,并记录下返回的版本号。
POST /my_index/_doc/1 { "name": "John Doe" }
返回结果中会包含文档的版本号。
-
读取文档:读取文档以获取其当前版本号。
GET /my_index/_doc/1
返回结果中会包含文档的当前版本号。
-
模拟并发更新:在两个不同的会话或线程中,使用相同的版本号尝试更新同一个文档。
会话1:
POST /my_index/_update/1?version=1 { "doc": { "name": "Jane Doe" } }
会话2(几乎同时):
POST /my_index/_update/1?version=1 { "doc": { "name": "Alice Smith" } }
注意,如果es版本是7及更高版本,使用version作为乐观锁会报如下错误。
-
处理版本冲突:Elasticsearch 会处理这两个更新请求,但是只有一个会成功,另一个会因为版本冲突而失败。
成功更新的会话将返回一个成功的状态,而失败的会话将返回一个错误,例如:
{ "error": { "root_cause": [ { "type": "version_conflict_engine_exception", "reason": "[my_index][1]: version conflict, current version [2] is different than the one provided [1]", "index_uuid": "...", "shard": "0", "index": "my_index" } ], "type": "version_conflict_engine_exception", "reason": "[my_index][1]: version conflict, current version [2] is different than the one provided [1]", "index_uuid": "...", "shard": "0", "index": "my_index" }, "status": 409 }
2,Elasticsearch7的乐观锁
Elasticsearch7已经引入了更先进的并发控制机制,使用if_seq_no
和if_primary_term
参数进行文档更新和删除操作。
if_seq_no
和if_primary_term
参数允许用户在执行更新或删除操作时指定期望的序列号和主分片任期号。
如果指定的序列号和任期号与当前文档的序列号和任期号不匹配,Elasticsearch将拒绝操作并返回错误。
以下是使用if_seq_no
和if_primary_term
参数构建测试用例的步骤:
-
索引文档:首先,索引一个文档。
POST /my_index/_doc/1 { "name": "John Doe" }
-
获取文档的序列号和任期号:通过获取文档的详细信息来获取序列号(
_seq_no
)和主分片任期号(_primary_term
)。GET /my_index/_doc/1
-
尝试更新文档:使用获取到的序列号和任期号尝试更新文档。
POST /my_index/_update/1?if_seq_no=1&if_primary_term=1 { "doc": { "name": "Jane Doe" } }
在这个例子中,我们假设文档的初始序列号是1,任期号也是1。
-
并发更新:在另一个会话中,尝试使用相同的序列号和任期号更新同一个文档。
POST /my_index/_update/1?if_seq_no=1&if_primary_term=1 { "doc": { "name": "Alice Smith" } }
-
处理并发冲突:如果第一个更新操作成功,第二个更新操作将因为序列号或任期号不匹配而失败。
失败的更新操作将返回一个错误,例如:
{ "error": { "root_cause": [ { "type": "version_conflict_engine_exception", "reason": "[my_index][1]: version conflict, required seq_no [1], primary term [1]. current document has seq_no [2] and primary term [1]" } ], "type": "version_conflict_engine_exception", "reason": "[my_index][1]: version conflict, required seq_no [1], primary term [1]. current document has seq_no [2] and primary term [1]" }, "status": 409 }