基于AWS ECS部署的Slackbot RTM接口重复执行问题及蓝绿部署咨询

针对你遇到的RTM Slackbot在ECS更新时新旧任务共存导致重复操作的问题，我整理了几个实用的解决方案，专门适配这类长连接、无流量转发的服务场景：

方案1：利用Slack RTM的连接唯一性特性 #

Slack的RTM API本身有个内置机制：同一个Bot用户如果建立新的RTM连接，Slack服务器会主动断开旧的连接。你可以在Bot代码里监听disconnect事件，一旦收到断开通知，立刻清理资源并退出进程，这样旧任务会在新任务连接成功后快速终止，大幅缩短重复运行的窗口。

举个简单的代码示例（以Python slack-sdk为例）：

from slack_sdk.rtm import RTMClient

@RTMClient.run_on(event="disconnect")
def handle_disconnect(**payload):
    print("Received disconnect signal from Slack, exiting...")
    rtm_client.stop()
    exit(0)

# 启动RTM连接
rtm_client = RTMClient(token="YOUR_BOT_TOKEN")
rtm_client.start()

这个方案不需要额外的AWS服务配置，成本最低，优先推荐尝试。

方案2：分布式锁控制单一活跃实例 #

如果Slack的内置机制不够可靠，你可以用分布式锁确保同一时间只有一个Bot实例能处理RTM消息。推荐用AWS DynamoDB或者ElastiCache Redis来实现：

• 每个Bot任务启动时，先尝试获取锁（比如在DynamoDB中写入一条带TTL的锁记录，使用条件表达式确保只有第一个写入成功的实例拿到锁）
• 拿到锁的实例正常启动RTM连接；没拿到锁的实例直接退出
• 运行中的实例定期检查锁的有效性，如果发现锁被新实例抢占，立刻断开RTM并退出

示例DynamoDB锁逻辑（Python）：

import boto3
import os
import time
import sys

dynamodb = boto3.resource('dynamodb')
lock_table = dynamodb.Table('SlackBotLocks')
BOT_ID = "my-slack-bot-id"
TASK_ID = os.environ.get("ECS_TASK_ID", "local-dev")

def acquire_lock():
    try:
        lock_table.put_item(
            Item={
                'bot_id': BOT_ID,
                'owner_task_id': TASK_ID,
                'ttl': int(time.time()) + 60  # 锁1分钟后过期
            },
            ConditionExpression='attribute_not_exists(bot_id)'
        )
        return True
    except dynamodb.meta.client.exceptions.ConditionalCheckFailedException:
        # 锁已被占用
        return False

def check_lock_periodically():
    while True:
        time.sleep(10)
        response = lock_table.get_item(Key={'bot_id': BOT_ID})
        if not response.get('Item') or response['Item']['owner_task_id'] != TASK_ID:
            print("Lock lost, exiting...")
            # 断开RTM连接并退出
            rtm_client.stop()
            sys.exit(0)

# 启动流程
if not acquire_lock():
    print("Failed to acquire lock, exiting...")
    sys.exit(0)

# 启动后台锁检查线程
import threading
lock_check_thread = threading.Thread(target=check_lock_periodically)
lock_check_thread.daemon = True
lock_check_thread.start()

# 启动RTM连接...

方案3：优化ECS服务的更新策略+自定义健康检查 #

调整ECS服务的滚动更新参数，并配合自定义健康检查，确保旧任务只有在新任务完全就绪后才会被终止：

• 在ECS服务配置中，设置maximum percent为100（同一时间最多运行期望数量的任务），minimum healthy percent为0（允许临时无健康任务，但我们通过自定义检查控制顺序）
• 给Bot添加自定义健康检查逻辑：新任务启动并成功建立RTM连接、获取锁后，向ECS报告健康状态（比如写入特定的本地文件，或者发送CloudWatch自定义指标）
• 配置ECS服务的健康检查为检查这个自定义状态，只有当新任务标记为健康后，ECS才会终止旧任务

这样就能严格控制新旧任务的切换顺序，避免重叠运行。

方案4：主动通知旧任务终止 #

在新任务启动成功后，主动向旧任务发送终止信号，让它立刻停止RTM监听。可以用以下两种方式实现：

• 利用ECS任务元数据+AWS SNS：新任务启动后，通过ECS任务元数据API获取当前服务的所有运行中任务，然后给旧任务发送SNS消息，旧任务订阅SNS主题，收到终止消息后退出
• 监听ECS服务事件：用AWS EventBridge监听ECS服务的任务启动事件，触发Lambda函数向旧任务发送终止指令（比如通过ECS ExecuteCommand执行退出命令）

这个方案需要额外的AWS服务配置，但能精准控制旧任务的终止时机。

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