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

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

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

1、背景介紹

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

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

圖片

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

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

2、性能測(cè)試方法

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

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

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

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

以下是我們用于測(cè)試的查詢(xún)示例：

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

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

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

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

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

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

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

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

圖片

3.2. 限制段數(shù)量

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

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

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

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

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

圖片

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

我們實(shí)施的下一個(gè)優(yōu)化是將用于 term 查詢(xún) 的字段類(lèi)型更改為 keyword。

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

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

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

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

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

圖片

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

圖片

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

3.4. 啟用請(qǐng)求緩存

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

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

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

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

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

3.5. 優(yōu)化排序

在 Elasticsearch 中查詢(xún)超過(guò) 10,000 個(gè)文檔時(shí)，我們使用了 Point In Time (PIT)。

干貨 | 全方位深度解讀 Elasticsearch 分頁(yè)查詢(xún)

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

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

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

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

4、總結(jié)

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

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

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

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

原文作者：Mert Oz