請求速率限制器

Solr 允許針對每個請求類型進行速率限制。每個請求類型都可以分配一個最大允許的並行活動請求數量。預設的速率限制是針對更新和搜尋實作的。

如果請求超出請求配額，則會拒絕其他傳入的請求，並傳回 HTTP 錯誤碼 429 (請求過多)。

請注意，速率限制是在實例 (JVM) 層級運作，而不是在核心或集合層級運作。規劃容量時請考慮這一點。未來計劃在此處進行更細微的執行 (SOLR-14710)。

請求的速率限制儲存區取決於該請求的唯一 Solr-Request-Type HTTP 標頭值。沒有 Solr-Request-Type 標頭的請求將被接受並處理，而沒有速率限制。「時段借用」和「保證時段」是相對於指定的速率限制儲存區定義的。

目前只有一個 Solr-Request-Type 值被識別用於速率限制：字串常值 QUERY。因此，只有指定標頭 Solr-Request-Type: QUERY 的請求才會受到速率限制 (而且在有多個請求類型受到尊重之前，其他的 Solr-Request-Type 規格根本不受速率限制，而「時段借用」和「保證時段」的概念，只有在多個請求類型之間才有意義，因此沒有實際效果)。

何時使用速率限制器

當使用者希望將請求執行緒集區的保證容量分配給特定的請求類型時，應使用速率限制器。索引和搜尋請求主要在爭奪 CPU 資源。在生產工作負載中，在高壓下，這種情況尤其明顯。目前的實作有一個查詢速率限制器，可以釋放索引的資源。

速率限制器設定

預設的速率限制器是搜尋速率限制器。因此，可以使用以下命令進行設定

curl -X POST -H 'Content-type:application/json' -d '{
  "set-ratelimiter": {
    "enabled": true,
    "guaranteedSlots":5,
    "allowedRequests":20,
    "slotBorrowingEnabled":true,
    "slotAcquisitionTimeoutInMS":70
  }
}' https://127.0.0.1:8983/api/cluster

啟用查詢速率限制器

控制查詢速率限制器的啟用。預設值為 false。

"enabled": true

最大並行請求數

允許設定在給定時間點的最大並行搜尋請求數。預設值為核心數 * 3。

"allowedRequests":20

請求槽位分配等待時間

當所有槽位都滿時，請求在被放入等待佇列之前，會等待槽位可用的時間（以毫秒為單位）。這允許請求在速率限制器的請求槽位暫時不可用時，有機會繼續進行。預設值為 -1，表示不等待。0 也表示不等待。請注意，較高的請求分配時間可能會導致較長的佇列時間，並可能導致查詢的等待時間更長。

"slotAcquisitionTimeoutInMS":70

啟用槽位借用

是否啟用槽位借用（如下所述）。預設值為 false。

此功能為實驗性功能，如果借用請求持續時間過長，可能會導致槽位被阻塞。

"slotBorrowingEnabled":true,

保證槽位

查詢速率限制器將保留的保證槽位數量，無論查詢請求的負載如何。這僅在啟用槽位借用時使用，並作為查詢速率限制器不允許其他請求類型從其配額借用槽位的閾值。預設值為允許的並行請求數 / 2。

此功能為實驗性功能，如果借用請求持續時間過長，可能會導致槽位被阻塞。

"guaranteedSlots":5,

重點

以下是使用速率限制器時需要注意的一些事項。

過度訂閱

可以為請求類型定義一個超過可用執行緒池大小的配額。Solr 不會強制執行對請求類型配額大小的規則。這樣做是為了讓使用者完全控制他們的配額分配。但是，如果配額超過了可用的執行緒池大小，執行緒池的標準佇列策略將會啟動。

槽位借用

如果一個配額沒有積壓，但其他配額有，那麼相對較不繁忙的配額可以從較繁忙的配額「借用」槽位。目前這是以循環方式進行的，未來有一項待處理任務要使其成為基於優先順序的模型 (https://issues.apache.org/jira/browse/SOLR-14709)。

此功能為實驗性功能，不保證借用的槽位會及時歸還。