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 Simple Message Queue (formerly MNS) queue triggers, ApsaraMQ for RocketMQ triggers, RabbitMQ triggers, ApsaraMQ for Kafka triggers, and DTS triggers.

Invocation methods

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

Invocation mode	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 on the body size to determine whether to reduce the number of aggregated messages in batch push. For more information about the limits on 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 to 10000.
Batch Push Interval: the interval at which a 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.

Examples of batch push

Example 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.
Example 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.
Example 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 on 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 sample code shows an event in CloudEvents and RawData formats. In the sample code, an Simple Message Queue (formerly MNS) queue trigger is used.

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 shows an event in 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 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 randomly 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.
Function execution error: A function failed to be executed as a result of incorrect function implementation.

FAQ

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

A: Yes.

Fault tolerance policy

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

Fault Tolerance Allowed
The system skips the request that failed to be executed after retires and proceeds to process the next request.
Fault Tolerance Prohibited
Consumption is blocked when a request fails to be executed after retries.

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. Function Compute supports the following destination services: Simple Message Queue (formerly MNS), ApsaraMQ for RocketMQ, ApsaraMQ for Kafka, and EventBridge.
If you do not enable the dead-letter queue feature, messages that exceed the maximum number of retries are discarded.

Concurrent consumption

You can use concurrent consumption threads to increase throughput. You can configure Concurrency Quota only for ApsaraMQ for 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.