如何在不使用ApplicationUrl的情况下通过gsutil监听云存储对象变更

很遗憾，gsutil本身并没有原生的实时监听Cloud Storage桶对象变更的功能——它主要是用于对象存储的常规操作（上传、下载、列出等），而非持续的事件监听。不过我们可以通过两种实用的方案来实现你的需求，完美适配Linux脚本场景：

方案1：轮询检测（简单易实现） #

这是最直接的方法，通过定期执行gsutil命令对比桶内对象的状态变化，适合对实时性要求不高的场景。

实现思路： #

1. 首次运行时，记录桶内所有对象的元数据（比如修改时间、ETag、路径）到本地文件；
2. 每隔固定时间（比如1分钟）重新获取桶内对象的元数据；
3. 对比两次数据的差异，识别出新增、修改或删除的对象；
4. 根据变更执行你的脚本逻辑。

示例脚本片段： #

#!/bin/bash

BUCKET="gs://your-target-bucket"
STATE_FILE="/tmp/gcs_bucket_state.txt"

# 初始化状态文件
if [ ! -f "$STATE_FILE" ]; then
    gsutil ls -la "$BUCKET" | grep -v "PRE" | awk '{print $3, $4, $NF}' > "$STATE_FILE"
    exit 0
fi

# 获取当前桶状态
CURRENT_STATE=$(gsutil ls -la "$BUCKET" | grep -v "PRE" | awk '{print $3, $4, $NF}')

# 对比差异
DIFF=$(diff "$STATE_FILE" <(echo "$CURRENT_STATE"))

if [ -n "$DIFF" ]; then
    echo "检测到对象变更："
    echo "$DIFF"
    # 在这里添加你的业务逻辑，比如处理变更的对象
    # ...
    
    # 更新状态文件
    echo "$CURRENT_STATE" > "$STATE_FILE"
fi

你可以用cron或者watch命令让这个脚本定期执行，比如每5分钟跑一次：

*/5 * * * * /path/to/your/script.sh

方案2：结合Pub/Sub实现实时监听（高效推荐） #

如果需要低延迟的实时通知，建议使用Cloud Storage的Pub/Sub通知功能，然后在Linux脚本中订阅Pub/Sub的消息流——这比轮询更高效，也符合云原生的事件驱动模式。

步骤说明： #

1. 创建Pub/Sub主题：

gcloud pubsub topics create gcs-bucket-change-topic

2. 为桶配置Pub/Sub通知：

gsutil notification create -t gcs-bucket-change-topic -f json gs://your-target-bucket

这条命令会让桶把所有对象变更事件（新增、修改、删除）发送到指定的Pub/Sub主题。

3. 创建订阅并在脚本中拉取消息：
   先创建订阅：

gcloud pubsub subscriptions create gcs-bucket-sub --topic gcs-bucket-change-topic

然后在你的Linux脚本中，用循环持续拉取消息：

#!/bin/bash

SUBSCRIPTION="gcs-bucket-sub"

while true; do
    # 拉取消息（拉取后自动确认，如需手动确认可添加--ack-deadline参数）
    MESSAGES=$(gcloud pubsub subscriptions pull "$SUBSCRIPTION" --auto-ack --format="value(message.data)")
    
    if [ -n "$MESSAGES" ]; then
        # 解码Base64格式的消息内容（Cloud Storage的通知消息是Base64编码的JSON）
        DECODED_MSG=$(echo "$MESSAGES" | base64 -d)
        echo "收到对象变更事件："
        echo "$DECODED_MSG"
        # 在这里处理变更事件，比如解析JSON获取对象路径、变更类型等
        # ...
    fi
    
    # 短暂休眠，避免频繁请求
    sleep 1
done

优缺点对比： #

• 轮询：无需额外服务依赖，实现简单，但有延迟，且频繁调用gsutil会产生一定的API开销；
• Pub/Sub：实时性高，事件驱动更高效，但需要配置Pub/Sub服务，且需要确保脚本持续运行（可以用systemd托管脚本）。

内容的提问来源于stack exchange，提问作者Jurgen