一、并發(fā)沖突處理機(jī)制剖析 ### --- 詳解并發(fā)沖突~~~ # 在電商場(chǎng)景下，工作流程為： ~~~ 讀取商品信息，包括庫(kù)存數(shù)量 ~~~ 用戶下單購(gòu)買(mǎi) ~~~ 更新商品信息，將庫(kù)存數(shù)減一 ~~~ 如果是多線程操作，就可能有多個(gè)線程并發(fā)的去執(zhí)行上述的3步驟流程， ~~~ 假如此時(shí)有兩個(gè)人都來(lái)讀取商品數(shù)據(jù)，兩個(gè)線程并發(fā)的服務(wù)于兩個(gè)人， ~~~ 同時(shí)在進(jìn)行商品庫(kù)存數(shù)據(jù)的修改。假設(shè)庫(kù)存為100件 正確的情況： ~~~ 線程A將庫(kù)存-1，設(shè)置為99件，線程B接著讀取99件，再-1，變?yōu)?8件。 ~~~ 如果A,B線程都讀取的為100件，A處理完之后修改為99件， ~~~ B處理完之后再次修改為99件，此時(shí)結(jié)果就出錯(cuò)了。 二、解決方案 ### --- 悲觀鎖~~~ 顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為被人會(huì)修改，所以每次拿數(shù)據(jù)的時(shí)候都會(huì)加鎖， ~~~ 以防別人修改，直到操作完成后，才會(huì)被別人執(zhí)行。 ~~~ 常見(jiàn)的關(guān)系型數(shù)據(jù)庫(kù)，就用到了很多這樣的機(jī)制，如行鎖，表鎖，寫(xiě)鎖，都是在操作之前加鎖。 ~~~ # 悲觀鎖的優(yōu)點(diǎn)： ~~~ 方便，直接加鎖，對(duì)外透明，不需要額外的操作。~~~ # 悲觀鎖的缺點(diǎn)： ~~~ 并發(fā)能力低，同一時(shí)間只能有一個(gè)操作。 ### --- 樂(lè)觀鎖~~~ 樂(lè)觀鎖不加鎖，每個(gè)線程都可以任意操作。 ~~~ 比如每條文檔中有一個(gè)version字段，新建文檔后為1，修改一次累加，線程A,B同時(shí)讀取到數(shù)據(jù)， ~~~ version=1，A處理完之后庫(kù)存為99，在寫(xiě)入es的時(shí)候會(huì)跟es中的版本號(hào)比較，都是1，則寫(xiě)入成功， ~~~ version=2，B處理完之后也為99，存入es時(shí)與es中的數(shù)據(jù)的版本號(hào)version=2相比，明顯不同， ~~~ 此時(shí)不會(huì)用99去更新，而是重新讀取最新的數(shù)據(jù)，再減一，變?yōu)?8，執(zhí)行上述操作寫(xiě)入。 ### --- Elasticsearch的樂(lè)觀鎖~~~ Elasticsearch的后臺(tái)都是多線程異步的，多個(gè)請(qǐng)求之間是亂序的， ~~~ 可能后修改的先到，先修改的后到。 ~~~ Elasticsearch的多線程異步并發(fā)修改是基于自己的_version版本號(hào)進(jìn)行樂(lè)觀鎖并發(fā)控制的。 ~~~ 在后修改的先到時(shí)，比較版本號(hào),版本號(hào)相同修改可以成功，而當(dāng)先修改的后到時(shí)， ~~~ 也會(huì)比較一下_version版本號(hào)，如果不相等就再次讀取新的數(shù)據(jù)修改。 ~~~ 這樣結(jié)果會(huì)就會(huì)保存為一個(gè)正確狀態(tài)刪除操作也會(huì)對(duì)這條數(shù)據(jù)的版本號(hào)加1 ~~~ 在刪除一個(gè)document之后，可以從一個(gè)側(cè)面證明，它不是立即物理刪除掉的， ~~~ 因?yàn)樗囊恍┌姹咎?hào)等信息還是保留著的。先刪除一條document， ~~~ 再重新創(chuàng)建這條document，其實(shí)會(huì)在delete version基礎(chǔ)之上，再把version號(hào)加1 ### --- es的樂(lè)觀鎖并發(fā)控制示例~~~ # 先新建一條數(shù)據(jù) PUT /test_index/_doc/4 { "test_field": "test" } ### --- 模擬兩個(gè)客戶端，都獲取到了同一條數(shù)據(jù)GET /test_index/_doc/4 ### --- 其中一個(gè)客戶端，先更新了一下這個(gè)數(shù)據(jù)， 同時(shí)帶上數(shù)據(jù)的版本號(hào)， ~~~ 確保說(shuō)，es中的數(shù)據(jù)的版本號(hào)，跟客戶端中的數(shù)據(jù)的版本號(hào)(_seq_no)是相同的，才能修改PUT /test_index/_doc/4 { "test_field": "client1 changed" } ### --- 另外一個(gè)客戶端，嘗試基于version=1的數(shù)據(jù)去進(jìn)行修改， ~~~ 同樣帶上(if_seq_no和if_primary_term)version版本號(hào)，進(jìn)行樂(lè)觀鎖的并發(fā)控制PUT /test_index/_doc/4?if_seq_no=1&if_primary_term=1 {"test_field": "client2 changed" } ### --- 樂(lè)觀鎖就成功阻止并發(fā)問(wèn)題 ~~~ 在樂(lè)觀鎖成功阻止并發(fā)問(wèn)題之后，嘗試正確的完成更新 ~~~ 重新進(jìn)行GET請(qǐng)求，得到 versionGET /test_index/_doc/4 ### --- 基于最新的數(shù)據(jù)和版本號(hào) ~~~ (以前是version 現(xiàn)在是if_seq_no和if_primary_term )，去進(jìn)行修改，修改后，帶上最新的版本號(hào)， ~~~ 可能這個(gè)步驟會(huì)需要反復(fù)執(zhí)行好幾次，才能成功， ~~~ 特別是在多線程并發(fā)更新同一條數(shù)據(jù)很頻繁的情況下PUT /test_index/_doc/4?if_seq_no=1&if_primary_term=1 { "test_field": "client2 changed" }

總結(jié)

以上是生活随笔為你收集整理的CC00045.elasticsearch——|HadoopElasticSearch.V45|——|ELK.v45|原理剖析|并发冲突处理机制剖析|的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。