如何在时间窗口内处理单个资源更新并解决并发重复问题？

这个问题本质是分布式环境下的竞态条件——你原来的“读上次处理时间→判断时间差→处理请求→更新时间”是拆分的非原子操作，并发请求很容易同时读到旧的时间记录，导致重复处理。下面给你几个落地性很强的解决方案，按推荐度排序：

1. 用Redis Lua脚本实现原子判断+更新（最推荐） #

Redis执行Lua脚本是原子性的——整个脚本执行期间不会被其他命令打断，完美解决竞态问题。你可以把“检查时间窗口+更新处理时间”的逻辑塞进一个Lua脚本里，一次性完成。

示例Lua脚本（支持毫秒级时间戳）：

-- 参数说明：
-- KEYS[1] = 存储该resourceId上次处理时间的key，比如 "resource:123:last_processed"
-- ARGV[1] = 当前时间戳（毫秒），比如 1699999999000
-- ARGV[2] = 时间窗口阈值（毫秒），比如 10000（10秒）
local last_processed = redis.call('GET', KEYS[1])
-- 如果没有历史记录，或者当前时间与上次处理时间差超过窗口阈值
if not last_processed or tonumber(ARGV[1]) - tonumber(last_processed) > tonumber(ARGV[2]) then
    -- 更新上次处理时间为当前时间
    redis.call('SET', KEYS[1], ARGV[1])
    return 1 -- 返回1表示允许处理该请求
else
    return 0 -- 返回0表示跳过该请求
end

使用方式：

• 收到请求时，生成当前毫秒级时间戳
• 调用Redis的EVAL命令执行这个脚本，传入对应的key、时间戳、窗口阈值
• 如果返回1，就处理请求；返回0直接丢弃即可

注意事项：Redis集群环境下，要确保同一个resourceId对应的key落在同一个节点——只要你的key命名格式统一（比如resource:{id}:last_processed），Redis会根据key的哈希值分配槽位，同一个id的key必然在同一个节点，保证脚本原子性生效。

2. 用Redis分布式锁（NX+EX）控制并发 #

如果不想用Lua脚本，也可以通过分布式锁让同一resourceId的请求“排队”进入判断逻辑。

具体步骤：

1. 收到请求时，尝试给该resourceId加锁：

   SET resource:{id}:lock "processing" NX EX 15
   

   • NX表示只有当key不存在时才设置成功（加锁成功）
   • EX 15表示锁自动过期时间为15秒（要比你的10秒窗口长一点，避免处理过程中锁提前过期）
2. 如果加锁成功（返回OK）：
   • 读取该resourceId的上次处理时间，判断是否超过窗口阈值
   • 若符合条件，处理请求并更新上次处理时间
   • 处理完成后可以主动调用DEL resource:{id}:lock释放锁，也可以等锁自动过期（避免异常场景下锁无法释放）
3. 如果加锁失败（返回nil），直接跳过该请求

优缺点：逻辑比Lua脚本稍复杂，但也能解决问题。需要注意锁的过期时间设置——太短可能导致处理未完成锁就释放，太长则可能在进程挂掉后锁长时间占用资源。

额外小提示 #

• 一定要用毫秒级时间戳，因为你的请求间隔是毫秒级的，秒级时间戳精度不够
• 可以把时间窗口阈值做成可配置的，方便后续调整

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