[AWS] How to Use SQS as an Event Source for AWS Lambda
Lambda Trigger
一、资源收集
被动触发三个源如下。
AWS Lambda is a compute service that lets you run code without provisioning or managing servers. It enables your code to be triggered by many different event sources, including
-
- Amazon Simple Notification Service (Amazon SNS),
- Amazon Simple Store Service (Amazon S3),
- and Amazon Simple Queue Service (Amazon SQS).
二、KMS 保安全
Security first! Before you get started with Amazon SQS and Lambda, you create an AWS KMS customer master key (CMK) for the application. This key is used to configure encryption across Amazon SQS and Lambda, and ensure that all of your data is safely encrypted.
公私钥、对称非对称加密的问题。
三、创建 Standard Queue
-
先创建 “死队列”
You use a dead-letter queue to set aside transactions that couldn’t be processed.
This could happen if the messages are poorly formed or corrupted (例如 格式有问题), or the transaction reconciliation failed for some other unknown reason.
记得选上加密的 banking-key(KMS)。
-
再创建 “事务队列”
注意关键指标的理解:
Default Visibility Timeout = 30 seconds (This is the amount of time that a message is invisible so that it isn’t processed by other functions).
超过30秒 invisible,之后也就不会被处理。
Message Retention (滞留) Period = 1 day (This is the amount of time that Amazon SQS retains a message before it gets deleted).
Receive Message Wait Time = 20 seconds (This is the amount of time that a long poller waits before it returns an empty response to the function).
Ref: 基本 Amazon SQS 架构
使整个服务异步处理,不要求组件始终可用。
由于队列的分布式特性,它无法保证消息的先后顺序。也正是由于舍弃了这些特性,才得以保持了SQS的可扩展性。
从生命周期理解架构。
Ref: Amazon SQS 可见性超时
无法保证使用者实际收到消息。因此,使用者在接收和处理消息后必须从队列中删除该消息。自己动手删除,不会自动删除!
可见性超时
这是 Amazon SQS 防止其他使用者接收和处理消息的时间段。
对于标准队列,可见性超时 无法保证 不会接收消息两次。(可能会接收到两次同一个消息,所以client要自己去判断是否重复了)
终止消息的可见性超时
收到来自某个队列的某条消息时,您可能会发现,您实际上不想 “处理并删除” 该消息。(让其他组件去处理嚒)
Amazon SQS 允许您终止特定消息的可见性超时。这将使该消息对系统中的其他组件立即可见并且可用于处理。
要在调用 ReceiveMessage
后终止消息的可见性超时,请调用 ChangeMessageVisibility
并将 VisibilityTimeout
设置为 0 秒。
修改消息的可见性超时
同理 “终止消息”。
四、'Receive' Lambda 构建
Ref: 使用 AWS Lambda 【类似的中文step by step,创建和使用Lambda的精简说明】
-
Env 构建
注意权限:Policy templates。
Amazon SQS poller permissions.
AWS KMS decryption permissions.
-
Trigger 构建
做了三点:
1). 函数代码、测试代码。
2). Add trigger: 添加了SQS。
3). Environment variables: 设置了KMS。
五、'Send' Lambda --> SQS
再创建一个lambda 和 一个sqs,再加上 上面的lambda,构成 Lambda --> SQS --> Lambda。
-
首先,创建 Lambda
但这次使用 basic Lambda permissions,如下。
自动创建了role,但需要在 basic的基础上,再添加一些 policy。
-
其次,增强 role 的 policy
添加这部分policy。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "WriteToQueuePolicy", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey", "sqs:SendMessageBatch", "sqs:SendMessage" ], "Resource": [ "arn:aws:kms:us-east-1:123456789010:key/b5b22a1e-d171-2505-b516-60a67c6e28cc", "arn:aws:sqs:us-east-1:123456789010:banking-queue" ] } ] }
可见除了默认的第一个,新出现了KMS,SQS。
(添加的是 inline policy)
-
最后,添加 trigger SQS的代码
指定了sqs的http,加入boto3代码即可。
六、测试 pipeline
The banking-reconciliation-function-tester simply loops to create 100 different dynamically generated transactions and sends them to the banking-queue.
瞧瞧test之后的sqs和lambda都发生了什么: monitoring tab 的dashboard。
七、Amazon SQS 常见问题
问:Amazon SQS 与 Amazon MQ 有何不同?
如果您正在使用现有应用程序中的消息收发功能,并且想要快速轻松地将消息收发功能移至云中,我们建议您考虑使用 Amazon MQ。
如果您要在云中构建全新的应用程序,我们建议您考虑使用 Amazon SQS 和 Amazon SNS。
消息排序功能?
标准队列提供宽松的 FIFO 功能,会尽可能保持消息顺序。
但是,由于标准队列使用高度分布式架构来实现大规模扩展,因此并不能确保接收消息时严格遵循消息发送的顺序。
End.