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

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