Go语言Gin框架实现基于Redis的在线用户统计-Golang-PHP中文网

redis的set不适合直接存在线用户状态，因其无法对集合成员单独设ttl，sadd与expire非原子导致过期残留或并发丢数据，且keys扫描阻塞、高频scard拖慢接口；必须用lua脚本或中间件+定时续期保障原子性与可靠性。

go语言gin框架实现基于redis的在线用户统计

为什么 `redis.Set` 不适合存在线用户状态

直接用 redis.Set 存用户 ID 会导致重复写入、无法自动过期、查总数还得 SCARD —— 看似简单，实际漏掉心跳续期和并发冲突。在线用户本质是「有活跃信号的去重集合」，得靠带 TTL 的键 + 原子操作兜底。

推荐方案：每个用户用一个带过期时间的 string 键，例如 online:user:123，值任意（如时间戳），TTL 设为 30 秒；再用 redis.Keys 扫描统计？不行 —— KEYS 阻塞 Redis，线上禁用。改用 redis.Scan 迭代，但 Gin 请求里不能每秒都扫一遍。

真正可行的是：用 redis.PFAdd（HyperLogLog）做去重基数估算，误差率 0.81%，但不支持查具体用户
更实用的是：用 redis.SAdd + redis.Expire 组合，把用户 ID 写进一个 set，每次请求前先 EXPIRE 延长 TTL，最后用 SCARD 拿总数
注意 SAdd 是原子的，但 EXPIRE 要配合 SETEX 或分两步加锁？其实不用 —— 先 SADD online:users 123，再 EXPIRE online:users 300 即可，set 本身不自动过期，但整个 key 可设 TTL

Gin 中间件里怎么安全更新用户在线状态

别在每个 handler 里手写 redis.SAdd 和 redis.Expire，容易漏、难维护。中间件统一处理最稳，但要注意：中间件执行时机在路由匹配后、handler 前，此时你可能还没拿到用户 ID。

典型结构是登录后把 user_id 放进 context 或 cookie，中间件从 c.Get("user_id") 或 c.Cookie("uid") 提取。示例代码片段：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

func OnlineUserMiddleware(rdb *redis.Client) gin.HandlerFunc {
    return func(c *gin.Context) {
        uid, exists := c.Get("user_id")
        if !exists {
            c.Next()
            return
        }
        userID := fmt.Sprintf("%v", uid)
        // 写入 set 并设置过期（注意：EXPIRE 对整个 key 生效，不是对 member）
        _, err := rdb.SAdd(context.Background(), "online:users", userID).Result()
        if err != nil {
            log.Printf("redis SAdd failed: %v", err)
        }
        // 重置 TTL，避免 key 被删，但不要每次都调 EXPIRE（开销大），可加条件：比如每 15 秒续一次
        now := time.Now().Unix()
        lastRenew, _ := c.Get("last_renew_time")
        if lastRenew == nil || now - lastRenew.(int64) > 15 {
            rdb.Expire(context.Background(), "online:users", 300*time.Second)
            c.Set("last_renew_time", now)
        }
        c.Next()
    }
}

别用 SETEX 替代 SAdd + Expire —— SETEX 只适用于 string 类型，set 类型必须分开操作
如果用户登出，记得显式 SRem online:users {userID}，否则要等 300 秒自动消失
并发高时，SAdd 本身幂等，没问题；但 Expire 多次调用也没副作用

怎么查实时在线人数又不拖慢接口

别在 HTTP 接口里跑 SCARD online:users 就完事 —— 看似快，但 Redis 单线程，高频查询会排队。尤其当你的 /api/status 接口每秒被调几百次，SCARD 就成了瓶颈。

正确做法：用 Redis 的发布订阅机制，或本地缓存 + 定时刷新。更轻量的是加一层内存缓存，比如用 sync.Map 存最近一次 SCARD 结果，每 2 秒异步更新一次：

var onlineCount int64
go func() {
    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()
    for range ticker.C {
        cnt, _ := rdb.SCard(context.Background(), "online:users").Result()
        atomic.StoreInt64(&onlineCount, cnt)
    }
}()

对外提供 /api/online 返回 atomic.LoadInt64(&onlineCount)，毫秒级响应
如果允许误差，甚至可以只在用户上线/下线时增减计数器（用 INCRBY / DECRBY），但要注意分布式环境下 SAdd 成功但计数器失败的情况，需补偿
别依赖 INFO keyspace 查 online:users 的 length 字段 —— 这个字段不实时，且非公开协议

Redis 连接池和超时配置不设对，统计就不可靠

很多线上问题不是逻辑错，是 redis.Options 里 PoolSize 太小、MinIdleConns 为 0、Timeout 设成 5 秒导致请求卡住。Gin 默认每个请求走独立 goroutine，Redis 连接不够时会阻塞等待，最终在线数“看起来掉线”，其实是请求超时没写进去。