最近在做日誌蒐集系統，涉及到Kafka到ES的資料解析寫入，但是Kafka的寫入效率遠遠高於ES，造成大量的資料在Kafka中積累，且ES的資料更新非常緩慢，最終造成了在Kibana中查詢的時候發現，ES中的資料有接近9個小時的資料延遲，這顯然是不可接受的。因此，必須著手優化ES的寫入效率。在儘可能不改變已有配置的情況下，寫入效率優先可以考慮以下兩點。

必須使用bulk方式提交寫入資料

一開始我們的解析器是通過單條資料的形式提交的資料，很明顯這種方式在大資料量的時候就越來越慢，因此我們必須修改為批量提交的方式。ES的bulk提交有個限制就是一次性提交的資料量不能超過15MB，因此，在考慮一次性提交多少條資料比較合適的時候，這個引數無比重要。根據分析，我們目前的資料量一次性bulk提交5000條資料比較合適，約為5-6MB的樣子。當然不是越多越好，也不是滿滿地一定要達到15MB的限制，那樣的風險太大，對於我們來講，能夠提升速率滿足需求即可。並且我們的程式優化過後能夠滿足隨時根據引數調整bulk請求數量的訊息數量大小。我們的k8s中對應的容器配置是這樣的：

可根據實際情況調整bulk queue size

bulk queue size是ES的資料處理佇列大小，由於ES在接收到資料之後需要做一些索引處理，因此需要將接收到的請求暫放到佇列中進行緩衝處理，這個佇列預設的值是根據機器的配置動態計算的，一般為200左右。為什麼說要根據實際情況來調整呢？因為預設情況下，200左右的佇列大小已經夠用，比如我們現在的情況客戶端配置的佇列大小隻有50。當然併發量實在是太大的時候，可以適當調整這個引數。需要在配置檔案 elasticsearch.yml 中增加以下配置：

其他一些臨時修改方案

主要是2個引數：index.refresh_interval 和 index.number_of_replicas 。為什麼說是臨時修改方案呢？因為這些方案需要修改索引配置，並且不能長期保持該方案執行，否則會引起穩定性的問題，必須在適當時候再調整回來。參考官方文件：https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html

參考連結：