一句话定位:RustFS 是面向 AI 时代、从零原生打造的高性能分布式对象存储,100% 兼容 S3 API,Apache 2.0 协议,底层用 Rust 构建,可作为 MinIO 的 drop-in 替代方案。
目录
- 问题背景:轮询 LIST 太笨
- 九类目标,一套机制
- 开启模块并建一个 webhook 目标
- 给桶挂通知规则
- 边界与验证
- 总结与下一步
1. 问题背景:轮询 LIST 太笨
流式处理管线里常有个尴尬环节:下游想知道"桶里是不是新来了文件",只能定时LIST然后比对。对象一多,LIST 本身就成瓶颈,还总有秒级延迟。S3 生态的标准解法是事件通知——对象一创建/删除/被访问,存储主动把事件推给外部系统。RustFS 100% 兼容 S3,这套通知机制原生可用,不用自己造轮子。
对一个 AI 训练数据管线来说,这意味着新样本一落桶,就能自动触发特征抽取或标注任务,而不是让调度器空转轮询。
2. 九类目标,一套机制
RustFS 的事件通知支持九类目标家族:webhook、Kafka、MQTT、MySQL、PostgreSQL、NATS、Redis、AMQP、Pulsar。它们背后是同一套过滤与分发逻辑,只是投递协议不同——你按现有数据基建挑一个就行,不必为了接通知另起一套消息系统。
事件家族也和 S3 对齐:对象创建(s3:ObjectCreated:*含 Put/Copy/CompleteMultipartUpload)、对象删除(s3:ObjectRemoved:*)、对象访问(s3:ObjectAccessed:Get/Head)、对象标签变更,以及生命周期/分层相关事件。用s3:ObjectCreated:*这类通配就能订阅一整个家族。
当前只接受队列(queue)配置,SNS 主题和 Lambda 函数配置暂不支持;桶规则走标准 S3
PutBucketNotificationConfigurationAPI。
3. 开启模块并建一个 webhook 目标
事件通知模块默认关闭。用环境变量开启,并建一个名为primary的 webhook 目标(目标名就是环境变量后缀的小写形式,_PRIMARY即primary):
exportRUSTFS_NOTIFY_ENABLE="true"exportRUSTFS_NOTIFY_WEBHOOK_ENABLE_PRIMARY="on"exportRUSTFS_NOTIFY_WEBHOOK_ENDPOINT_PRIMARY="https://events.example.com/rustfs"exportRUSTFS_NOTIFY_WEBHOOK_AUTH_TOKEN_PRIMARY=""exportRUSTFS_NOTIFY_WEBHOOK_QUEUE_DIR_PRIMARY="/var/lib/rustfs/notify-primary"exportRUSTFS_OUTBOUND_ALLOW_ORIGINS="https://events.example.com"改完环境变量后要重启 RustFS才生效。QUEUE_DIR是持久化投递队列目录,RustFS 写不下去时会排队而不是丢事件。生产环境如果接收端用私有 CA,配RUSTFS_NOTIFY_WEBHOOK_CLIENT_CA_PRIMARY做 mTLS 校验;别开RUSTFS_NOTIFY_WEBHOOK_SKIP_TLS_VERIFY_PRIMARY。
4. 给桶挂通知规则
目标建好后,用标准 S3PutBucketNotificationConfiguration把规则和桶关联起来。下面这条只推uploads/下.dat文件的创建和删除事件:
{"QueueConfigurations":[{"Id":"primary-uploads","QueueArn":"arn:rustfs:sqs:us-east-1:primary:webhook","Events":["s3:ObjectCreated:*","s3:ObjectRemoved:*"],"Filter":{"Key":{"FilterRules":[{"Name":"prefix","Value":"uploads/"},{"Name":"suffix","Value":".dat"}]}}}]}用 aws-cli 指向 RustFS 端点应用:
aws --endpoint-url http://localhost:9000--regionus-east-1\s3api put-bucket-notification-configuration\--bucketmy-bucket --notification-configuration file://notification.json aws --endpoint-url http://localhost:9000--regionus-east-1\s3api get-bucket-notification-configuration--bucketmy-bucket前缀和后缀过滤是大小写敏感且 AND 逻辑——uploads/且.dat才推。保存规则不等于目标已在线,必须确认模块和目标都已启用、接收端能应答健康检查、再真正传一个对象验证投递。
5. 边界与验证
几个要记牢的边界:
- 异步投递:事件进队列后由后台发送,不阻塞
PutObject;接收端临时不可达时靠QUEUE_DIR持久化重投。 - 只接受队列配置:SNS / Lambda 配置现在不收,需要走这两类的得用中间 webhook 桥接。
- 健康检查:RustFS 会对端点来源根路径发
HEAD,接收端要回 200;投递请求发到完整 endpoint,返回成功状态才算送达。 - 过滤 AND 逻辑:多个 FilterRule 之间是 AND,不是 OR。
验证时传一个匹配规则的对象,去接收端看是否收到 JSON POST;再传一个不匹配的(比如uploads/notes.txt),确认它不触发。两步都符合预期,这条通知链路才算真通。
6. 总结与下一步
RustFS 事件通知把"对象变了就触发下游"这件事变成一组环境变量加一条 S3 通知规则,不碰应用代码。九类目标让你直接复用现有 Kafka / AMQP / webhook 基建,新文件落桶即刻驱动流水线。
下一步建议:
- 从 webhook 起步,用
nc或简单 HTTP 服务接住 JSON 先验证投递,再换 Kafka/AMQP。 - 生产给
QUEUE_DIR单独挂盘,避免队列把系统盘写满。 - 多渠道通知时每个目标用独立后缀(如
_SECONDARY),ARN 里的目标名随之变化。
GitHub 仓库: GitHub 仓库 - 获取源代码、提交问题或贡献代码。
社区支持: GitHub Discussions- 与开发者交流经验和解决方案。