$ s remove trigger
Need to delete the resource in the cn-shanghai area, the operation service is dev_event-handler-builtin-runtime-Kafka-trigger-example-service:
Trigger:
┌──────────────────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────┬─────────────┬───────────┐
│ functionName │ triggerName │ triggerType │ qualifier │
├──────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────┼─────────────┼───────────┤
│ dev_event-handler-builtin-runtime-Kafka-trigger-example-function │ dev_event-handler-builtin-runtime-Kafka-trigger-example-trigger │ eventbridge │ LATEST │
└──────────────────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────┴─────────────┴───────────┘
? Are you sure you want to delete these resources? yes
✔ Delete trigger dev_event-handler-builtin-runtime-Kafka-trigger-example-service/dev_event-handler-builtin-runtime-Kafka-trigger-example-function/dev_event-handler-builtin-runtime-Kafka-trigger-example-trigger success.
End of method: remove
基本信息
消息队列 Kafka ----> 事件总线 EventBridge 事件流 ----> 函数计算
并发配置
消费任务并发数
官方解释：
我的理解：通过设置 Kafka 触发器内部并发消费线程数，可以让我们直观感受到消费速度提升（如果云函数处理事件速度够快的话）。
投递并发最大值
官方解释：
我的理解：把投递理解为请求，这个参数可以理解为 Kafka 触发器向函数计算发起的请求的并发最大值。
（批量）推送配置
官方解释：
注意：
场景分析（TBD）
函数实例并发度
官方解释：
我的理解：一次请求可以发送多个事件（根据批量推送配置而定）。
各参数间关系
投递并发最大值决定了 Kafka 触发器向函数计算发起的请求的并发最大值，而是否能达到这个最大值，是由消费任务并发数决定的，Kafka 触发器内部并发消费线程数越多，越有可能达到这个最大值。如果把 Kafka 触发器向函数计算发起的请求的实际并发值，叫做实际投递并发值，那么函数计算实际创建的函数实例数为：
⌈<实际投递并发值> / <函数实例并发度>⌉而函数计算创建的函数实例数上限为：
⌈<投递并发最大值> / <函数实例并发度>⌉示例项目
这是一个使用内置运行时 go1 实现的 Event Handler，配置了 Kafka 触发器。
项目结构
本地调试
准备事件数据，我把事件保存在一个文件中，事件格式参考文档，是一个 JSON 数组：
把 Go 程序编译成二进制文件：
本地调用，省略了部分结果：
可以看到，调用成功，返回了原始输入的事件数据。
这次用 3 个事件调用看看（
s local invoke命令会在开始打印事件数据）：部署
s deploy本地调用云函数
用之前的事件数据调用部署好的云函数：
输出结果和本地调用时相差不大。
在阿里云控制台也能看到相应日志：
并发配置测试
这部分关注 3 个配置参数间的关系：
注意在下面的过程中，（Kafka 触发器）消费任务并发数一直是 1，因为源 Kafka Topic 只有 1 个分区，设置再多的消费任务并发数也是没用的。
最初的配置值是：
观察到函数计算只创建了 1 个函数实例：
删除 trigger：
在阿里云控制台重置 group
dev_test-Kafka-trigger的消费位点为 0。改变配置：
使用
s deploy命令部署。观察到函数计算创建了 2 个函数实例：
重复删除 trigger、重置消费位点、更改并发配置、部署的步骤（后面不再提及），这次的配置改为：
观察到函数计算创建了 6 个函数实例：
将配置更改为：
观察到函数计算创建了 11 个函数实例：
将配置更改为：
观察到函数计算创建了 11 个函数实例：
汇总上面的数据：
观察到在（函数）实例并发度为 2 和 1 时，函数计算创建的函数实例数不如理论上那么多，这是因为（Kafka 触发器）消费任务并发数只有 1，虽然设置了其投递并发最大值为 26，但受限于其投递能力有限（或者说函数计算处理事件速度较快），并不会给函数计算造成并发 26 个请求的压力，因此函数计算用少于理论值个数的函数实例就可以应付 Kafka 触发器的请求了。
下面我把 handler 实现改一下，处理每个事件时
time.Sleep(500 * time.Millisecond)，这样函数计算的压力就比较大了，其创建的函数实例数量就会增加。将配置更改为：
观察到函数计算创建了 13 个函数实例：
配置更改为：
观察到函数计算创建了 26 个函数实例：
汇总以上数据：
看到增加函数计算的压力，其创建的函数实例数量就会增加。且函数计算最多创建的函数实例数量遵循这个公式：
⌈<Kafka 触发器投递并发最大值> / <函数实例并发度>⌉重试和容错
重试策略
函数执行出错时可进行重试。本来函数计算同步调用是不支持重试的，但是 Kafka 等触发器支持重试。重试策略选项如下：
容错策略
当错误发生时的处理方式：
重试和容错最佳实践
TBD
参见