如何防止同一账号多地同时登录（限制并发 Session）？

1. 引言：共享单车与账号共享的“冲突”

想象一下，你买了一辆共享单车的月卡。你骑车时，朋友也想用同一张月卡扫码。如果系统允许，那么你们可以同时使用——这对你来说是“共享”，对公司来说却是“损失”。为了防止这种情况，共享单车平台会限制：同一账号在同一时间只能在一辆车上使用。

在 Web 应用中，这种“一账号多设备同时登录”同样会带来安全风险：账号被共享、被盗后无法及时发现、难以审计。本文将带你深入理解如何实现“限制同一账号多地同时登录”，并掌握从 Session 到 Token 的多种技术方案。

2. 前置知识：为什么需要限制并发登录？

2.1 HTTP 的无状态与会话机制

HTTP 协议是无状态的——服务器不会记住两次请求之间的关系。为了让服务器认出“你是谁”，我们引入了 Session 或 Token 机制。用户登录后，服务端生成一个凭证（Session ID 或 JWT），客户端后续请求携带它，服务端据此识别用户。

2.2 并发登录的风险

如果没有限制，同一个账号可以在多个设备、多个浏览器上同时登录，这会带来：

• 账号共享：多人共用同一账号，违反用户协议
• 安全风险：账号被盗后，攻击者可同时登录，用户无法及时发现
• 审计困难：无法区分不同用户的操作，难以追溯责任

因此，限制同一账号多地同时登录，是保障系统安全和业务合规的重要手段。

3. 核心方案：如何限制并发登录？

3.1 方案一：Session + Redis 映射（传统 Session 架构）

原理

登录时将 userId → sessionId 的映射存入 Redis。新登录时，根据旧的 sessionId 销毁旧 Session，并更新映射。每次请求拦截，校验当前 Session 对应的 userId 是否与 Redis 中存储的最新 sessionId 一致。

流程

代码示例（Java + Redis 伪代码）

// 登录逻辑
public void login(String username, String password) {
    // 1. 验证用户
    User user = userService.verify(username, password);
    
    // 2. 获取旧的 sessionId
    String oldSessionId = redis.get("user:session:" + user.getId());
    if (oldSessionId != null) {
        // 3. 使旧 Session 失效
        sessionManager.invalidate(oldSessionId);
        redis.del("user:session:" + user.getId());
    }
    
    // 4. 创建新 Session
    HttpSession newSession = request.getSession();
    String newSessionId = newSession.getId();
    
    // 5. 存储新映射
    redis.set("user:session:" + user.getId(), newSessionId, 3600);
}

// 拦截器校验
public boolean preHandle(HttpServletRequest request) {
    HttpSession session = request.getSession(false);
    if (session == null) return false;
    
    String sessionId = session.getId();
    Long userId = (Long) session.getAttribute("userId");
    String storedSessionId = redis.get("user:session:" + userId);
    
    // 如果当前 sessionId 不是最新的，则踢出
    if (!sessionId.equals(storedSessionId)) {
        session.invalidate();
        return false;
    }
    return true;
}

优点：与现有 Session 机制无缝集成，实现简单。
缺点：依赖 Redis，增加架构复杂度。

3.2 方案二：Token 版本号（无状态 JWT 方案）

原理

在用户表中维护一个 token_version 字段。每次登录时，生成新 JWT 时将该版本号编码进 Token，并递增用户表的版本号。服务端验证 Token 时，比对 Token 中的版本号是否与数据库一致。

流程

1. 用户登录，服务端生成 JWT，将 token_version 放入 payload。
2. 更新用户表中的 token_version（+1）。
3. 下次请求时，服务端解析 JWT，取出其中的 token_version，与数据库中的版本号比对。
4. 若不一致，说明已有新登录，当前 Token 失效。

代码示例（Java 伪代码）

// 登录
public String login(String username, String password) {
    User user = userService.verify(username, password);
    // 更新版本号
    user.setTokenVersion(user.getTokenVersion() + 1);
    userService.update(user);
    
    // 生成 JWT，将版本号放入 payload
    String jwt = Jwts.builder()
        .setSubject(user.getId().toString())
        .claim("version", user.getTokenVersion())
        .signWith(SignatureAlgorithm.HS256, secretKey)
        .compact();
    return jwt;
}

// 拦截器校验
public boolean verify(String token) {
    Claims claims = Jwts.parser()
        .setSigningKey(secretKey)
        .parseClaimsJws(token)
        .getBody();
    
    Long userId = Long.parseLong(claims.getSubject());
    Integer tokenVersion = claims.get("version", Integer.class);
    User user = userService.getById(userId);
    
    if (!tokenVersion.equals(user.getTokenVersion())) {
        throw new TokenExpiredException("账号已在其他设备登录");
    }
    return true;
}

优点：无状态，无需 Redis，适合微服务架构。
缺点：JWT 无法主动吊销，依赖数据库查询版本号，增加了数据库访问。

3.3 方案三：登录记录 + 最大并发数（多端管理）

原理

存储 userId → [device1, device2, ...] 的映射，允许同一账号在多个设备登录，但限制最大并发数（如最多 3 个）。新设备登录时，如果超过限制，则踢出最早登录的设备。

流程

1. 每个登录生成唯一 deviceId（可基于 User-Agent + IP + 随机数）。
2. 将 deviceId 存入 Redis 的 user:devices:{userId} 有序集合（按登录时间排序）。
3. 新登录时，如果集合大小超过限制，删除最早的元素，并通知对应设备下线。

优点：灵活，可区分设备类型（PC、手机、平板），允许用户管理已登录设备。
缺点：实现复杂，需要维护设备标识和推送下线通知。

4. 方案对比

5. 实现要点与注意事项

5.1 分布式环境必须使用集中存储

• 如果使用 Session 方案，必须用 Redis 替代本地内存，否则不同节点无法共享 Session 映射。
• 如果使用 Token 版本号，数据库必须是共享的。

5.2 踢出与拒绝的选择

• 新登录踢旧：用户体验好，用户不必每次重新登录，适合大多数场景。
• 旧在线时拒绝新登录：更严格，适合安全要求高的系统（如银行、内部系统）。

5.3 避免并发竞态

同一用户短时间内多次登录（如网络重试），可能导致多次踢出操作。需加锁（如 Redis 分布式锁）保证原子性。

5.4 移动端与多端区分

如果需要 PC 和 App 同时在线，可在映射 key 中加入设备类型：user:session:{userId}:{deviceType}。

5.5 主动清理过期数据

Redis 中的映射应设置 TTL（如 Session 超时时间），防止“僵尸映射”堆积。

6. 常见误区

7. 总结：从需求到落地的核心步骤

一句话总结：限制同一账号多地登录的核心，是建立用户与活跃会话的映射，并在每次请求中验证凭证的“新鲜度”。无论选择哪种技术方案，都需考虑分布式一致性、并发安全与用户体验的平衡。