快速入門：達到電子郵件傳送層限制時擲回例外狀況

發行項
04/28/2024

在本快速入門中，您將會了解如何使用我們的電子郵件 SDK，在達到電子郵件傳送層限制時擲回例外狀況。

達到電子郵件傳送層限制時擲回例外狀況

電子郵件 API 對於您可以傳送的電子郵件訊息數目限制會進行節流。電子郵件傳送有每分鐘和每小時適用的限制，如 API 節流和逾時中所述。當您達到這些限制時，後續以 SendAsync 呼叫傳送的電子郵件會收到錯誤回應「429：太多要求」。根據預設，SDK 會設定為在等候一段時間後重試這些要求。建議您使用 Azure SDK 設定記錄，以擷取這些回應碼。

或者，您可以手動定義自訂原則：

using Azure.Core.Pipeline;

public class Catch429Policy : HttpPipelineSynchronousPolicy
{
    public override void OnReceivedResponse(HttpMessage message)
    {
        if (message.Response.Status == 429)
        {
            throw new Exception(message.Response);
        }
        else
        {
            base.OnReceivedResponse(message);
        }
    }
}

將此原則新增至您的電子郵件用戶端，以確保 429 回應碼擲回例外狀況，而不是重試。

EmailClientOptions emailClientOptions = new EmailClientOptions();
emailClientOptions.AddPolicy(new Catch429Policy(), HttpPipelinePosition.PerRetry);

EmailClient emailClient = new EmailClient(connectionString, emailClientOptions);

達到電子郵件傳送層限制時擲回例外狀況

電子郵件 API 對於您可以傳送的電子郵件訊息數目限制會進行節流。電子郵件傳送有每分鐘和每小時適用的限制，如 API 節流和逾時中所述。當您達到這些限制時，後續以 send 呼叫傳送的電子郵件會收到錯誤回應「429：太多要求」。根據預設，SDK 會設定為在等候一段時間後重試這些要求。建議您使用 Azure SDK 設定記錄，以擷取這些回應碼。

有每分鐘和每小時限制您可以使用 Azure 通訊電子郵件服務傳送的電子郵件數量。當您達到這些限制時，任何進一步 beginSend 呼叫都會收到 429: Too Many Requests 回應。根據預設，SDK 會設定為在等候一段時間後重試這些要求。建議您使用 Azure SDK 設定記錄，以擷取這些回應碼。

或者，您可以手動定義自訂原則：

const catch429Policy = {
  name: "catch429Policy",
  async sendRequest(request, next) {
    const response = await next(request);
    if (response.status === 429) {
      throw new Error(response);
    }
    return response;
  }
};

將此原則新增至您的電子郵件用戶端，以確保 429 回應碼擲回例外狀況，而不是重試。

const clientOptions = {
  additionalPolicies: [
    {
      policy: catch429Policy,
      position: "perRetry"
    }
  ]
}

const emailClient = new EmailClient(connectionString, clientOptions);

達到電子郵件傳送層限制時擲回例外狀況

電子郵件 API 對於您可以傳送的電子郵件訊息數目限制會進行節流。電子郵件傳送有每分鐘和每小時適用的限制，如 API 節流和逾時中所述。當您達到這些限制時，後續以 beginSend 呼叫傳送的電子郵件會收到錯誤回應「429：太多要求」。根據預設，SDK 會設定為在等候一段時間後重試這些要求。建議您使用 Azure SDK 設定記錄，以擷取這些回應碼。

或者，您可以手動定義自訂原則：

import com.azure.core.http.HttpResponse;
import com.azure.core.http.policy.ExponentialBackoff;

public class CustomStrategy extends ExponentialBackoff {
    @Override
    public boolean shouldRetry(HttpResponse httpResponse) {
        int code = httpResponse.getStatusCode();

        if (code == HTTP_STATUS_TOO_MANY_REQUESTS) {
            throw new RuntimeException(httpResponse);
        }
        else {
            return super.shouldRetry(httpResponse);
        }
    }
}

將此重試原則新增至您的電子郵件用戶端，以確保 429 回應碼擲回例外狀況，而不是重試。

import com.azure.core.http.policy.RetryPolicy;

EmailClient emailClient = new EmailClientBuilder()
    .connectionString(connectionString)
    .retryPolicy(new RetryPolicy(new CustomStrategy()))
    .buildClient();

達到電子郵件傳送層限制時擲回例外狀況

或者，您可以手動定義自訂原則，以確保 429 回應碼擲回例外狀況，而不是重試。

def callback(response):
    if response.http_response.status_code == 429:
        raise Exception(response.http_response)

email_client = EmailClient.from_connection_string(<connection_string>, raw_response_hook=callback)

疑難排解

電子郵件傳遞

若要針對與電子郵件傳遞相關的問題進行疑難排解，您可以取得電子郵件傳遞的狀態以擷取傳遞的詳細資料。

重要

輪詢傳送作業狀態所傳回的成功結果只會驗證已成功傳送電子郵件以傳遞的事實。若要取得收件者端傳遞狀態的其他資訊，您必須參考如何處理電子郵件事件。

電子郵件節流

如果您看到應用程式已停止回應，可能是因為電子郵件傳送受到節流處理。您可以透過記錄或實作自訂原則來處理此作業。

注意

此沙箱設定是為了協助開發人員開始建置應用程式。一旦應用程式準備好上線，您便可以逐漸要求增加傳送量。如果您需要傳送超過比率限制的郵件訊息量，請提交支援要求來提高您想要的傳送限制量。

清除 Azure 通訊服務資源

如果您想要清除並移除通訊服務訂用帳戶，您可以刪除資源或資源群組。刪除資源群組也會刪除與其相關聯的任何其他資源。深入了解如何清除資源。

下一步

在本快速入門中，您已了解如何使用 Azure 通訊服務在傳送電子郵件時手動輪詢狀態。

您可能也會想要：