在微服務(wù)架構(gòu)中，速度和效率至關(guān)重要，每一毫秒都可能產(chǎn)生巨大影響。最近，我們在一個使用 Elasticsearch 來查找商品列表的微服務(wù)上深有體會。起初，每個 Elasticsearch 查詢 大約需要 50-60 毫秒才能完成——在某些情況下還算可以，但在處理大量請求和頻繁更新時，這就成了瓶頸。即使是微小的延遲也會影響系統(tǒng)性能和用戶滿意度。

認(rèn)識到需要改進(jìn)后，我們開始進(jìn)行重大更改。我們的目標(biāo)是減少延遲，同時確保服務(wù)能夠高效地處理大量請求。經(jīng)過一系列調(diào)整和優(yōu)化 Elasticsearch 查詢 后，我們將延遲降低到 1 毫秒以下。這一重大改進(jìn)不僅使服務(wù)速度大幅提升，還增強(qiáng)了其處理大量請求的能力。

在本文中，我們將逐步介紹實現(xiàn)這一性能提升的步驟。我們將涵蓋從調(diào)整查詢到架構(gòu)更新的具體更改和策略。

1、背景介紹

在 Trendyol（阿里巴巴旗下土耳其電商平臺），我們始終關(guān)注賣家和買家，努力使國際銷售盡可能順暢高效。我的團(tuán)隊在這個過程中發(fā)揮著關(guān)鍵作用，使賣家只需點擊一下就能接觸到國際買家。這意味著賣家無需手動更新新市場的價格或庫存水平。他們可以輕松地向全球客戶銷售商品，以最小的努力開拓新的機(jī)會。

這一操作的核心是一個 微服務(wù)，負(fù)責(zé)更新國際銷售的產(chǎn)品價格。系統(tǒng)中的每個商品列表都屬于一個“內(nèi)容（content）”。當(dāng)產(chǎn)品在其他國家銷售時，必須考慮多個因素來設(shè)定正確的價格，例如賣家的貨幣和運(yùn)費(fèi)。一個詳細(xì)的算法會計算出一個“系數(shù)率（coefficient rate）”，該系數(shù)率與價格相乘以計算新價格，針對每個內(nèi)容與相應(yīng)的“店面（storefront）”（即國家），然后將此信息發(fā)送到一個 Kafka 主題。

圖片

我們的微服務(wù)監(jiān)聽該 Kafka 主題 上的更新，處理傳入的數(shù)據(jù)，并使用 Elasticsearch 查找相關(guān)的商品列表。為此，我們創(chuàng)建了一個 Elasticsearch 查詢 來找到需要根據(jù)新系數(shù)調(diào)整的相關(guān)商品列表。找到這些列表后，服務(wù)將包含系數(shù)率的修訂列表發(fā)布到另一個 Kafka 主題，在那里進(jìn)一步處理以設(shè)置新價格。

如果該系統(tǒng)出現(xiàn)任何延遲，價格更新可能無法立即應(yīng)用。這意味著價格調(diào)整可能需要更長時間才能反映出來，可能會影響一致性。因此，系統(tǒng)中的每一毫秒都很重要。

2、性能測試方法

在深入探討性能調(diào)優(yōu)細(xì)節(jié)之前，了解我們?nèi)绾螠y試和評估微服務(wù)和 Elasticsearch 查詢 的性能非常重要。為了測試，我們使用了公司內(nèi)部開發(fā)和維護(hù)的工具 Ares。Ares 使我們能夠?qū)?yīng)用程序進(jìn)行全面的負(fù)載測試，包括 Elasticsearch 查詢 和整體系統(tǒng)性能。

銘毅備注：關(guān)于性能測試工具，咱們可以使用 Elasticsearch 平替的開源方案 esrally，或者我們通用的方案：JMeter 等。

JMeter 如何實現(xiàn) Elasticsearch 8.X 性能測試？

首先，我們從生產(chǎn)環(huán)境中選擇大量樣本。通常，我們會檢索一份包含 10,000 個內(nèi)容的列表，代表我們需要測試的數(shù)據(jù)。然后，我們在測試工具中創(chuàng)建一個 Elasticsearch 任務(wù)，使用這個內(nèi)容列表。此設(shè)置有助于我們模擬真實世界的條件，并有效地對 Elasticsearch 索引施加壓力。

以下是我們用于測試的查詢示例：

{
    "query": {
        "bool": {
            "filter": [
                {
                    "term": {
                        "contentId": 10863010
                    }
                },
                {
                    "terms": {
                        "storefrontId": [
                            "50",
                            "35",
                            "36",
                            "43",
                            "48",
                            "49"
                        ]
                    }
                }
            ]
        }
    },
    "_source": [
        "storefrontId",
        "listingId"
    ],
    "sort": [
        {
            "storefrontId": "asc",
            "listingId": "asc"
        }
    ]
}

該查詢基于特定的 contentId 和一組 storefrontId 檢索文檔。它使用 bool 查詢 和 filter 子句 來選擇匹配給定內(nèi)容 ID 的文檔。此外，它過濾 storefrontId 以確保結(jié)果與目標(biāo)市場相關(guān)。

3、性能優(yōu)化策略

3.1. 減少分片數(shù)量

在 Elasticsearch 中，分片是存儲的基本單位，將索引拆分為更小的部分，使系統(tǒng)能夠在多個節(jié)點上分配數(shù)據(jù)和查詢。我們在 Elasticsearch 集群中進(jìn)行的第一個優(yōu)化是減少過多的分片數(shù)量。

最初，我們的集群有超過 100 個分片，導(dǎo)致系統(tǒng)資源的低效使用。

為了解決這個問題，我們將分片數(shù)量減少到與節(jié)點數(shù)量相匹配，這不僅降低了資源開銷，還顯著提高了查詢速度和集群穩(wěn)定性。

以下是減少分片數(shù)量后集群的分片分布情況：

圖片

3.2. 限制段數(shù)量

我們的第二個優(yōu)化是解決隨著索引操作而增加的段（segment）數(shù)量。

段是分片內(nèi)更小的不可變數(shù)據(jù)單元，隨著段的累積，搜索延遲會增加，因為 Elasticsearch 需要搜索更多的段。

為了解決這個問題，我們實施了一個段合并策略來控制并逐步減少段的數(shù)量，優(yōu)化搜索性能。

起初，我們嘗試在段數(shù)量增加時強(qiáng)制段合并，但這種方法不足以限制段數(shù)量。為了解決這個問題，我們實施了一個段合并策略來控制并逐步減少段的數(shù)量，優(yōu)化搜索性能。以下是我們應(yīng)用的策略字段：

• max_merge_at_once_explicit: "4"：控制顯式合并操作中一次可以合并的最大段數(shù)，限制為 4 可以防止在手動合并期間過度使用資源。
• max_merge_at_once: "4"：限制自動合并時一次可以合并的段數(shù)，保持在 4 以確保受控的合并，維持系統(tǒng)穩(wěn)定性。
• max_merged_segment: "30gb"：定義合并段的最大大小，限制為 30GB 可以避免創(chuàng)建過大的段，導(dǎo)致內(nèi)存和性能問題。
• segments_per_tier: "2"：限制每個合并層允許的段數(shù)，限制為 2 有助于保持較低的段數(shù)量，通過優(yōu)化 Elasticsearch 必須搜索的段數(shù)來降低搜索延遲。
• floor_segment: "20gb"：設(shè)置有資格合并的最小段大小，小于 20GB 的段將首先被合并，防止大量小段的累積，可能會降低搜索性能。

圖片

3.3. 類型轉(zhuǎn)換優(yōu)化

我們實施的下一個優(yōu)化是將用于 term 查詢 的字段類型更改為 keyword。

keyword 存儲在倒排索引中，使查找速度極快，非常適合 term 或精確匹配查詢。

鑒于我們只需要這些字段進(jìn)行精確匹配，我們決定將其轉(zhuǎn)換為 keyword 類型，并重新索引了所有文檔。

在轉(zhuǎn)換字段類型后，我們重新索引了所有文檔，并再次進(jìn)行了負(fù)載測試。

結(jié)果令人印象深刻：搜索速率飆升至每秒約 50,000 個查詢，而延遲降至 1 毫秒以下。

類型轉(zhuǎn)換前的集群性能：

圖片

類型轉(zhuǎn)換后的集群性能：

圖片

這一優(yōu)化不僅提升了查詢性能，還展示了在 Elasticsearch 中為特定查詢用例選擇正確字段類型的重要性。

3.4. 啟用請求緩存

我們實施的另一個性能改進(jìn)是啟用 Elasticsearch 集群中的 request_cache。此緩存對于處理重復(fù)查詢非常有用，例如重試或從 Kafka 多次攝取同一事件的情況。通過在索引上啟用請求緩存，我們確保了這些重復(fù)查詢的響應(yīng)時間更快。

Elasticsearch 的緩存特別有效之處在于，每當(dāng)刷新間隔觸發(fā)時，它會自動失效緩存數(shù)據(jù)，這意味著緩存的數(shù)據(jù)始終接近實時，避免了一致性問題。

盡管這可以顯著提高查詢速度，但需要考慮它可能導(dǎo)致的內(nèi)存使用增加。因此，啟用 request_cache 是一個強(qiáng)大的優(yōu)化，但應(yīng)與內(nèi)存考慮保持平衡。

要在 Elasticsearch 中為索引啟用請求緩存，可以使用以下命令：

PUT /your_index_name/_settings
{
  "index": {
    "requests.cache.enable": true
  }
}

3.5. 優(yōu)化排序

在 Elasticsearch 中查詢超過 10,000 個文檔時，我們使用了 Point In Time (PIT)。

干貨 | 全方位深度解讀 Elasticsearch 分頁查詢

PIT 允許我們通過捕獲索引在特定時刻的快照來執(zhí)行一致的搜索，確保查詢不受正在進(jìn)行的索引操作影響。所有的 PIT 搜索請求都會自動包含一個隱式的排序斷點字段 _shard_doc，有助于保持一致的分頁。如果無法使用 PIT，確保在排序子句中包含一個唯一的斷點字段至關(guān)重要，以防止分頁結(jié)果中出現(xiàn)遺漏或重復(fù)。

在我們的案例中，原始查詢按 listingId 和 storefrontId 對結(jié)果進(jìn)行排序。然而，由于我們主要關(guān)注的是避免重復(fù)，而不是使用特定的排序字段，我們從查詢中刪除了這些排序字段。

取而代之的是，我們按照建議使用 _shard_doc 對結(jié)果進(jìn)行排序。

搜索響應(yīng)中，每個命中都會包含一個排序值數(shù)組。使用 PIT 時，每個命中的最后一個排序值包含斷點 _shard_doc。該值在 PIT 的上下文中對每個文檔都是唯一的，由分片索引和 Lucene 的內(nèi)部文檔 ID 組合而成。這種方法確保我們高效地管理文檔分頁，而不會引入重復(fù)。

4、總結(jié)

通過針對性的優(yōu)化，我們將 Elasticsearch 查詢 的延遲從 50-60 毫秒降低到 1 毫秒以下，顯著提升了系統(tǒng)性能。

這些優(yōu)化包括降低分片數(shù)量、有效管理 段合并、啟用 請求緩存 和為精確查詢優(yōu)化 字段類型。

這些經(jīng)驗表明，在 Elasticsearch 中進(jìn)行針對性的優(yōu)化可以帶來速度和整體系統(tǒng)響應(yīng)能力的顯著提升。

原文地址：https://medium.com/trendyol-tech/unlocking-speed-key-optimizations-for-elasticsearch-performance-20af2cb4ac87

原文作者：Mert Oz