简介JSP开发中同一账号同一时间仅允许登录一次是常见的账户安全需求这份轻量级示例工程基于Session机制和过滤器实现面向Java Web开发人员适合需要快速掌握单点登录或会话唯一性控制的中初级学习者。rar压缩包共35个文件大小仅351KB包含4个JSP页面、6个Java源文件及对应class文件、15个tld标签库描述、2个jar依赖库与相关XML配置文件目录结构清晰可直接借鉴其代码组织方式。已有1407人学习下载是一份经过实践检验的参考案例。其中不仅演示了登录时创建Session、通过Filter拦截请求并校验重复登录的完整流程还涉及多线程并发控制、Session超时设置、防会话劫持等安全细节同时给出向OAuth2、JWT等更高级认证机制过渡的思路能帮助读者从基础到进阶理解Web登录状态的工程化设计。 很多产品的PRD里对单端登录的需求描述通常只有一句话同一个账号同一时间只能允许他登录一次。这句话看着简单真正落到后端实现我们会发现它牵扯出一连串的问题新设备登录时旧设备要不要被踢怎么判断同一时间Web端和App端算不算同一个端被顶下去的设备能不能第一时间收到通知这些问题没讨论清楚就直接写代码返工是大概率事件。这篇文章我从后端视角把这块需求完整拆一遍从需求定义、存储选型、Redis互踢的落地思路、Session与JWT方案的取舍到那些不踩一遍根本发现不了的坑尽量讲透。无论你是刚接手一个要加单设备登录的系统还是想把自己项目的登录体系做得更稳这篇都适用。1. 先把需求拆明白踢旧、拒新还是一场业务规则的排列组合1.1 第二个设备登录时到底要发生什么当第二个设备发起登录时系统是让新设备直接踢掉旧设备还是直接拒绝新设备这是第一个要拍板的问题两种模式对应完全不同的用户心智。互踢模式新设备登录成功后旧设备的下一次请求失效旧设备被强制下线。适合账号安全敏感、需要快速抢占会话的场景网银、企业后台、视频会员基本都是这种。拒绝模式账号已经在线时新设备登录直接报账号已在其他设备登录请先退出后再登录。适合单账号强绑定单设备的场景比如某些私有化部署的终端系统。不要以为选互踢就完事了还接着有一堆问题旧设备被踢后要不要有明确提示提示文案是您的账号已在其他设备登录还是登录已过期如果用户同时在电脑和手机上用同一个账号这是不是违规这些都属于需求边界不敲定清楚demo写完一定会返工。1.2 同一时间在工程上如何定义HTTP协议是无状态的后端其实判断不了用户此时此刻是否正在使用某个设备。我们能做的是判断当前请求携带的凭证是否还处于有效状态。所以同一时间只能登录一次在工程上被拆成两个可以判定的问题当前请求携带的token是否还没过期这个token是不是该账号最新签发的那一个只要这两个问题都通过就认定该请求合法如果旧设备还在用旧token第2个问题就过不去。整个单端登录设计的核心就是服务端必须能回答哪个token是最新的这决定了我们必须在服务端保存一份会话状态而不是天真地以为靠客户端传参就能完成互踢。1.3 动手前必须和产品确认的四个问题我强烈建议开发在排期前就把下面几个问题扔给产品确认否则写完后端接口再改规则成本很高一个账号最多同时允许几个端在线是全平台只能一个还是手机端一个、Web端一个新登录请求是互踢还是拒绝如果新设备登录失败要不要提供强制上线的二次确认被踢的设备需不需要收到实时通知通知到什么程度后台需不需要有强制下线某个用户的管理功能这些问题不敲定后面的数据结构和接口设计都会乱。我见过一个项目上线第二周运营就反馈用户在电脑上工作到一半被手机登录顶掉了就是因为当初没确认互踢粒度把App端互斥、Web端不互斥的需求误做成了全平台互斥。2. 存储模型怎么选一张表还是Redis直接影响后续所有逻辑2.1 简单系统的数据库方案用户表加token字段如果业务规模不大、并发量低最朴素的做法是直接在user表上加会话字段current_token当前有效tokentoken_expire_timetoken过期时间last_login_time最近登录时间登录时后台生成一个新token用UPDATE把这个用户的current_token覆盖掉同时刷新过期时间。请求进来时接口按token查询用户比对current_token是否一致。这个方案很直白几十个并发的小系统完全够用。但它的毛病也藏不住每次请求都要查一次user表token量大的时候还得给token列建索引token过期了也没法自动清理得靠定时任务扫后面要区分多端的话一张表里的字段会越加越多。有人会想那我给current_token加个唯一索引让数据库天然保证唯一token不就行了这个思路方向对但实操很痛苦。每次登录都要先删旧token再插新token数据库在并发插入时会因为唯一键冲突报错你还得想办法处理这种冲突。而中间旧token已删、新token未插的空窗期会让正在使用的用户意外掉线。数据库唯一索引适合做唯一身份标识不适合做会话互斥标记。2.2 切到Redis的真实理由过期、性能、分布式一致性把当前有效token从数据库搬到Redis之后三个问题迎刃而解Redis的key天然带TTLtoken过期后自动消失不用写定时任务清扫Redis的读写比数据库快一两个数量级高频接口每次校验会话的开销可以忽略多实例部署时各实例访问同一个Redis互踢状态天然全局一致不需要额外的同步机制。所以对于大多数需要单端登录的中小型系统Redis是目前综合成本最低的答案Spring Session、各类语言SDK对Redis的支持也都很成熟。如果你的系统已经是集群部署但会话状态还留在各自机器的本地内存里那单端登录根本没法定制因为A机器判断你是最新会话、B机器却不知道有这回事这属于必须先解决的底层问题。2.3 双键结构和键的过期策略我用两种键来维护会话状态核心思路如下键Alogin:session:{userId}value存当前有效tokenTTL设8天键Blogin:token:{token}value存userIdTTL设7天。校验请求时先用键B确认token本身存在并拿到userId再用键A里的token和当前token比较不一致就说明被顶号。键A的TTL比键B多一天是为了防止会话在用户活跃过程中提前被清掉。键A如果只set不设过期时间时间长了会积累一堆僵尸key内存白白被占所以过期时间一定要给。这个双键结构看着简单却是后面所有互踢逻辑的地基。3. 基于Redis的互踢拦截链完整落地3.1 登录时生成token、写入会话、踢掉旧会话登录校验通过之后我习惯按三步走生成足够随机的token。直接用UUID也行更稳妥的是用SecureRandom生成一段32字节以上的随机hex。不要用自增数字当token太容易猜。写入键B先把login:token:{newToken}写进Redisvalue存userId设置7天过期。这一步先执行保证新token可以被查到。更新键A把login:session:{userId}覆盖为新token设置8天过期同时把旧token对应的键B删掉。这里有一个经常被忽略的顺序问题第2步必须放在第3步之前否则新token先成了最新会话但键B里还没有它用户刚登录就发请求会被误判为未登录。而第3步里的更新键A 删除旧键B两步日常顺序执行也可以但并发请求多的时候就容易出竞态这个我放到第5章专门讲。用Java伪代码表达大概是这个意思String newToken UUID.randomUUID().toString().replace(-, ); stringRedisTemplate.opsForValue().set( login:token: newToken, String.valueOf(userId), Duration.ofDays(7)); String oldToken stringRedisTemplate.opsForValue().get(login:session: userId); stringRedisTemplate.opsForValue().set( login:session: userId, newToken, Duration.ofDays(8)); if (StringUtils.hasText(oldToken)) { stringRedisTemplate.delete(login:token: oldToken); }3.2 请求校验时确认你是最新会话在网关或拦截器里对所有受保护接口做统一校验逻辑用四步就能说清楚从Authorization头取出token查键B也就是login:token:{token}如果查不到直接返回未登录或token失效查键Alogin:session:{userId}和当前token做比较一致则放行不一致则返回账号已在其他设备登录。有一个常见误区有些人认为互踢只要在登录接口里把旧token标记成失效就够了但登录之后的每一次请求还是要靠拦截器来校验最新会话身份。所以哪怕互踢逻辑再简单这个最新会话比对也绝对不能省否则老会话还是能一直用着。校验逻辑里还可以顺带做会话续期也就是滑动过期。如果键B的剩余TTL低于1天就重新设置成7天这样长效在线用户不会被强制要求重新登录但长时间不活跃的用户会话还是会自然过期。注意滑动续期不要每个请求都刷新TTL只在低于阈值时刷新否则高并发下Redis的写压力会被过度放大。3.3 主动退出与被动过期收尾工作不能漏用户主动退出时要把当前token对应的键B删掉让会话立即失效。键A不建议直接删可以设置成空字符串或者让它走自然过期避免出现刚退出又发一个旧请求被判成有效会话的尴尬。被动过期场景要区分为三种键B自然到期、密码修改后强制旧token全部失效、账号被后台管理员强制下线。这三种都要走同一套会话撤销逻辑。尤其是密码修改很多团队忽略了这一步用户改完密码旧设备拿着旧token照样能访问三天这就是妥妥的安全漏洞。改密码本身应该让所有已签发会话失效这跟互踢逻辑是天然配合的。4. Session与JWT两种常见技术栈下的互踢落地方案4.1 基于Session的互踢先解决Session共享再谈互踢如果你的老项目还是以Session为中心互踢也可以做但前提是Session必须放在Redis这种共享存储里。否则多实例部署时会出现用户登录在A机器请求被路由到B机器B机器没有这个Session的经典问题。解决共享以后逻辑就和第3章的Redis方案几乎一样登录成功后把当前Session ID记录到Redis中比如login:session:{userId}每次请求先拿到Session再和Redis里记录的Session ID比对。因为Session容器本身已经存了用户信息互踢只需要额外存一个当前Session ID字段。这套方案适合结合Spring Session做旧工程改造改造成本最小。但注意不要在Session里塞太多对象否则Redis内存和序列化开销都会上来尤其是每次请求都要反序列化整个Session。4.2 JWT的无状态短板Token签发了就收不回来新项目里JWT很流行因为服务端不用存会话验签就能确认身份。可一旦要做互踢JWT无状态的优点恰恰变成缺点token一旦签发在过期前你没有任何办法让它立刻失效。要互踢就必须给JWT补一层服务端状态常见两种做法版本号方案Redis里存login:ver:{userId}当前版本号登录时把版本号加1并把版本号写进JWT的payload。请求时解析出版本号与Redis里的当前版本对比不一致就拒绝。这个方案用一个小字段替代了存整个token的开销内存非常省。黑名单方案JWT签发时带一个唯一ID也就是jti。被踢时把这个jti写进Redis黑名单TTL设为JWT的剩余有效期。请求时先查黑名单命中就拒绝。两个方案我都在项目里用过。版本号方案节省内存但每次请求要多一次Redis读黑名单方案实现直观、无需改签发逻辑但黑名单条目会占用更多内存。归根结底需要封禁、踢人这些能力服务端状态层是绕不开的别被JWT完全无状态的说法带偏。5. 实战中躲不开的坑并发、通知、多端组合与配套规范5.1 并发登录的竞态同一秒两台设备同时登录怎么办这是我在生产环境真实遇到过的坑。用户两台设备几乎同时发起登录后端收到两个请求登录A先写了自己的token登录B后写了自己的token最后键A被后一个覆盖。本来结果也还行但问题出在中间有一段窗口期A设备的token已经被键A替换而B设备还没完成更新键A的操作结果双方在各自校验时都被拒绝用户两边的登录体验都非常差。解决办法有两种。一种是把获取旧token、更新键A、删除旧键B封装成一个Lua脚本在Redis里原子执行不留给并发任何窗口。另一种是给同一个userId的登录请求加分布式锁用SET NX拿到锁的请求才允许走完整登录流程拿不到锁的要么等待要么直接失败重试。如果用了Redis ClusterLua脚本涉及的多个key要尽量通过hash tag路由到同一个slot否则会跨slot报错。相比之下分布式锁方案逻辑更简单排错也更容易。5.2 被踢用户如何第一时间知道WebSocket推送与轮询只靠接口层的401错误码用户不做下一次操作是感知不到被踢的。更稳妥的方案是被踢发生时通过WebSocket或SSE向旧设备推送一个kicked事件前端收到后立刻清理本地登录态并弹窗提示。没有WebSocket基建的老项目至少要做到前端在切页、App回到前台时主动调用一次会话检查接口发现40102就跳登录页。这里有一个体验细节被踢提示不要泄露新设备的任何信息。类似您的账号已在某品牌手机上登录这类文案看起来贴心实际上反而可能被社会工程学利用。统一提示您的账号已在其他设备登录如非本人操作请及时修改密码就足够了。5.3 更复杂的限制手机端只能登一台同时允许电脑在线很多产品规则其实是一个手机端加一个Web端可以同时在线只是同类端内互斥。这种场景不用改核心逻辑只需要把键A的粒度改细login:session:{userId}:{deviceType}。deviceType由客户端在登录请求中显式上报比如iOS、Android、PC-Web、PC-Client。跨端之间互不干扰同端之间互踢。再进一步如果产品要求每个设备ID只能登录一个会话那就在键A里再加deviceId。但设备ID通常由客户端生成并上报刷机、重装App都可能变安全要求不高的场景别做太死否则误伤率太高。设备相关字段也容易被伪造真要追求安全得配合设备指纹和风控体系或者利用官方SDK提供的设备唯一标识能力不要自己拼一个UA版本号就当设备ID用。5.4 错误码、审计日志与后台强制下线配套体系决定上限互踢功能能不能让运营、客服、安全团队省心取决于配套是否完整。首先要有一套稳定的错误码规范我通常这样定义错误码场景提示文案40101未登录或token失效请先登录40102账号在其他设备登录您已在其他设备登录如非本人操作请及时修改密码40103登录状态已过期登录已过期请重新登录40104被后台强制下线账号已被管理员下线其次每次登录、被踢、强制下线都要打审计日志记录时间、IP、设备、登录结果、被踢原因。客服接到账号是不是被盗了的投诉时这套日志能直接给出答案安全团队做异常登录检测时也靠它找线索。后台强制下线这个功能经常被做成重置密码或者删除用户对象这都不对。正确做法是复用会话撤销逻辑找到该用户当前token对应的键B删除或标记为被踢再把键A清掉或覆盖。管理员在后台点一下强制下线用户的会话必须立刻失效否则就又是一个看着下线了、其实还能用的Bug。我在不同项目里分别用过数据库字段、Redis双键、JWT版本号这三种方案踩过不少坑之后目前最顺手的一套组合是Redis双键存会话 Lua脚本处理并发登录 明确的错误码 WebSocket通知被踢方 完整审计日志。这套方案不算重普通规模的Web服务都能扛住以后要扩展多端组合限制也只是改改键的粒度不用推翻重来。如果你正在接手这类需求我的建议是先花半天把产品规则聊透再动手写代码。单端登录看着是个小功能真正做扎实了并发控制、会话生命周期、安全审计和前端交互每一块都需要提前设计。本文还有配套的精品资源点击获取