erlcloud SQS 消息队列实战快速构建可靠的异步任务系统【免费下载链接】erlcloudAWS APIs library for Erlang (Amazon EC2, S3, SQS, DDB, ELB and etc)项目地址: https://gitcode.com/gh_mirrors/er/erlclouderlcloud SQS 消息队列是 Erlang 生态中最实用的 AWS 消息服务解决方案之一。本文将通过完整实战教你如何使用 erlcloud 库的 SQS 模块Amazon Simple Queue Service快速构建一套高可靠、易扩展的异步任务系统把耗时的业务操作如发邮件、生成报表、处理图片从请求链路中剥离出来让系统响应更快、更稳、更好维护。为什么用 SQS 做异步任务系统SQS 是 AWS 托管的分布式消息队列服务它的核心价值在于解耦削峰填谷瞬时高并发请求先入队消费者按自己的节奏慢慢处理避免服务被压垮天然可靠消息默认保留 4 天消费者崩溃也不丢消息处理失败可以重试无需运维不用自己搭 RabbitMQ / Kafka 集群开箱即用按量付费配合 Erlang 天生契合Erlang 的并发模型轻量进程 Actor与消息队列的消费模式简直是绝配一个消费者进程池轻松搞定任务处理erlcloud 快速安装步骤 ️erlcloud 是纯 Erlang 编写的 AWS SDKSQS 只是它支持的 30 多个 AWS 服务之一。安装方式很灵活方式一rebar3 依赖引入推荐在rebar.config中添加依赖后重新拉取即可{deps, [ {erlcloud, 3.2.15} ]}.方式二源码编译git clone https://gitcode.com/gh_mirrors/er/erlcloud cd erlcloud make编译完成后把ebin目录加入 Erlang 的代码路径就能直接使用了。核心的 SQS 实现都在 src/erlcloud_sqs.erl 中全部 API 函数都带完善的类型声明配合 IDE 提示非常友好。第一步配置 AWS 凭证 erlcloud 提供两种配置方式灵活对应不同场景方式一进程字典配置简单场景erlcloud_sqs:configure(AccessKeyID, SecretAccessKey). erlcloud_sqs:configure(AccessKeyID, SecretAccessKey, sqs.cn-north-1.amazonaws.com.cn).方式二配置对象多账号 / 跨区域场景Config erlcloud_sqs:new(AccessKeyID, SecretAccessKey), %% 之后每个调用显式传入 Config 即可这两种模式对应源码中的 configure/2,3 和 new/2,3。生产环境建议用配置对象方式避免进程字典的隐式状态带来踩坑。第二步创建 SQS 队列标准队列与 FIFO 队列erlcloud SQS 消息队列支持两种类型类型特点适用场景标准队列高吞吐、至少一次投递、可能乱序日志收集、通知发送、任务分发FIFO 队列严格有序、去重、恰好一次处理订单处理、库存扣减、审计流水创建标准队列%% 指定默认可见性超时秒0~43200 erlcloud_sqs:create_queue(order-task-queue, 30). %% 返回 #{queue_url https://sqs.../order-task-queue}创建 FIFO 队列注意名称必须以.fifo结尾erlcloud_sqs:create_fifo_queue(order-task-queue.fifo, 30).底层实现见 create_queue/3 与 create_fifo_queue/3FIFO 队列会自动附加FifoQueuetrue属性。第三步发送消息到队列 ✉️发送消息是异步任务系统的入口erlcloud 提供了非常灵活的重载%% 最简形式 erlcloud_sqs:send_message(order-task-queue, hello task). %% 带延迟投递0~900 秒 erlcloud_sqs:send_message(order-task-queue, hello task, 10). %% 带消息属性支持 String / Number / Binary 和自定义类型 erlcloud_sqs:send_message(order-task-queue, task-body, none, [{order_id, 10086}, {priority, high}]).FIFO 队列发送需要额外指定消息组 ID 和去重 IDerlcloud_sqs:send_message(order-queue.fifo, task-body, [{message_group_id, order-10086}, {message_deduplication_id, task-1}]).对应实现为 send_message/5返回message_id和md5_of_message_body供业务追踪。第四步接收并可靠处理消息 ✅接收消息是异步任务系统的核心环节也是可靠性的关键。核心参数有三个MaxNumberOfMessages单次最多拉取 1~10 条VisibilityTimeout可见性超时0~43200 秒消息被拉取后对其他消费者隐身的时间WaitTimeSeconds长轮询等待时间0~20 秒设为 20 可减少空轮询、降低成本%% 长轮询拉取消息最多 10 条可见性超时 30 秒等待 20 秒 Messages erlcloud_sqs:receive_message(order-task-queue, all, 10, 30, 20).每条消息包含body、message_id、receipt_handle等字段。处理完成的最后一步必须删除消息%% 处理业务逻辑... %% 用 receipt_handle 删除消息表示处理成功 erlcloud_sqs:delete_message(order-task-queue, ReceiptHandle).可靠性要点只有显式删除消息才会从队列移除。如果消费者崩溃或超时未删除消息会重新变得可见被其他消费者再次拉取——这正是至少一次投递 幂等处理的经典可靠模式。详见 receive_message/7 与 delete_message/3。第五步批量操作提升吞吐 高吞吐场景下逐条发送/删除会浪费大量网络往返。erlcloud 提供批量接口单次最多 10 条%% 批量发送 erlcloud_sqs:send_message_batch(order-task-queue, [{id-1, task-body-1}, {id-2, task-body-2}]). %% 返回 [{successful, [...]}, {failed, [...]}] %% 批量删除 erlcloud_sqs:delete_message_batch(order-task-queue, [{id-1, ReceiptHandle1}, {id-2, ReceiptHandle2}]).批量返回结果会区分successful和failed便于对失败条目做补偿重试。实现参考 send_message_batch/4 和 delete_message_batch/3。第六步组装完整的异步任务系统 ️有了上面的基础一个可靠的异步任务系统只需要三部分1. 生产者API 层收到请求后校验参数把任务 JSON 序列化后send_message入队立即返回已受理。2. 队列SQS作为缓冲层天然承担削峰和故障隔离。3. 消费者Worker 池用 Erlang 的进程池循环执行拉取 → 处理 → 删除%% 伪代码消费者主循环 loop(QueueName, Config) - case erlcloud_sqs:receive_message(QueueName, all, 10, 60, 20, Config) of {messages, []} - loop(QueueName, Config); %% 队列空继续轮询 {messages, Messages} - [spawn(fun() - handle_task(M, QueueName, Config) end) || M - Messages], %% 每个任务一个进程 loop(QueueName, Config) end. handle_task(M, QueueName, Config) - try process_task(M), %% 业务处理 erlcloud_sqs:delete_message(QueueName, proplists:get_value(receipt_handle, M), Config) catch _:_ - ok %% 失败不删除自动重试 end.这套模式的精髓是处理失败就不删除消息SQS 会在可见性超时后自动把消息放回队列配合ApproximateReceiveCount属性还能实现重试 N 次后进死信队列的高级玩法。常见坑与最佳实践 可见性超时设置要合理必须大于单条消息的最长处理时间否则任务还没处理完就被重新投递造成重复处理消费者要做幂等SQS 是至少一次投递业务处理必须天然幂等如用订单号做唯一约束优先使用长轮询WaitTimeSeconds20能显著减少空请求次数省成本又降延迟FIFO 队列注意去重窗口默认 5 分钟去重窗口内相同message_deduplication_id的消息会被丢弃善用批量接口单次批量 10 条吞吐提升近 10 倍代码量反而更少监控队列深度用 get_queue_attributes 定期检查approximate_number_of_messages及时扩容消费者完整的行为测试可以参考 test/erlcloud_sqs_tests.erl里面有各种参数组合的断言样例是你写业务代码前的最佳参考资料。总结 通过 erlcloud SQS 消息队列你可以在 Erlang 项目中用不到 100 行代码搭起一套生产可用的异步任务系统。它把高性能Erlang 进程并发与高可靠SQS 托管队列完美结合既不需要自建基础设施又继承了 AWS 的弹性和可用性。从简单的邮件发送到复杂的订单流水处理这套模式都能直接复用。现在就 clone 一份 erlcloud 源码动手改造你的第一个异步任务吧【免费下载链接】erlcloudAWS APIs library for Erlang (Amazon EC2, S3, SQS, DDB, ELB and etc)项目地址: https://gitcode.com/gh_mirrors/er/erlcloud创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/8/20 21:47:30 · 阅读 1.2k erlcloud SQS 消息队列实战：快速构建可靠的异步任务系统
erlcloud SQS 消息队列实战快速构建可靠的异步任务系统【免费下载链接】erlcloudAWS APIs library for Erlang (Amazon EC2, S3, SQS, DDB, ELB and etc)项目地址: https://gitcode.com/gh_mirrors/er/erlclouderlcloud SQS 消息队列是 Erlang 生态中最实用的 AWS 消息服务解决方案之一。本文将通过完整实战教你如何使用 erlcloud 库的 SQS 模块Amazon Simple Queue Service快速构建一套高可靠、易扩展的异步任务系统把耗时的业务操作如发邮件、生成报表、处理图片从请求链路中剥离出来让系统响应更快、更稳、更好维护。为什么用 SQS 做异步任务系统SQS 是 AWS 托管的分布式消息队列服务它的核心价值在于解耦削峰填谷瞬时高并发请求先入队消费者按自己的节奏慢慢处理避免服务被压垮天然可靠消息默认保留 4 天消费者崩溃也不丢消息处理失败可以重试无需运维不用自己搭 RabbitMQ / Kafka 集群开箱即用按量付费配合 Erlang 天生契合Erlang 的并发模型轻量进程 Actor与消息队列的消费模式简直是绝配一个消费者进程池轻松搞定任务处理erlcloud 快速安装步骤 ️erlcloud 是纯 Erlang 编写的 AWS SDKSQS 只是它支持的 30 多个 AWS 服务之一。安装方式很灵活方式一rebar3 依赖引入推荐在rebar.config中添加依赖后重新拉取即可{deps, [ {erlcloud, 3.2.15} ]}.方式二源码编译git clone https://gitcode.com/gh_mirrors/er/erlcloud cd erlcloud make编译完成后把ebin目录加入 Erlang 的代码路径就能直接使用了。核心的 SQS 实现都在 src/erlcloud_sqs.erl 中全部 API 函数都带完善的类型声明配合 IDE 提示非常友好。第一步配置 AWS 凭证 erlcloud 提供两种配置方式灵活对应不同场景方式一进程字典配置简单场景erlcloud_sqs:configure(AccessKeyID, SecretAccessKey). erlcloud_sqs:configure(AccessKeyID, SecretAccessKey, sqs.cn-north-1.amazonaws.com.cn).方式二配置对象多账号 / 跨区域场景Config erlcloud_sqs:new(AccessKeyID, SecretAccessKey), %% 之后每个调用显式传入 Config 即可这两种模式对应源码中的 configure/2,3 和 new/2,3。生产环境建议用配置对象方式避免进程字典的隐式状态带来踩坑。第二步创建 SQS 队列标准队列与 FIFO 队列erlcloud SQS 消息队列支持两种类型类型特点适用场景标准队列高吞吐、至少一次投递、可能乱序日志收集、通知发送、任务分发FIFO 队列严格有序、去重、恰好一次处理订单处理、库存扣减、审计流水创建标准队列%% 指定默认可见性超时秒0~43200 erlcloud_sqs:create_queue(order-task-queue, 30). %% 返回 #{queue_url https://sqs.../order-task-queue}创建 FIFO 队列注意名称必须以.fifo结尾erlcloud_sqs:create_fifo_queue(order-task-queue.fifo, 30).底层实现见 create_queue/3 与 create_fifo_queue/3FIFO 队列会自动附加FifoQueuetrue属性。第三步发送消息到队列 ✉️发送消息是异步任务系统的入口erlcloud 提供了非常灵活的重载%% 最简形式 erlcloud_sqs:send_message(order-task-queue, hello task). %% 带延迟投递0~900 秒 erlcloud_sqs:send_message(order-task-queue, hello task, 10). %% 带消息属性支持 String / Number / Binary 和自定义类型 erlcloud_sqs:send_message(order-task-queue, task-body, none, [{order_id, 10086}, {priority, high}]).FIFO 队列发送需要额外指定消息组 ID 和去重 IDerlcloud_sqs:send_message(order-queue.fifo, task-body, [{message_group_id, order-10086}, {message_deduplication_id, task-1}]).对应实现为 send_message/5返回message_id和md5_of_message_body供业务追踪。第四步接收并可靠处理消息 ✅接收消息是异步任务系统的核心环节也是可靠性的关键。核心参数有三个MaxNumberOfMessages单次最多拉取 1~10 条VisibilityTimeout可见性超时0~43200 秒消息被拉取后对其他消费者隐身的时间WaitTimeSeconds长轮询等待时间0~20 秒设为 20 可减少空轮询、降低成本%% 长轮询拉取消息最多 10 条可见性超时 30 秒等待 20 秒 Messages erlcloud_sqs:receive_message(order-task-queue, all, 10, 30, 20).每条消息包含body、message_id、receipt_handle等字段。处理完成的最后一步必须删除消息%% 处理业务逻辑... %% 用 receipt_handle 删除消息表示处理成功 erlcloud_sqs:delete_message(order-task-queue, ReceiptHandle).可靠性要点只有显式删除消息才会从队列移除。如果消费者崩溃或超时未删除消息会重新变得可见被其他消费者再次拉取——这正是至少一次投递 幂等处理的经典可靠模式。详见 receive_message/7 与 delete_message/3。第五步批量操作提升吞吐 高吞吐场景下逐条发送/删除会浪费大量网络往返。erlcloud 提供批量接口单次最多 10 条%% 批量发送 erlcloud_sqs:send_message_batch(order-task-queue, [{id-1, task-body-1}, {id-2, task-body-2}]). %% 返回 [{successful, [...]}, {failed, [...]}] %% 批量删除 erlcloud_sqs:delete_message_batch(order-task-queue, [{id-1, ReceiptHandle1}, {id-2, ReceiptHandle2}]).批量返回结果会区分successful和failed便于对失败条目做补偿重试。实现参考 send_message_batch/4 和 delete_message_batch/3。第六步组装完整的异步任务系统 ️有了上面的基础一个可靠的异步任务系统只需要三部分1. 生产者API 层收到请求后校验参数把任务 JSON 序列化后send_message入队立即返回已受理。2. 队列SQS作为缓冲层天然承担削峰和故障隔离。3. 消费者Worker 池用 Erlang 的进程池循环执行拉取 → 处理 → 删除%% 伪代码消费者主循环 loop(QueueName, Config) - case erlcloud_sqs:receive_message(QueueName, all, 10, 60, 20, Config) of {messages, []} - loop(QueueName, Config); %% 队列空继续轮询 {messages, Messages} - [spawn(fun() - handle_task(M, QueueName, Config) end) || M - Messages], %% 每个任务一个进程 loop(QueueName, Config) end. handle_task(M, QueueName, Config) - try process_task(M), %% 业务处理 erlcloud_sqs:delete_message(QueueName, proplists:get_value(receipt_handle, M), Config) catch _:_ - ok %% 失败不删除自动重试 end.这套模式的精髓是处理失败就不删除消息SQS 会在可见性超时后自动把消息放回队列配合ApproximateReceiveCount属性还能实现重试 N 次后进死信队列的高级玩法。常见坑与最佳实践 可见性超时设置要合理必须大于单条消息的最长处理时间否则任务还没处理完就被重新投递造成重复处理消费者要做幂等SQS 是至少一次投递业务处理必须天然幂等如用订单号做唯一约束优先使用长轮询WaitTimeSeconds20能显著减少空请求次数省成本又降延迟FIFO 队列注意去重窗口默认 5 分钟去重窗口内相同message_deduplication_id的消息会被丢弃善用批量接口单次批量 10 条吞吐提升近 10 倍代码量反而更少监控队列深度用 get_queue_attributes 定期检查approximate_number_of_messages及时扩容消费者完整的行为测试可以参考 test/erlcloud_sqs_tests.erl里面有各种参数组合的断言样例是你写业务代码前的最佳参考资料。总结 通过 erlcloud SQS 消息队列你可以在 Erlang 项目中用不到 100 行代码搭起一套生产可用的异步任务系统。它把高性能Erlang 进程并发与高可靠SQS 托管队列完美结合既不需要自建基础设施又继承了 AWS 的弹性和可用性。从简单的邮件发送到复杂的订单流水处理这套模式都能直接复用。现在就 clone 一份 erlcloud 源码动手改造你的第一个异步任务吧【免费下载链接】erlcloudAWS APIs library for Erlang (Amazon EC2, S3, SQS, DDB, ELB and etc)项目地址: https://gitcode.com/gh_mirrors/er/erlcloud创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考