Advanced features of triggers - Function Compute - Alibaba Cloud Documentation Center

This topic describes the advanced features of triggers.

Usage notes

The advanced features described in this topic are only applicable to custom event source triggers, including MNS queue triggers, ApsaraMQ for RocketMQ triggers, RabbitMQ triggers, ApsaraMQ for Kafka trigger, and DTS triggers.

Invocation methods

Triggers for Function Compute support synchronous invocations and asynchronous invocations. The following table describes the limits of the two methods.

Invocation method	Maximum `body` size	Maximum timeout period
Synchronous invocation	32 MB	5 minutes
Asynchronous invocation	128 KB	5 minutes

Push configurations

Note

You must use the limit of the body size to determine whether to reduce the number of aggregated messages in batch push. For more information about the limits of the body size, see Invocation methods.

Batch push

After you enable batch push, you must configure the Batch Push Messages and Batch Push Interval parameters.

Batch Push Messages: the maximum number of messages that are sent for each invocation. Requests are sent only when the number of messages in the backlog reaches the specified value. Valid values: [1,10000].
Batch Push Interval: the interval at which the function is invoked. The system aggregates messages and sends the messages to Function Compute at the specified time interval. Valid values: 0 to 15. Unit: seconds. A value of 0 indicates that the messages are sent in real time.

Batch push helps you aggregate multiple events. When one of the conditions of the Batch Push Messages and Batch Push Interval parameters is met, the function is triggered and request messages are pushed to Function Compute at a time.

Example of batch push

Case 1
Batch Push Messages is set to 100 and Batch Push Interval is set to 15s. The size of each message is 1 KB. The number of messages reaches 100 in 10s. In this case, the messages are immediately sent without waiting for 15 seconds.
Case 2
Batch Push Messages is set to 100 and Batch Push Interval is set to 15s. The size of each message is 1 KB. The number of messages is 50 when the interval reaches 15s. In this case, the messages are immediately sent without waiting for the number of messages to reach 100.
Case 3
Batch Push Messages is set to 100 and Batch Push Interval is set to 15s. The size of each message is 2 KB. Invocation Method is set to Asynchronous Invocation. The number of messages reaches 100 in 10s and the size of the messages reaches 200 KB (100 x 2 KB) which exceeds the upper limit of the body size for asynchronous invocations. In this case, messages are immediately sent in two batches. 64 messages are pushed to Function Compute in the first batch and 36 messages are pushed to Function Compute in the second batch.

Push format

A push format specifies the format of data elements in the event parameter.

CloudEvents: A specification for describing event data in a common format. CloudEvents simplifies event declaration and transmission between different services and platforms.
RawData: Only the content of data fields in CloudEvents is delivered. Other metadata in the CloudEvents format is not delivered.

The following example shows the event of CloudEvents and RawData formats in MNS queue triggers in the event mode.

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"
    }
}

RawData

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

The following sample code provides an example of event in the CloudEvents and RawData formats in event streaming mode:

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"
    }
]

Retry policies

Failed function requests can be retried based on the configured retry policies. The following items describe the available retry policies:

Backoff Retry: The system retries the request up to three times. The interval between two consecutive retries ranges from 10 to 20 seconds.
Exponential Decay Retry: The default retry policy. The system retries the request up to 176 times. The time interval for each retry exponentially increases to 512s. The total retry time is 24 hours. The retry interval is 1s, 2s, 4s, 8s, 16s, 32s, 64s, 128s, 256s, and 512s. The interval of 512s is used for 167 times.

Scenarios in which retries are triggered

429 error: Requests are throttled by Function Compute. The throttling is temporary and the requests are retried.
5xx error: A function failed to be executed because of a system error in Function Compute.

FAQ

Q: Does a function execution error caused by function implementation issues trigger a retry policy?

A: No. Function Compute cannot determine the type of function execution error on the system level. Therefore, function execution errors do not trigger the retry policies.

The following two types of function retries are included:

Retries may succeed.
You can retry the requests within the function without the need to execute the retry policy.
Retries are bound to fail.
Retries are meaningless and increase the retry cost.

Fault tolerance policy

The fault tolerance policy specifies whether to ignore an error when it occurs.

Fault Tolerance Allowed
The system skips the requests that failed to be executed and retried and continues to process the next request.
Fault Tolerance Prohibited
The consumption tasks are blocked when a request fails to be executed and retried.

Dead-letter queue

You can configure dead-letter queues only when Fault Tolerance Allowed is enabled.

If you enable the dead-letter queue feature, messages that are not processed or whose maximum number of retries are reached are delivered to destination services. The destination services supported by Function Compute include MNS, ApsaraMQ for RocketMQ, ApsaraMQ for Kafka, and EventBridge. You can select different queue types based on your business requirements.
If you do not enable the dead-letter queue feature, messages whose maximum number of retries are reached are discarded.

Concurrent consumption

You can use concurrent consumption threads to increase the throughput. You can configure Concurrency Quota only for Message Queue for Apache Kafka triggers. The concurrent consumption in ApsaraMQ for Kafka must be implemented together with topic partitions. The following scenarios are included:

Topic partitions = Concurrent consumption threads: One thread consumes one topic partition.
Topic partitions > Concurrent consumption threads: Multiple concurrent consumption threads evenly consume all partitions.
Topic partitions < Concurrent consumption threads: One thread consumes one topic partition. The extra consumption threads are invalid.

Note

To ensure that your resources are fully utilized, we recommend that you select Topic partitions = Concurrent consumption threads or Topic partitions > Concurrent consumption threads.