預先擷取 Azure 服務匯流排訊息
預先擷取功能在背景將訊息擷取到本機預先擷取緩衝區中，直到達到預先擷取計數。 訊息會從緩衝區提供。 發生這種情況時，會在緩衝區中釋放空間，而接收者會在背景中預先擷取更多空間。
若要啟用預先擷取功能，請將佇列或訂閱用戶端的預先擷取計數設定為大於零的數字。 將值設定為零會關閉預先擷取。 如果功能關閉之後，預先擷取緩衝區中有訊息，應用程式會先從緩衝區接收這些訊息，然後移至服務。
在 ServiceBusReceiverOptions 和 ServiceBusProcessorOptions 物件上設定預先擷取計數屬性。
注意
JAVA 指令碼 SDK 不支援預先擷取功能。
在預先擷取緩衝區中可使用訊息時，緩衝區可以立即滿足任何後續接收到的呼叫。 緩衝區會在背景中恢復，因為空間可供使用。 如果沒有任何訊息可供傳遞，接收作業就會如預期般清空緩衝區，然後加以等候或封鎖。
為什麼預先擷取不是預設選項？
預先擷取加速訊息流程的方式為：透過應用程式要求某個訊息之前，先將訊息備妥以供本機擷取。 這個輸送量提升是應用程式作者必須明確進行取捨的結果。
您使用 eceive-and-delete 模式時，佇列將無法再使用預先擷取緩衝區取得的所有訊息。 訊息只會保留在記憶體內部預先擷取緩衝區中，直到應用程式收到訊息為止。 如果應用程式在接收到訊息之前終止，則那些訊息將會永久遺失。
您使用瞄核鎖定接收模式時，會以鎖定狀態來將擷取到預先擷取緩衝區的訊息擷取到緩衝區。 鎖定計時器會從訊息預先擷取到緩衝區的那一刻開始。 如果預先擷取緩衝區較大，而且處理花費過長的時間，導致停留於預先擷取緩衝區的訊息鎖定到期，甚至是應用程式正在處理訊息時，前述訊息鎖定到期，則可能會有一些複雜的事件需要應用程式處理。 應用程式所取得的訊息可能含有過期或即將到期的鎖定。 若是如此，應用程式可能會處理該訊息，但接著發現因為鎖定到期而無法完成訊息。 應用程式可以檢查 LockedUntilUtc 屬性，但請記住，訊息代理程式和本機電腦時鐘之間有時鍾誤差。
如果預先擷取緩衝區中的鎖定會以無訊息方式到期，則該訊息會被視為已放棄，並可再次從佇列加以擷取。 然後，訊息會再次擷取到預先擷取緩衝區並放置在結尾。若在訊息到期期間，通常無法處理預先擷取緩衝區，則系統會重複預先擷取訊息，但永遠不會以可用 (有效鎖定) 狀態有效地進行傳遞，而且最終會在超過最大傳遞計數時，將其移至無效信件佇列中。
如果應用程式明確放棄訊息，該訊息可能會再次可供從佇列中擷取。 啟用預先擷取時，訊息會再次擷取到預先擷取緩衝區，並放在結尾。 當來自預先擷取緩衝區的訊息以先出先出 (FIFO) 順序清空時，應用程式可能會依序接收訊息。 例如，應用程式可能會從緩衝區接收識別碼為 2 的訊息，然後接收識別碼為 1 的訊息 (先前已放棄)。
如果您需要進行高度可靠的訊息處理，而且處理需要相當多的工作和時間，則我們建議謹慎使用預先擷取功能，或者完全不使用。 如果您需要高輸送量且訊息處理通常很便宜，預先擷取就會產生顯著的輸送量優點。
預先擷取計數上限需要和佇列或訂用帳戶上設定的鎖定持續期間取得平衡，例如，鎖定逾時至少要超過針對預先擷取緩衝區的大小上限累積的預期訊息處理時間，再加上一個訊息。 同時，鎖定持續時間不應該太長，訊息可以在鎖定時超過其存留時間上限，這表示如果預先擷取訊息無法完成，就會被移除。
在 2026 年 9 月 30 日，我們將淘汰不符合 Azure SDK 準則的 Azure 服務匯流排 SDK 程式庫 WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus 和 com.microsoft.azure.servicebus。 我們也將結束 SBMP 通訊協定的支援，因此您將無法在 2026 年 9 月 30 日之後再使用此通訊協定。 請在該日期之前移轉至最新的 Azure SDK 程式庫，該程式庫提供重要的安全性更新和改進的功能。
雖然較舊的程式庫仍可在 2026 年 9 月 30 日之後使用，但它們將不再收到 Microsoft 的官方支援和更新。 如需詳細資訊，請參閱支援淘汰公告。