概要
本篇主要介紹增量更新(partial update，也叫局部更新)的核心原理，介紹6.3.1版本的Elasticsearch腳本使用實例和增量更新的優勢。
增量更新過程與原理
簡單回顧
前文我們有簡單介紹過增量的語法，簡單回顧一下請求示例：
POST /music/children/1/_update
{
"doc": {
"length": "76"
}
}
一般從客戶端到Elasticsearch，完整的應用請求流程基本是這樣的：
- 客戶端先發起GET請求，獲取到document信息，展現到前端頁面上，供用戶進行編輯。
- 用戶編輯完數據后，點擊提交。
- 后台系統處理修改后的數據，並組裝好完整的document報文。
- 發送PUT請求到ES，進行全量替換。
- ES將老的document標記為deleted，然后重新創建一個新的document。
Elasticsearch的document是基於不可變模式設計的，所有的document更新，其實都創建了一個新的document出來，再把老的document標記為deleted，增量更新也不例外，只是GET全量document數據，整合新的document，替換老的document這三步操作全在一個shard里完成，毫秒級完成。
增量更新分片之間的交互
增量更新document的步驟：
- Java客戶端向ES集群發送更新請求。
- Coodinate Node收到請求，但該document不在當前node上，它將請求轉發到Node2節點的P0 shard上。
- Node 2檢索document，修改_source下的JSON，並且重新索引該document，如果有其他線程修改過該document，有版本沖突的話，會重新嘗試更新document，最大重試retry_on_conflict次，超出重試次數后放棄。
- 如果步驟3操作成功，Node2會將該document的完整內容異步轉發到Node1和Node3的replica shard，重新建立索引。一旦所有replica都返回成功，Node2返回成功消息給Coodinate Node。
- Coodinate Node響應更新成功消息給客戶端，此時ES集群內primary shard和replica shard都已經更新完成。
注意幾點：
- primary shard向replica shard進行document數據同步時，發送的是document的完整信息，因為異步請求不保證有序，如果發增量信息的話，順序錯亂會導致document內容錯誤。
- 只要Coodinate Node向Java客戶端響應成功，就表示所有的primary shard向replica shard都完成了更新操作，此時ES集群內的數據是一致的，更新是安全的。
- retry策略，ES再次獲取document數據和最新版本號，成功就更新，失敗再試，最大次數可以設置，如5次：retry_on_conflict=5
- retry策略在增量操作無關順序的場景更適用，比如說計數操作，誰先執行誰后執行，關系不大，最終結果是對的就行。其他的一些場景，如庫存的變化，賬戶余額的變化，直接更新成指定數值的，肯定不能使用retry策略，但可以轉化成加減法，如下單時由直接更新庫存數量的邏輯改成“當前可用庫存數量=庫存數量-訂單商品數量”，賬戶余額的更新加減變化的金額，這樣可以在一定程度上，把順序有關轉化成順序無關，就可以更方便的使用retry策略解決沖突的問題。
增量更新的優點
- 所有的查詢、修改和回寫操作，都是在ES內部完成的，減小了網絡數據傳輸開銷（2次），提升了性能。
- 相比全量替換的時間間隔（秒級以上），縮短了查詢和修改的時間間隔（毫秒級），可以有效降低並發沖突的情況。
使用腳本實現增量更新
Elasticsearch支持使用腳本實現更為靈活的邏輯，6.0版本以后，默認支持的腳本是painless，並且不再支持Groovy，因為Groovy編譯有一定概率會出現內存不釋放，最終導致Full GC的問題。
我們以英文兒歌的案例為背景，假設document的數據是這樣：
{
"_index": "music",
"_type": "children",
"_id": "2",
"_version": 6,
"found": true,
"_source": {
"name": "wake me, shark me",
"content": "don't let me sleep too late, gonna get up brightly early in the morning",
"language": "english",
"length": "55",
"likes": 0
}
}
內置腳本
現在有這樣一個需求：每當有人點擊播放一次歌曲時，該document的likes field就自增1，我們可以用簡單的腳本來實現：
POST /music/children/2/_update
{
"script" : "ctx._source.likes++"
}
執行一次后，再查詢該document，發現likes變成1，每執行一次，likes都自增1，結果符合預期。
外部腳本
對剛剛那個自增需求做一些改動，支持批量更新播放量，自增的數量由參數傳入，腳本也可以通過導入的方式，預先編譯存儲在ES中，使用的時候調用即可。
創建腳本
POST _scripts/music-likes
{
"script": {
"lang": "painless",
"source": "ctx._source.likes += params.new_likes"
}
}
腳本ID為music-likes，參數為new_likes，是可以在調用時傳入的。
使用腳本
我們更新時，執行如下請求，就可以調用剛剛創建的腳本
POST /music/children/2/_update
{
"script": {
"id": "music-likes",
"params": {
"new_likes": 2
}
}
}
id即創建腳本時的music-likes，params是固定寫法，里面的參數為new_likes，執行后再查看document信息，可以看到likes field的值按傳入的值進行累加，結果符合預期。
查看腳本
命令：
GET _scripts/music-likes
斜杠后面的參數即腳本ID
刪除腳本
命令：
DELETE _scripts/music-likes
斜杠后面的參數即腳本ID
腳本注意事項
- ES檢測到新腳本時，會執行腳本編譯，並將它存儲在緩存中，編譯比較耗時。
- 腳本的編寫能參數化的，就不要硬編碼，提高腳本的復用性。
- 短時間內太多的腳本編譯，如果超出了ES的承受范圍，ES直接報circuit_breaking_exception錯誤，這個范圍默認是15條/分鍾。
- 腳本緩存默認100條，默認不設過期時間，每個腳本最大字符65535字節，想自行配置的話可以改script.cache.expire、script.cache.max_size和script.max_size_in_bytes參數。
一句話，提高腳本的復用性。
upsert語法
像剛剛的案例，實現的是一個播放計數器的功能，目前這個計數器是與內容存儲在一起，如果計數器單獨存儲，可能會出現新上架的一首歌，但計數器的document可能還不存在，試圖對它做更新操作會報document_missing_exception錯誤，這種場景我們需要使用upsert語法：
POST /music/children/3/_update
{
"script" : "ctx._source.likes++",
"upsert": {
"likes": 0
}
}
如果id為3的記錄不存在，第一次請求時，執行upsert里面的JSON內容，初始化一個新文檔，ID為3，likes值為0；第二次請求時，文檔已經存在，此時做script腳本的更新操作，likes自增。
小結
本篇簡單介紹了增量更新的過程與原理，並與全量替換做了簡單的對比，針對一些簡單的計數場景，引入腳本的實現方式案例，腳本可以實現很豐富的功能，具體可以查看官網對Painless的介紹。
專注Java高並發、分布式架構，更多技術干貨分享與心得，請關注公眾號：Java架構社區
