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 |
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
bodyatinge 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 |
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.
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.