用事件驱动处理
对象存储可以在对象发生变化时主动发出事件通知：创建、删除、恢复、复制完成、生命周期转移等动作都会产生一条事件记录，推送到消息队列或函数计算等目标。这样数据到达即触发处理，不必靠定时轮询列表接口，既降低请求量也缩短处理延迟。事件是「至少一次」投递，因此消费端必须自己处理重复。
基本信息
| 触发动作 | 创建、删除、恢复、复制、生命周期转移等 |
|---|---|
| 过滤方式 | 按前缀与后缀匹配，避免无关对象引发处理 |
| 投递目标 | 消息队列、函数计算、消息通知服务 |
| 投递语义 | 至少一次，可能重复且不保证严格顺序 |
典型使用场景
- 图片与视频处理：上传后自动转码、生成缩略图
- 数据入库：新文件落地后触发解析与索引更新
- 内容分发预热：对象创建后主动刷新边缘节点缓存
- 审计与告警：监控异常删除操作并即时通知
- 流程编排：把对象事件作为上下游系统的触发信号
事件记录关键字段
事件记录关键字段
# 事件名 : 例如对象创建完成、对象删除
# 桶与键 : 标明是哪个对象发生了变化
# 事件时间 : 用于排序与去重判断
# 版本标识 : 版本控制开启时有意义
# 请求标识 : 与访问日志关联排查时使用
# 大小与标识: 便于跳过零字节或占位对象投递语义与应对
| 特性 | 含义 | 消费端要做的事 |
|---|---|---|
| 至少一次 | 可能重复投递 | 按事件标识或键加版本去重 |
| 不保证顺序 | 同一键的多次事件可能乱序 | 用时间戳或版本比较决定是否处理 |
| 不保证必达 | 极端情况下事件可能丢失 | 关键流程保留兜底扫描任务 |
| 事件不等于数据 | 事件只含描述不含对象内容 | 需要内容时要回读对象 |
设计与运维要点
- 前缀设计要足够精确，否则无关对象会触发大量无效处理
- 一个桶可配置多条通知规则，但要核对规则之间是否有交叠
- 通知目标本身要有限流与重试策略，避免高峰期被打崩
- 处理失败的记录要留存并支持重放，不能直接丢弃
- 定期核对事件数量与对象增长量，发现偏差及时排查
把事件处理写成幂等是硬要求：重试、重复投递与人工重放都会让同一条事件被处理多次。
各实现支持的事件类型与目标类型不同，配置前以目标存储的官方文档为准，尤其是删除与生命周期相关事件的可选性。