Todos os produtos
Search
Central de documentação

Function Compute:Advanced Trigger Features

Última atualização: Aug 04, 2026

Os gatilhos de source de eventos personalizados no Function Compute oferecem suporte a envio em lote, formatos de evento configuráveis, políticas de nova tentativa, tolerância a falhas e filas de mensagens mortas. Esses recursos controlam a entrega das mensagens à sua função e o comportamento em caso de falha.

Os recursos descritos nesta página aplicam-se apenas aos seguintes gatilhos de source de eventos personalizados: Gatilhos de fila do Simple Message Queue (anteriormente MNS) , Gatilhos do RocketMQ , Gatilhos do RabbitMQ , Gatilhos do Kafka e Gatilhos do DTS .

Métodos de invocação

Os gatilhos do Function Compute suportam dois métodos de invocação. O limite de tamanho do body determina quantas mensagens é possível agregar em uma única solicitação.

Método de invocação

**Limite de tamanho do body**

Tempo limite máximo

Invocação síncrona

32 MB

5 minutos

Invocação assíncrona

128 KB

5 minutos

Configuração de envio

Envio em lote

O envio em lote agrupa várias mensagens em uma única invocação de função, reduzindo o número de chamadas e melhorando o throughput.

Após ativar o envio em lote, configure os seguintes parâmetros:

Parâmetro

Descrição

Intervalo

Batch Push Messages

Número máximo de mensagens por invocação

1–10.000

Batch Push Interval

Intervalo de tempo entre invocações, em segundos. Defina como 0 para entrega em tempo real.

0–15 s

Funcionamento do agrupamento em lotes

O sistema envia um lote assim que qualquer uma das condições abaixo for atendida, prevalecendo a que ocorrer primeiro:

  • A quantidade de mensagens acumuladas atinge o valor definido em Batch Push Messages.

  • O Batch Push Interval expira.

  • O tamanho acumulado do body atinge o limite de invocação (32 MB para síncrona, 128 KB para assíncrona).

Exemplos

Exemplo 1 — o intervalo dispara primeiro: Defina Batch Push Messages como 100 (1 KB cada) e Batch Push Interval como 15 s. Se 50 mensagens se acumularem em 15 s, o envio ocorre imediatamente, sem aguardar 100 mensagens.

Exemplo 2 — a contagem de mensagens dispara primeiro: Com as mesmas configurações, se 100 mensagens se acumularem em 10 s, o envio ocorre imediatamente, sem esperar os 15 s.

Exemplo 3 — o limite de tamanho do body dispara primeiro (invocação assíncrona): Configure Batch Push Messages como 100 (2 KB cada), Batch Push Interval como 15 s e Invocation Method como Async Invocation. Quando 100 mensagens se acumularem em 10 s, o tamanho total será de 100 × 2 KB = 200 KB, excedendo o limite assíncrono de 128 KB. O Function Compute divide o lote automaticamente: o primeiro contém 64 mensagens e o segundo, 36 mensagens.

Formato de envio

Selecione o formato dos dados de evento entregues ao ponto de entrada da sua função.

Formato

Descrição

CloudEvents

Entrega o envelope CloudEvents completo, incluindo todos os campos de metadados. Segue a especificação CNCF CloudEvents, que padroniza dados de eventos entre serviços e plataformas.

RawData

Entrega apenas o campo data do envelope CloudEvents, sem metadados.

Os exemplos a seguir mostram o payload do evento para cada formato, usando um gatilho de fila do Simple Message Queue (anteriormente MNS) com duas mensagens.

CloudEvents

[
    {
        "id": "c2g71017-6f65-fhcf-a814-a396fc8d****",
        "source": "MNS-Function-mnstrigger",
        "specversion": "1.0",
        "type": "mns:Queue:SendMessage",
        "datacontenttype": "application/json; charset=utf-8",
        "subject": "acs:mns:cn-hangzhou:164901546557****:queues/zeus",
        "time": "2021-04-08T06:28:17.093Z",
        "aliyunaccountid": "164901546557****",
        "aliyunpublishtime": "2021-10-15T07:06:34.028Z",
        "aliyunoriginalaccountid": "164901546557****",
        "aliyuneventbusname": "MNS-Function-mnstrigger",
        "aliyunregionid": "cn-chengdu",
        "aliyunpublishaddr": "42.120.XX.XX",
        "data": {
            "requestId": "606EA3074344430D4C81****",
            "messageId": "C6DB60D1574661357FA227277445****",
            "messageBody": "TEST"
        }
    },
    {
        "id": "d2g71017-6f65-fhcf-a814-a396fc8d****",
        "source": "MNS-Function-mnstrigger",
        "specversion": "1.0",
        "type": "mns:Queue:SendMessage",
        "datacontenttype": "application/json; charset=utf-8",
        "subject": "acs:mns:cn-hangzhou:164901546557****:queues/zeus",
        "time": "2021-04-08T06:28:17.093Z",
        "aliyunaccountid": "164901546557****",
        "aliyunpublishtime": "2021-10-15T07:06:34.028Z",
        "aliyunoriginalaccountid": "164901546557****",
        "aliyuneventbusname": "MNS-Function-mnstrigger",
        "aliyunregionid": "cn-chengdu",
        "aliyunpublishaddr": "42.120.XX.XX",
        "data": {
            "requestId": "606EA3074344430D4C81****",
            "messageId": "C6DB60D1574661357FA227277445****",
            "messageBody": "TEST"
        }
    }
]

RawData

[
    {
        "requestId": "606EA3074344430D4C81****",
        "messageId": "C6DB60D1574661357FA227277445****",
        "messageBody": "TEST"
    },
    {
        "requestId": "606EA3074344430D4C81****",
        "messageId": "C6DB60D1574661357FA227277445****",
        "messageBody": "TEST"
    }
]

Políticas de nova tentativa

Quando uma solicitação falha, o Function Compute tenta executá-la novamente conforme a política de nova tentativa configurada. Há duas políticas disponíveis:

Política

Contagem de novas tentativas

Intervalos entre tentativas

Duração total das novas tentativas

Backoff Retry

3

Intervalo aleatório entre 10 s e 20 s

Exponential Decay Retry (padrão)

176

Começa em 1 s, dobra a cada intervalo até 512 s e depois mantém 512 s (167 intervalos de 512 s)

24 horas

Quando as novas tentativas são acionadas

Erro

Causa

Comportamento

HTTP 429

O Function Compute limitou a taxa da solicitação

Nova tentativa — a limitação é temporária

HTTP 5xx

Um erro de sistema do Function Compute impediu a execução da função

Nova tentativa

Perguntas frequentes

Erros de lógica da função acionam a política de nova tentativa?

Depende do método de invocação. Em invocações síncronas, erros de lógica acionam a política de nova tentativa. Já em invocações assíncronas, esses erros não acionam a política de nova tentativa no nível do gatilho; em vez disso, ativam a política específica de nova tentativa para invocações assíncronas. Para mais detalhes, consulte Políticas de nova tentativa.

Ao avaliar uma nova tentativa acionada por erro de lógica da função, considere a probabilidade de sucesso:

  • Se o erro for transitório, implemente a lógica de nova tentativa dentro da própria função em vez de depender da política no nível do gatilho.

  • Se o erro for permanente, as novas tentativas não terão êxito e apenas aumentarão o custo. Nesse caso, utilize as configurações de tolerância a falhas e fila de mensagens mortas para tratar a mensagem com falha.

Políticas de tolerância a falhas

A tolerância a falhas define o comportamento quando uma solicitação falha e todas as novas tentativas se esgotam.

Configuração

Comportamento

Fault Tolerance Allowed

Ignora a solicitação com falha e continua o processamento da próxima.

Fault Tolerance Prohibited

Bloqueia a tarefa de consumo até que a solicitação com falha seja bem-sucedida.

Fila de mensagens mortas

Uma fila de mensagens mortas (DLQ) captura mensagens não processadas após o esgotamento de todas as novas tentativas. Configure uma DLQ somente quando Fault Tolerance Allowed estiver ativado.

Configuração da DLQ

Comportamento

Enabled

Encaminha mensagens não processadas ou que excedem o limite de novas tentativas ao serviço de destino. Serviços de destino suportados: Simple Message Queue (anteriormente MNS), ApsaraMQ for RocketMQ, ApsaraMQ for Kafka e EventBridge.

Disabled

Descarta mensagens que excedem o limite de novas tentativas.

Em cenários de invocação assíncrona, se uma função encontrar um erro durante a execução, o registro de falha não vai para a fila de mensagens mortas do gatilho. O sistema o entrega ao destino de invocação assíncrona configurado no Function Compute. Para mais detalhes, consulte Callbacks de resultado .

Consumo concorrente

Aumente o throughput definindo o número de threads de consumo concorrente. Atualmente, apenas gatilhos do Kafka permitem configurar a Concurrent Quota. O consumo concorrente no ApsaraMQ for Kafka exige coordenação com as partições do tópico nos seguintes cenários:

  • Quantidade de partições do tópico = quantidade de consumos concorrentes: uma thread consome uma partição do tópico.

  • Quantidade de partições do tópico > quantidade de consumos concorrentes: vários consumidores concorrentes compartilham o consumo de todas as partições.

  • Quantidade de partições do tópico < quantidade de consumos concorrentes: uma thread consome uma partição do tópico e os consumidores excedentes ficam inativos.

Nota

Para garantir a utilização completa dos recursos, escolha cenários em que a quantidade de partições do tópico seja igual ou superior à quantidade de consumos concorrentes.