問題描述
我們有個系統設計的時候針對Hive創建表、刪除表, 需要更新ES中的一個狀態,標記是否刪除,在幾乎同時執行兩條下面的語句的時候,發現在ES 中出現表即使被創建了還是無法被查詢到的情況,針對該問題記錄下排查分析過程.
drop table if exists tmp.test_create_table;
create table if not exists tmp.test_create_table(
id int,
name string
) stored as parquet;
問題排查
查看ES數據
發現ES創建表的狀態沒有正常更新 yn 還是0
查看日志
查看日志, 截取部分關鍵信息:
ReceiverController] [4eb1c8fd7b6987ae] - 接收的hive元數據為:{"data": ...
"eventType":"DROP_TABLE" ...
ReceiverController] [d1aa226b8739d352] - 接收的hive元數據為:{"data": ...
"eventType":"CREATE_TABLE" ...
[Kafka-Consume-Thread-bigdata_aa-0] [ec812addb0bf424d] - update table data to es: ... "yn":0}
[Kafka-Consume-Thread-bigdata_aa-0] [3085b7329053aaac] - update table data to es: ... "yn":1}
日志里有幾個關鍵線索：
-
建表與刪除表的Hive元數據信息正常上報上來了
-
建表刪表事件都執行了更新數據到ES的操作， [Kafka-Consume-Thread-bigdata_aa-0] 可以看出是單線程更新ES， 所以不會存在多線程並發的問題
-
基本可以定位是在es更新這塊出問題了
看對應代碼
final TableDocBean docBean = baseSearchService.getById(id);
setValueForBean(afterColumns, docBean);
log.info("update table data to es: {}", JSON.toJSONString(docBean));
baseSearchService.update(docBean);
代碼先通過表id 獲取對應ES文檔，然后賦值 執行更新數據操作
這塊沒有看出什么問題，考慮到兩個事件同時執行時間間隔較短，采用了在代碼里Thread.sleep(1000) 睡眠下試試，發現兩條SQL語句同時執行的基本每次都成功，可以在ES搜索到.
這種操作不免讓人覺得ES里執行更新操作，肯定是有延遲的，具體為什么延遲，就需要看下ES的更新原理
更新原理
ES更新請求先將index-buffer中文檔（document）解析完成的segment寫到filesystem cache之中，這樣避免了比較損耗性能io操作，又可以使document可以被搜索 , 從index-buffer中取數據到filesystem cache中的過程叫做refresh。es默認的refresh間隔時間是1s
ES數據在更新的時候並不是在原來的數據上做修改的, 而是找到該數據的索引Id，把原來的數據刪掉，再重新插入一條，但索引id是相同的
當刪除、更新兩個操作間隔很短時間執行，上一個數據還沒有refresh 到 FileSystem Cache區域，就無法查詢，final TableDocBean docBean = baseSearchService.getById(id);
獲取不到數據，所以會導致數據更新失敗
解決方案
修改ES refresh到cache區域間隔時間:
curl -XPUT http://ip:9200/meta_es_data/_settings?pretty -d '
{
"refresh_interval" : "500ms"
}'
在每次更新操作后，休眠1s:
baseSearchService.update(docBean);
Thread.sleep(1000);
ES 請求接口有請求后強制刷新方法，但是一般用於測試，不建議線上用
setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE);
總結
- 不要忽視一個看起來貌似是一個小的問題,其背后有一定的設計、原理在里面
- 代碼關鍵處加一些有意義且清晰的日志是非常必要的, 可以提高解決問題的效率
- 排查問題就像破案,要有耐心找到一個個關鍵線索,最終破案. 現實工作中解決問題的能力非常重要