1、Elasticsearch 版本沖突復(fù)現(xiàn)

先讓大家直觀的看到 Elasticsearch 文檔版本沖突。

1.1 場(chǎng)景1：create 場(chǎng)景

DELETE?my-index-000001
#?執(zhí)行創(chuàng)建并寫入
PUT?my-index-000001/_create/1
{
??"@timestamp":?"2099-11-15T13:12:00",
??"message":?"GET?/search?HTTP/1.1?200?1070000",
??"user":?{
????"id":?"kimchy"
??}
}

#?再次執(zhí)行會(huì)報(bào)版本沖突錯(cuò)誤。
#?報(bào)錯(cuò)信息：[1]: version conflict, document already exists (current version [1])
PUT?my-index-000001/_create/1
{
??"@timestamp":?"2099-11-15T13:12:00",
??"message":?"GET?/search?HTTP/1.1?200?1070000",
??"user":?{
????"id":?"kimchy"
??}
}

1.2 場(chǎng)景2：批量更新場(chǎng)景模擬

模擬腳本1：循環(huán)寫入數(shù)據(jù) index.sh。

模擬腳本2：循環(huán)update_by_query 批量更新數(shù)據(jù) update.sh。

由于：寫入腳本 index.sh 比更新腳本 update.sh （執(zhí)行一次，休眠1秒）執(zhí)行要快，所以更新獲取的版本較寫入的最新版本要低，會(huì)導(dǎo)致版本沖突如下圖所示：

1.3 場(chǎng)景3：批量刪除場(chǎng)景模擬

寫入腳本 index.sh 不變。

刪除腳本 delete.sh 如下：

和更新原因一致，由于：寫入腳本 index.sh 比刪除腳本 delete.sh （執(zhí)行一次，休眠1秒）執(zhí)行要快，所以刪除獲取的版本較寫入的最新版本要低，會(huì)導(dǎo)致版本沖突如下圖所示：

2、Elasticsearch 文檔版本定義

執(zhí)行：

GET?test/_doc/1

召回結(jié)果如下：

這里的 version 代表文檔的版本。

• 當(dāng)我們?cè)?Elasticsearch 中創(chuàng)建一個(gè)新文檔時(shí)，它會(huì)為該文檔分配一個(gè)_version: 1。

• 當(dāng)我們對(duì)該文檔進(jìn)行任何后續(xù)更新（更新 update、索引 index 或刪除 delete）時(shí)，_version都會(huì)增加 1。

一句話：Elasticsearch 使用_version來鑒別文檔是否已更改。

3、Elasticsearch 文檔版本產(chǎn)生背景

試想一下，如果沒有文檔版本？當(dāng)有并發(fā)訪問會(huì)怎么辦？

前置條件：Elasticsearch 從寫入到被檢索的時(shí)間間隔是由刷新頻率 refresh_interval 設(shè)定的，該值可以更新，但默認(rèn)最快是 1 秒。

如上圖所示，假設(shè)我們有一個(gè)人們用來評(píng)價(jià) T 恤設(shè)計(jì)的網(wǎng)站。網(wǎng)站很簡(jiǎn)單，僅列出了T恤設(shè)計(jì)，允許用戶給T恤投票。如果順序投票，沒有并發(fā)請(qǐng)求，直接發(fā)起update更新沒有問題。

但是，在999累計(jì)投票數(shù)后，碰巧小明同學(xué)和小紅同學(xué)兩位同時(shí)（并發(fā)）發(fā)起投票請(qǐng)求，這時(shí)候，如果沒有版本控制，將導(dǎo)致最終結(jié)果不是預(yù)期的1001，而是1000。

所以，為了處理上述場(chǎng)景以及比上述更復(fù)雜的并發(fā)場(chǎng)景，Elasticsearch 亟需一個(gè)內(nèi)置的文檔版本控制系統(tǒng)。這就是 _version 的產(chǎn)生背景。

https://kb.objectrocket.com/elasticsearch/elasticsearch-version-history-what-it-does-and-doesnt-do-501

https://www.elastic.co/cn/blog/elasticsearch-versioning-support

4、常見的并發(fā)控制策略

并發(fā)控制可以簡(jiǎn)記為：“防止兩個(gè)或多個(gè)用戶同時(shí)編輯同一記錄而導(dǎo)致最終結(jié)果和預(yù)期不一致”。

常見的并發(fā)控制策略：悲觀鎖、樂觀鎖。

4.1 悲觀鎖

悲觀鎖，又名：悲觀并發(fā)控制，英文全稱："Pessimistic Concurrency Control"，縮寫“PCC”，是一種并發(fā)控制的方法。

• 悲觀鎖本質(zhì)：在修改數(shù)據(jù)之前先鎖定，再修改。

• 悲觀鎖優(yōu)點(diǎn)：采用先鎖定后修改的保守策略，為數(shù)據(jù)處理的安全提供了保證。

• 悲觀鎖缺點(diǎn)：加鎖會(huì)有額外的開銷，還會(huì)增加產(chǎn)生死鎖的機(jī)會(huì)。

• 悲觀鎖應(yīng)用場(chǎng)景：比較適合寫入操作比較頻繁的場(chǎng)景。

4.2 樂觀鎖

樂觀鎖，又名：樂觀并發(fā)控制，英文全稱：“Optimistic Concurrency Control”，縮寫OCC”，也是一種并發(fā)控制的方法。

• 樂觀鎖本質(zhì)：假設(shè)多用戶并發(fā)的事務(wù)在處理時(shí)不會(huì)彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分?jǐn)?shù)據(jù)。在提交數(shù)據(jù)更新之前，每個(gè)事務(wù)會(huì)先檢查在該事務(wù)讀取數(shù)據(jù)后，有沒有其他事務(wù)又修改了該數(shù)據(jù)。如果其他事務(wù)有更新的話，正在提交的事務(wù)會(huì)進(jìn)行回滾。

• 樂觀鎖優(yōu)點(diǎn)：“膽子足夠大，足夠樂觀”，直到提交的時(shí)候才去鎖定，不會(huì)產(chǎn)生任何鎖和死鎖。

• 樂觀鎖缺點(diǎn)：并發(fā)寫入會(huì)有問題，需要有沖突避免策略補(bǔ)救。

• 樂觀鎖應(yīng)用場(chǎng)景：數(shù)據(jù)競(jìng)爭(zhēng)(data race)不大、沖突較少的場(chǎng)景、比較適合讀取操作比較頻繁的場(chǎng)景，確保比其他并發(fā)控制方法（如悲觀鎖）更高的吞吐量。

這里要強(qiáng)調(diào)的是，Elasticsearch 采用的樂觀鎖的機(jī)制來處理并發(fā)問題。

Elasticsearch 樂觀鎖本質(zhì)是：沒有給數(shù)據(jù)加鎖，而是基于 version 文檔版本實(shí)現(xiàn)。每次更新或刪除數(shù)據(jù)的時(shí)候，都需要對(duì)比版本號(hào)。

5、Elasticsearch 文檔版本沖突的本質(zhì)

一句話，Elasticsearch 文檔沖突的本質(zhì)——老版本覆蓋掉了新版本。

6、如何解決或者避免 Elasticsearch 文檔版本沖突？

6.1 external 外部控制版本號(hào)

“external”——我的理解就是“簡(jiǎn)政放權(quán)”，交由外部的數(shù)據(jù)庫(kù)或者更確切的說，是寫入的數(shù)據(jù)庫(kù)或其他第三方庫(kù)來做控制。

版本號(hào)可以設(shè)置為外部值（例如，如果在數(shù)據(jù)庫(kù)中維護(hù)）。要啟用此功能，version_type應(yīng)設(shè)置為 external。

使用外部版本類型 external 時(shí)，系統(tǒng)會(huì)檢查傳遞給索引請(qǐng)求的版本號(hào)是否大于當(dāng)前存儲(chǔ)文檔的版本。

• 如果為真，也就是新版本大于已有版本，則文檔將被索引并使用新的版本號(hào)。

• 如果提供的值小于或等于存儲(chǔ)文檔的版本號(hào)，則會(huì)發(fā)生版本沖突，索引操作將失敗。

好處：不論何時(shí)，ES 中只有最新版本的數(shù)據(jù)，借助 external 相對(duì)有效的解決版本沖突問題。

實(shí)戰(zhàn)一把：

如果沒有 external，執(zhí)行如下命令：

PUT?my-index-000001/_doc/1?version=2
{
??"user":?{
????"id":?"elkbee"
??}
}

報(bào)錯(cuò)如下：

{
??"error"?:?{
????"root_cause"?:?[
??????{
????????"type"?:?"action_request_validation_exception",
????????"reason"?:?"Validation?Failed:?1:?internal?versioning?can?not?be?used?for?optimistic?concurrency?control.?Please?use?`if_seq_no`?and?`if_primary_term`?instead;"
??????}
????],
.......省略2行......
??"status"?:?400
}

啥意思呢？?jī)?nèi)部版本控制（internal）不能用于樂觀鎖，也就是直接使用 version 是不可以的。需要使用：if_seq_no 和 if_primary_term，它倆的用法，后文會(huì)有專門解讀。

如果用 external，執(zhí)行如下命令：

PUT?my-index-000001/_doc/1?version=2&version_type=external
{
??"user":?{
????"id":?"elkbee"
??}
}

執(zhí)行結(jié)果如下：

{
??"_index"?:?"my-index-000001",
??"_type"?:?"_doc",
??"_id"?:?"1",
??"_version"?:?2,
??"result"?:?"updated",
??"_shards"?:?{
????"total"?:?2,
????"successful"?:?1,
????"failed"?:?0
??},
??"_seq_no"?:?1,
??"_primary_term"?:?1
}

相比于之間沒有加 external，加上 external 后，可以實(shí)現(xiàn)基于version的文檔更新操作。

external_gt 和 external_gte的用法見官方文檔，本文不展開，原理同 external。

https://www.elastic.co/guide/en/elasticsearch/reference/8.1/docs-index_.html#index-versioning

6.2 通過if_seq_no 和 if_primary_term 唯一標(biāo)識(shí)避免沖突

索引操作（Index，動(dòng)詞）是有條件的，并且只有在對(duì)文檔的最后修改分配了由 if_seq_no 和 if_primary_term 參數(shù)指定的序列號(hào)和 primary term specified（翻譯起來拗口，索性用英文）才執(zhí)行。

如果檢測(cè)到不匹配，該操作將產(chǎn)生一個(gè) VersionConflictException 409 的狀態(tài)碼。

Step1：寫入數(shù)據(jù)

DELETE?products_001
PUT?products_001/_doc/1567
{
??"product"?:?"r2d2",
??"details"?:?"A?resourceful?astromech?droid"
}


#?查看ifseqno?和?ifprimaryterm?
GET?products_001/_doc/1567

返回：

{
??"_index"?:?"products_001",
??"_type"?:?"_doc",
??"_id"?:?"1567",
??"_version"?:?1,
??"_seq_no"?:?0,
??"_primary_term"?:?1,
??"found"?:?true,
??"_source"?:?{
????"product"?:?"r2d2",
????"details"?:?"A?resourceful?astromech?droid"
??}
}

Step2：以這種方式更新，前提是先拿到 if_seq_no 和 if_primary_term

#?模擬數(shù)據(jù)打tag?過程
PUT?products_001/_doc/1567?if_seq_no=0&if_primary_term=1
{
??"product":?"r2d2",
??"details":?"A?resourceful?astromech?droid",
??"tags":?[?"droid"?]
}


#?再獲取數(shù)據(jù)
GET?products_001/_doc/1567

返回：

{
??"_index"?:?"products_001",
??"_type"?:?"_doc",
??"_id"?:?"1567",
??"_version"?:?2,
??"_seq_no"?:?1,
??"_primary_term"?:?1,
??"found"?:?true,
??"_source"?:?{
????"product"?:?"r2d2",
????"details"?:?"A?resourceful?astromech?droid",
????"tags"?:?[
??????"droid"
????]
??}
}

step2 更新數(shù)據(jù)的時(shí)候，是在 step1 的獲取已寫入文檔的 if_seq_no=0 和 if_primary_term=1 基礎(chǔ)上完成的。

這樣能有效避免沖突。

6.3 批量更新和批量刪除忽略沖突實(shí)現(xiàn)

如下是在開篇的基礎(chǔ)上加了：conflicts=proceed。

conflicts 默認(rèn)值是終止，而 proceed 代表繼續(xù)。

POST?test/_update_by_query?conflicts=proceed
{
??"query":?{
????"match":?{
??????"name":?"update"
????}
??},
??"script":?{
????"source":?"ctx._source['foo']?=?'123ss'",
????"lang":?"painless"
??}
}

conflicts=proceed 的本質(zhì)——告訴進(jìn)程忽略沖突并繼續(xù)更新其他文檔。

開篇不會(huì)報(bào) 409 錯(cuò)誤了，但依然會(huì)有版本沖突。但，某些企業(yè)級(jí)場(chǎng)景是可以用的。

同理，delete_by_query 參數(shù)及返回結(jié)果均和 update_by_query 一致。

擴(kuò)展：?jiǎn)蝹€(gè)更新 update （區(qū)別于批量更新：update_by_query）有 retry_on_conflict 參數(shù)，可以設(shè)置沖突后重試次數(shù)。

7、關(guān)于頻繁更新帶來的性能問題

正如文章開篇演示的，并發(fā)更新或者并發(fā)刪除可能會(huì)導(dǎo)致版本沖突。

除了并發(fā)性和正確性之外，請(qǐng)注意，非常頻繁地更新文檔可能會(huì)導(dǎo)致性能下降。

如果更新了尚未寫入段（segment）的文檔，將會(huì)導(dǎo)致刷新操作。而刷新頻率越?。ㄆ髽I(yè)級(jí)咨詢我見過設(shè)置小于1s的，不推薦），勢(shì)必會(huì)導(dǎo)致寫入低效。

更多探討推薦閱讀：

https://discuss.elastic.co/t/handling-conflicts/135240/2

8、小結(jié)

從實(shí)際問題抽象出模擬腳本，讓大家看到文檔版本沖突是如何產(chǎn)生的。而后，定義了版本沖突并指出了其產(chǎn)生的背景。

接著，詳細(xì)講解了解決沖突的兩種機(jī)制：樂觀鎖、悲觀鎖。探討、驗(yàn)證了解決文檔版本沖突的幾種方案。

你有沒有遇到過本文提及的問題，如何解決的呢？歡迎留言交流。

參考

[1] https://www.anycodings.com/1questions/160352/why-bulk-update-never-conflicts-with-update-by-query-requests-in-elasticsearch

[2] https://learnku.com/articles/43867

[3] https://www.elastic.co/guide/en/elasticsearch/reference/current/optimistic-concurrency-control.html

[4] https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html#optimistic-concurrency-control-index

[5] https://www.elastic.co/guide/en/elasticsearch/reference/8.1/docs-index_.html#index-versioning

推薦閱讀

1. 如何從0到1打磨一門 Elasticsearch 線上直播課？

2. 重磅 | 死磕 Elasticsearch 方法論認(rèn)知清單（2021年國(guó)慶更新版）

3. 如何系統(tǒng)的學(xué)習(xí) Elasticsearch ？? ? ? ? ? ? ? ? ? ? ??

比同事?lián)屜纫徊綄W(xué)習(xí)進(jìn)階干貨！文章來源地址http://www.zghlxwxcb.cn/news/detail-404796.html