這套點評實戰(zhàn)項目我前后做了好幾輪登錄模塊是第一個被推倒重來又徹底定稿的部分。很多剛上手 Spring Boot 的朋友都會問登錄不就是校驗用戶名密碼然后塞 Session 嗎干嘛非得引入 Redis等真把項目部署成多實例、把前端換成小程序和 App、再被測試反饋換臺設備登錄態(tài)就丟了請求頭里 Cookie 根本帶不過來的時候才明白 Session 這套方案在今天的主流項目里有多別扭。這篇文章把基于 Redis 實現(xiàn)登錄的完整思路、核心代碼和真實踩坑記錄全放出來當成這個系列的第一篇后面幾篇我們接著聊緩存穿透、分布式鎖和熱點數(shù)據(jù)優(yōu)化。這套登錄方案不挑語言思路我用 Java Spring Boot 實現(xiàn)核心邏輯就是把用戶登錄態(tài)從服務器內(nèi)存搬到 Redis用 Token 代替 Session ID所有依賴登錄的接口通過攔截器統(tǒng)一校驗。適合正在做單體應用但準備橫向擴容的同學也適合想搞清楚為什么要用 Redis 存登錄態(tài)的人。讀完你不僅能照著抄還能明白每行配置為什么這么寫。1. 先想清楚登錄方案為什么要動 Redis1.1 傳統(tǒng) Session 在真實項目里的四個痛點教科書里把 Session 講得很簡單用戶登錄成功服務器把用戶信息存進內(nèi)存生成一個 Session ID 通過 Cookie 返回給瀏覽器下次請求帶上 Cookie服務器比對一下 ID 就能認出你是誰。這套流程在單機開發(fā)環(huán)境里跑得飛快但一旦放到真實項目問題一個接一個蹦出來。第一個痛點是多實例部署。只要項目上了兩臺服務器負載均衡一轉(zhuǎn)發(fā)用戶第一次請求落在 A 節(jié)點第二次請求落在 B 節(jié)點B 節(jié)點內(nèi)存里根本沒有這個 Session用戶就被強制登出了。解決方案不是沒有Session 粘滯、Session 復制都有人用但粘滯會把負載均衡的能力廢掉一大半復制又會在節(jié)點多的時候產(chǎn)生大量冗余數(shù)據(jù)越用越難受。第二個痛點是跨域和移動端適配。Web 項目還好Cookie 是瀏覽器原生支持的但小程序、App 這類客戶端對 Cookie 的支持并不可控很多 HTTP 客戶端根本不會自動維護 Cookie 會話。做前后端分離更是如此接口域名和前端域名不一樣還得專門處理 CORS 里的 Credentials一個沒配好Cookie 就帶不過來了。第三個痛點是內(nèi)存占用。Session 默認存服務器內(nèi)存用戶越多內(nèi)存被吃掉的越多而且很多框架的 Session 還要做持久化重啟不丟這又引入了額外的存儲和序列化成本。我見過一個項目從沒配過 Session 清理內(nèi)存里堆了一大堆幾百年沒活躍過的用戶會話最后只能靠重啟暫時緩解。第四個痛點是被動失效難。你想讓某個用戶下線 Session 方案里你得知道他對應哪個 Session ID還得找到那臺存他 Session 的服務器想想就頭大。想做一個賬號只能在一處登錄管理員強制踢人這類運營需求 Session 方案實現(xiàn)起來非常繞。1.2 Redis 為什么適合做登錄態(tài)能過期、能共享、能精確刪除Session 的痛點Redis 幾乎是為解決它們而生的。先說共享。Redis 是獨立部署的服務業(yè)務服務器無論有多少臺節(jié)點訪問的都是同一個 Redis登錄態(tài)天然就是全局共享的。擴容時新加節(jié)點不用做任何會話同步因為會話根本不在節(jié)點上把服務發(fā)現(xiàn)有問題的同學直接解放。再說過期。Redis 的 key 支持設置 TTL到期自動刪除這跟會話的生命周期太契合了。用戶登錄態(tài)可以設置比如 30 分鐘過期用戶在活躍時每次請求都刷新這個 TTL就實現(xiàn)了滑動過期。用戶不活躍了TTL 到了Redis 自動把數(shù)據(jù)清掉不需要開發(fā)手寫定時任務去掃。然后是精確刪除。一個 DEL 命令就能把某個用戶的登錄態(tài)立刻干掉實現(xiàn)退出登錄踢人下線頂號登錄都非常直接。Session 方案里難以實現(xiàn)的運營需求Redis 方案下就是一條命令的事。最后可以對比一下同樣是無狀態(tài)登錄的 JWT 方案。JWT 把用戶信息加密進客戶端保存的令牌里服務端不存任何狀態(tài)天然適合分布式。但它有個硬傷你沒法主動讓一個已簽發(fā)的 JWT 失效。用戶被盜號了你想把他踢下線做不到只能等 token 自己過期。想實現(xiàn)頂號登錄得額外引入黑名單機制那本質(zhì)上又是在服務端存狀態(tài)了既然這樣還不如直接用 Redis 存登錄態(tài)一切盡在掌握。這就是我最終選擇 Redis 的核心原因可共享、可過期、可主動刪除三個特性正好補齊 Session 和 JWT 各自的短板。2. 模塊拆解登錄在點評項目里到底做了哪幾件事2.1 三條主線流程發(fā)碼、登錄、校驗登錄模塊不是只有一個登錄接口那么簡單。我把它拆成了三個流程每個流程面臨的 Redis 操作重點都不一樣。第一個流程是發(fā)送驗證碼。用戶輸入手機號點擊獲取驗證碼后端要做的不是立刻發(fā)短信而是一連串防御動作先校驗手機號格式對不對再看這個手機號是不是剛剛發(fā)過防止用戶狂點按鈕把短信接口刷爆然后生成一個 6 位隨機驗證碼存進 Redis 并設置過期時間最后才真正調(diào)用短信服務商把驗證碼發(fā)出去。在這個流程里Redis 承擔的是頻控 存儲兩個職責。第二個流程是登錄。用戶輸入手機號和驗證碼后端從 Redis 里把之前存的驗證碼取出來比對比對正確、刪掉這個 key驗證碼一次性用完即焚然后去用戶表查這個手機號有沒有注冊過沒有就自動創(chuàng)建一個新用戶最后生成一個 Token把用戶的核心信息存進 Redis設置 TTL再把 Token 返回給前端。這個流程里Redis 承擔的是存儲登錄態(tài)的職責。第三個流程是登錄態(tài)校驗。前端在后續(xù)所有需要登錄的請求頭里帶上 Token后端通過攔截器統(tǒng)一處理拿到 Token去 Redis 查有沒有對應的用戶查到了就放行查不到或者過期了就返回 401。同時還要做一件事——刷新 Token 的 TTL讓活躍用戶的登錄態(tài)自動續(xù)期。這個流程里Redis 承擔的是鑒權 續(xù)期兩個職責。三個流程看起來簡單但每個環(huán)節(jié)都有細節(jié)下面用 Redis 的數(shù)據(jù)結(jié)構(gòu)設計把這些細節(jié)串起來。2.2 key 設計與 TTL 管理怎么設計才能不串號、不占內(nèi)存Redis 是個大字典所有人共用同一片命名空間key 設計不好就等著數(shù)據(jù)互相覆蓋或者排查到崩潰。我在這個項目里統(tǒng)一用業(yè)務前綴 冒號 唯一標識的格式。前綴用英文單詞加模塊名比如驗證碼用login:code登錄態(tài)用login:token登錄態(tài)所屬用戶如果需要反向索引再用login:user。冒號不是隨便加的Redis 官方推薦這種風格它在可視化工具里會自動按前綴折疊分組排查問題的時候一眼就能看到某個業(yè)務下有哪些 key。具體到登錄場景我用了三個核心 keykeyvalueTTL用途login:code:{手機號}6 位隨機數(shù)字驗證碼5 分鐘存驗證碼過期作廢login:token:{token}用戶信息的 JSON 字符串30 分鐘存登錄態(tài)滑動續(xù)期login:user:{用戶id}token 字符串30 分鐘反查登錄態(tài)實現(xiàn)頂號驗證碼設 5 分鐘是行業(yè)通行做法太短用戶收個短信再看一眼就不夠用了太長又給暴力破解留了太多時間窗口。登錄態(tài)設 30 分鐘配合每次請求刷新 TTL用戶只要保持在用狀態(tài)就永遠不掉線真正超過 30 分鐘完全沒活躍才需要重新登錄大多數(shù)場景下這個配置是合理的。需要更長時長的業(yè)務比如記住我這類功能可以單獨給另一個 key 設置更長 TTL不要試圖用一個 key 兼顧所有場景。TTL 不是越長越好Redis 雖然會自動清理過期 key但大量長期不過期的登錄態(tài)堆在內(nèi)存里最終會觸發(fā)內(nèi)存淘汰策略到時候就不是你想保留哪個的問題了。login:user:{用戶id}這個反向索引很多人會忽略但它是實現(xiàn)頂號登錄的關鍵。用戶在新設備上登錄按用戶 id 把舊的 token 對應的 key 刪掉再存新 token就能保證同一時刻只有一個設備在線。如果產(chǎn)品需求是多端在線這個 key 就不需要了做成 token 列表也行。需求決定設計別一上來就把所有 key 都建了。3. 實操從零到一實現(xiàn) Redis 登錄3.1 序列化方案這一步做錯登錄態(tài)直接亂碼真正開始寫代碼前我建議先花五分鐘把 Redis 的序列化方案定下來。Spring Boot 里訪問 Redis 有兩大工具RedisTemplate和StringRedisTemplate。很多初學者上來就用RedisTemplate結(jié)果往 Redis 里一存控制臺看到的是一串\xAC\xED\x00\x05t...之類的亂碼這就是 JDK 默認序列化搞的鬼。JDK 序列化有三個毛病存進去的內(nèi)容人類完全讀不懂排查問題極其痛苦序列化后的體積特別大浪費內(nèi)存而且 JDK 序列化的數(shù)據(jù)只有 Java 程序能讀將來如果引入 PHP、Go 寫的服務想共用數(shù)據(jù)直接傻眼。我的選擇很簡單統(tǒng)一用StringRedisTemplatevalue 直接存 JSON 字符串。key 本來就是字符串value 用 JSON 序列化后的字符串Redis 里看到的就是干干凈凈的明文哪個 key 對應什么業(yè)務一目了然。配合項目里已有的 Jackson用戶對象轉(zhuǎn)成 JSON 再存取出時再反序列化回對象全程不碰 JDK 序列化。這里有一個容易踩的坑如果用戶對象里有LocalDateTime這種 Java 8 時間類型直接用 Jackson 轉(zhuǎn) JSON 會報錯或者轉(zhuǎn)成數(shù)組。需要引入jackson-datatype-jsr310模塊然后給ObjectMapper注冊JavaTimeModule再把writeDatesAsTimestamps關掉。這個坑不下三次在我手底下出現(xiàn)過提前寫進配置能省半天排查時間。Configuration public class RedisConfig { Bean public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory factory) { StringRedisTemplate template new StringRedisTemplate(); template.setConnectionFactory(factory); return template; } Bean public ObjectMapper objectMapper() { ObjectMapper mapper new ObjectMapper(); mapper.registerModule(new JavaTimeModule()); mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); return mapper; } }3.2 發(fā)驗證碼接口頻控、校驗、倒計時一次搞定發(fā)送驗證碼接口的核心不是發(fā)短信而是怎么擋掉無效請求。我完整走一遍這個接口的邏輯。第一步校驗手機號格式。手機號這關不過后面全都不用執(zhí)行。正則表達式校驗第一位是 1第二位是 3-9后面 9 位數(shù)字基本覆蓋國內(nèi)手機號格式。這一步可以省掉一次 Redis 查詢和一次短信費用值得認真寫。第二步查 Redis 里有沒有l(wèi)ogin:code:{手機號}這個 key。如果存在說明 60 秒內(nèi)才剛剛發(fā)過驗證碼直接提示發(fā)送過于頻繁連短信都不必調(diào)。這就是倒計時的實現(xiàn)原理倒計時不是前端渲染的而是后端根據(jù) Redis 里 key 的 TTL 剩多少返回給前端計算的。前端做 60 秒倒計時只是交互展示后端的 Redis 判斷才是真正的護欄。第三步生成 6 位隨機驗證碼。我用了String.format(%06d, random.nextInt(1000000))注意補齊前導零比如生成的是004728格式化后丟不了 0。有人喜歡用 UUID 截一段當驗證碼沒必要6 位數(shù)字對用戶最友好暴力破解風險靠 TTL 和頻控已經(jīng)壓下來了。第四步寫 Redis設置 5 分鐘 TTL。這里再疊加一個每日發(fā)送上限的 key比如login:code:limit:{手機號}每發(fā)一次就incr一次第一次發(fā)送時設置expire到當天 24 點超過比如 10 次就拒絕發(fā)送。這個設計能防住拿別人手機號惡意刷短信的腳本上線當天就被我用上了不然短信費一天比一天離譜。PostMapping(/code) public Result sendCode(RequestParam(phone) String phone) { // 1. 校驗手機號格式 if (!RegexUtils.isPhoneInvalid(phone)) { return Result.fail(手機號格式錯誤); } // 2. 檢查 60 秒內(nèi)是否已經(jīng)發(fā)過 String codeKey login:code: phone; if (stringRedisTemplate.hasKey(codeKey)) { Long ttl stringRedisTemplate.getExpire(codeKey, TimeUnit.SECONDS); return Result.fail(發(fā)送過于頻繁請 ttl 秒后重試); } // 3. 生成 6 位隨機驗證碼 String code String.format(%06d, new Random().nextInt(1000000)); // 4. 存入 Redis5 分鐘有效 stringRedisTemplate.opsForValue().set(codeKey, code, 5, TimeUnit.MINUTES); // 5. 記錄每日發(fā)送次數(shù) String limitKey login:code:limit: phone; Long count stringRedisTemplate.opsForValue().increment(limitKey); if (count ! null count 1) { stringRedisTemplate.expire(limitKey, Duration.between(LocalDateTime.now(), LocalDate.now().plusDays(1).atStartOfDay()).toMinutes(), TimeUnit.MINUTES); } // 6. 模擬調(diào)用短信服務商真實項目中替換成具體 SDK log.info(驗證碼{}, code); return Result.ok(); }有一個細節(jié)要注意第 2 步用hasKey判斷彈出的提示語最好做成返回剩余秒數(shù)而不是固定寫1 分鐘內(nèi)只能發(fā)一次。用戶體驗上差別很大而且實現(xiàn)上只是多一行getExpire的事。3.3 登錄接口驗證碼校驗、新用戶自動注冊、Token 生成登錄接口的核心是三個動作驗證碼比對、用戶查詢/創(chuàng)建、Token 生成與登錄態(tài)落庫。驗證碼比對有個關鍵點先判斷 key 是否存在再比對值最后無論對錯都要刪掉這個 key。刪掉的邏輯很多人會漏驗證碼是一次性的不能允許同一個驗證碼被反復提交。哪怕用戶輸錯了也要把舊驗證碼刪掉讓他重新獲取這種用完即焚的習慣能擋住大部分驗證碼重放攻擊。比對的時候我建議用字符串的equals別用有人在這里踩過坑拿反序列化的對象去比較結(jié)果莫名的 NPE。用戶查詢與創(chuàng)建查用戶表用手機號查查不到說明是新用戶自動注冊一個初始昵稱給個默認值、頭像給個默認圖這些生成邏輯在真實項目里也是小小的產(chǎn)品決策先別管花哨的機制能跑通流程最重要。Token 生成有人用 UUID有人用 Hutool 的IdUtil.simpleUUID()還有人用雪花算法。登錄態(tài) Token 不需要可讀性要的是隨機性和唯一性UUID 足夠了。注意生成后要替換掉中間的橫杠省幾個字節(jié)是一回事主要在 URL 和請求頭里裸奔的時候帶橫杠的字符串也沒啥大問題但干凈一點總沒壞處。登錄態(tài)落庫把用戶 ID、手機號、昵稱這些必要信息塞進一個UserDTO轉(zhuǎn)成 JSON 存到login:token:{token}這個 key 里TTL 30 分鐘。再次強調(diào)不要把密碼、密保問題答案這類敏感字段放進這個 JSON登錄態(tài)里只需要鑒權必需的信息。你存得越少泄露之后損失越小。這個習慣我是在一次線上數(shù)據(jù)被拖庫后養(yǎng)成的當年登錄態(tài)里塞了明文手機號和個人簡介教訓相當深刻。頂號邏輯這里提一下。如果你要做一個賬號同時只能一個設備登錄把新 Token 存進去之后順手從反向 keylogin:user:{用戶id}里取出舊 Token把舊的login:token:{舊token}刪掉再寫入新的反向索引。這樣用戶一登錄新設備老設備立刻失效實現(xiàn)頂號。PostMapping(/login) public Result login(RequestParam(phone) String phone, RequestParam(code) String code) { String codeKey login:code: phone; String savedCode stringRedisTemplate.opsForValue().get(codeKey); if (savedCode null || !savedCode.equals(code)) { return Result.fail(驗證碼錯誤或已過期); } // 驗證碼一次性刪掉防重放 stringRedisTemplate.delete(codeKey); // 查用戶不存在則自動注冊 User user userService.lambdaQuery().eq(User::getPhone, phone).one(); if (user null) { user createUserWithDefaultProfile(phone); } // 生成 Token保存登錄態(tài) String token UUID.randomUUID().toString().replace(-, ); UserDTO userDTO BeanUtil.copyProperties(user, UserDTO.class); String tokenKey login:token: token; stringRedisTemplate.opsForValue().set(tokenKey, objectMapper.writeValueAsString(userDTO), 30, TimeUnit.MINUTES); // 反向索引用于頂號登錄 String reverseKey login:user: user.getId(); String oldToken stringRedisTemplate.opsForValue().get(reverseKey); if (oldToken ! null) { stringRedisTemplate.delete(login:token: oldToken); } stringRedisTemplate.opsForValue().set(reverseKey, token, 30, TimeUnit.MINUTES); return Result.ok(token); }登錄接口里還有一個容易被忽略的環(huán)節(jié)把UserDTO轉(zhuǎn) JSON 時拋出的異常。運營反饋為什么登錄偶發(fā)失敗排查到最后是對象里有字段序列化不成功。所以我在實際項目里都會把 JSON 轉(zhuǎn)換單獨抽一個方法try-catch 包住失敗了記日志避免異常一路拋到前端返回一個 500用戶完全看不懂發(fā)生了什么。3.4 登錄攔截器一勞永逸的登錄態(tài)校驗與刷新登錄態(tài)存好了總不能每個需要登錄的接口都寫一遍查 Redis、解析用戶吧。用攔截器統(tǒng)一處理這是這個模塊的核心價值所在。先寫業(yè)務攔截器。preHandle里做三件事。第一從請求頭authorization里取出 Token注意大小寫我見過前端傳Authorization、后端取authorization導致全部 401 的冤案建議前后端約定同一種寫法第二拿著 Token 去查 Redis查不到說明登錄態(tài)過期或者被頂號直接返回 401這里一定要response.setStatus(401)不要只返回一個 JSON 里帶 code 的錯誤前后端分離的架構(gòu)里HTTP 狀態(tài)碼也是協(xié)議的一部分第三查到了就把這個 key 的 TTL 續(xù)期到 30 分鐘再把UserDTO放進去ThreadLocal方便后面的業(yè)務代碼直接拿當前用戶不用在每個 Controller 方法里定義多余的形參。public class LoginInterceptor implements HandlerInterceptor { private final StringRedisTemplate stringRedisTemplate; private final ObjectMapper objectMapper; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(authorization); if (token null || token.isEmpty()) { response.setStatus(401); return false; } String key login:token: token; String userJson stringRedisTemplate.opsForValue().get(key); if (userJson null) { response.setStatus(401); return false; } UserDTO userDTO objectMapper.readValue(userJson, UserDTO.class); // 滑動續(xù)期 stringRedisTemplate.expire(key, 30, TimeUnit.MINUTES); UserHolder.saveUser(userDTO); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserHolder.removeUser(); } }ThreadLocal的使用有個鐵律用完必須清理。afterCompletion里調(diào)用removeUser()這一步不能省。Tomcat 的工作線程是復用的線程處理完一個請求不會銷毀不清ThreadLocal下一個請求就會讀到上一個用戶的信息輕則數(shù)據(jù)串號重則越權訪問。這個坑我栽過上線第一天就收到了用戶 A 看到了用戶 B 數(shù)據(jù)的工單排查半天才定位到是ThreadLocal沒清。最后配置攔截器。實現(xiàn)WebMvcConfigurer把攔截器注冊進去并設置放行路徑。登錄相關接口、靜態(tài)資源、錯誤頁要放行其余/**全部攔截。很多人這里會犯一個錯把WebMvcConfigurer寫成了普通的Component而沒有繼承任何東西或者忘記加Configuration結(jié)果攔截器悄悄失效。另一個容易忽略的是路徑匹配如果你用 Spring Boot 3.xant_path_matcher的配置有時候需要手動開否則/**不生效所有請求都被攔下來一片紅。Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor(stringRedisTemplate)) .addPathPatterns(/**) .excludePathPatterns(/login, /code, /error); } }4. 上線前會踩的坑實測問題與排查記錄4.1 攔截器明明寫了卻不生效項目里第一個攔路虎就是攔截器失效。日志里能看到LoginInterceptor被 Spring 加載了但請求一個都不攔全部直接進了 Controller。排查順序我建議固定為三層。第一層看有沒有配置類真被掃描到Configuration注解的類所在的包必須能被ComponentScan掃到否則配置類等于沒寫。第二層看是不是實現(xiàn)了WebMvcConfigurerSpring Boot 3 以前還有一種繼承WebMvcConfigurationSupport的寫法這個寫法會把 Spring Boot 自動配置的 MVC 全部覆蓋掉靜態(tài)資源映射、消息轉(zhuǎn)換器全部失效能不碰就別碰。第三層看攔截器注冊時addPathPatterns(/**)的寫法在 Spring Boot 2.6 之后路徑匹配策略變了部分情況下要用PathMatchConfigurer把匹配策略切回AntPathMatcher否則/**匹配不到任何路徑。三層排查法走下來絕大多數(shù)攔截器不生效都能解決。4.2 Token 拿到手卻查不到用戶序列化格式不一致有一次前端反饋某些用戶明明剛登錄成功下一次請求就 401。追蹤發(fā)現(xiàn)login:token:對應的 key 確實存在而且 TTL 還有二十多分鐘但StringRedisTemplate.opsForValue().get(key)返回了null。問題出在存的時候和取的時候用了兩套序列化。登錄接口里用了StringRedisTemplate存了一個 JSON 字符串但后來攔截器里圖方便用了RedisTemplate去取RedisTemplate默認 JDK 序列化它用 JDK 序列化的方式去解析一個 JSON 字符串自然解析得七零八落取出來是null或者解析異常。這一類的詭異問題直接統(tǒng)一所有操作 Redis 的地方都用StringRedisTemplate就不會發(fā)生。這也是我一直強調(diào)定方案要趁早的原因前后端接口字段統(tǒng)一用駝峰、Date 用時間戳還是字符串Redis 序列化用 JSON 還是用別的這類全局約定一定是在寫第一行代碼之前就拍死的。4.3 驗證碼接口被腳本刷爆這個坑是我在生產(chǎn)環(huán)境真實撞見的。上線第二天監(jiān)控發(fā)現(xiàn)短信接口的調(diào)用量是昨天同期的三倍打開后臺一看全是同一個 IP 在狂點獲取驗證碼顯然是有人拿腳本在刷。光靠60 秒發(fā)一次根本擋不住腳本可以隨機換手機號每次都是新手機號就繞過了單個手機號的頻率限制。治本辦法是把頻率限制從手機號維度擴展到設備/IP 維度和全局配額維度。Redis 里用login:code:ip:{ip}統(tǒng)計每個 IP 每日發(fā)送量超過閾值就拒絕再加一個全局計數(shù)器比如整個系統(tǒng)每天最多發(fā)多少條驗證碼量到了就該人工介入審查了。短信服務商那邊也要配限額萬一 Redis 數(shù)據(jù)被清、后端的判斷全部失效服務商的配額還能兜底這是最后一道防線。4.4 ThreadLocal 用戶串號前面提到過這里再展開一次。用戶 A 登錄后看到了用戶 B 的訂單數(shù)據(jù)排查過程十分詭異兩個用戶是不同手機號、不同賬號Redis 里的數(shù)據(jù)也沒串但 Controller 拿到的用戶卻是 B。最后定位在ThreadLocalTomcat 的線程池復用了工作線程前一個請求是 B處理完后沒有清掉ThreadLocal下一個請求雖然攔截器正確地從 Redis 拿到了 A 的用戶信息但業(yè)務代碼因為有緩存直接讀了舊的ThreadLocal于是 A 就看到了 B 的數(shù)據(jù)。解決辦法已經(jīng)寫在了攔截器代碼里afterCompletion一定要清理。按我的習慣凡是往ThreadLocal里寫了東西的都得像對待InputStream一樣強制在finally里清理一步都不能少?，F(xiàn)象可能原因排查方法解決方案所有請求 401攔截器放行配置錯登錄接口也被攔看日志是否有LoginInterceptor在 excludePathPatterns 加/login登錄態(tài)隨機丟失存和取用了不同 RedisTemplate打印 key 的 value 看是否亂碼統(tǒng)一用 StringRedisTemplate驗證碼同一秒被刷檢查邏輯里沒有先查再發(fā)的原子操作看 Redis key 的 TTL用setIfAbsent加分布式鎖產(chǎn)生了大量永久 key登錄 key 沒設置 TTLredis-cli --bigkeys統(tǒng)計所有 key 都要帶 TTL用戶數(shù)據(jù)串號ThreadLocal 未清理在 afterCompletion 打印日志強制調(diào)用 removeUser4.5 頂號登錄的邊界情況頂號登錄邏輯看起來簡單但有幾個邊界情況很考驗腦筋。一是同一個用戶在極短的時間內(nèi)兩次登錄第一次登錄寫入 token1第二次登錄時刪 token1、寫入 token2如果第一次的請求比第二次晚到達就會出現(xiàn) token1 已經(jīng)被刪了但第一次請求的校驗還能通過短暫地把 token1 又寫回來了。解決思路是刪舊 token 前先判斷反向索引里的 token 是不是等于當前請求要刪的 token不一致就不刪。二是用戶 A 在設備 1 登錄被盜號者拿去設備 2 登錄頂號后設備 1 確實失效了但 Redis 里可能殘留設備 1 創(chuàng)建的其他業(yè)務數(shù)據(jù)這些數(shù)據(jù)要設計生命周期不能全部綁定在登錄態(tài)上。三是頂號策略本身要看產(chǎn)品需求是想讓新設備頂?shù)衾显O備還是干脆禁止重復登錄這直接決定了反向索引寫不寫別上來就照抄。5. 上線前最后再檢查這幾件事代碼寫完了不代表能上線我這套登錄模塊上線前反復檢查的點整理成一份清單照著走一遍能省很多半夜攔截器報警的功夫。第一個檢查 Redis 的配置。連接池超時時間、最大連接數(shù)、空閑淘汰參數(shù)都要根據(jù)業(yè)務預估量提前估算。尤其要注意 Redis 的密碼和網(wǎng)絡安全組配置不要讓 Redis 裸奔在公網(wǎng)我見過不止一個團隊把 Redis 端口暴露到公網(wǎng)數(shù)據(jù)庫被清空的事件做技術的人一定要有這個敏感度。第二個檢查 TTL 策略。確認所有業(yè)務 key 都帶了合理的過期時間別有不帶 TTL 的野 key 長期占用內(nèi)存。上線前可以寫個腳本統(tǒng)計一下 key 的數(shù)量和分布心里先有個底。第三個檢查異常處理鏈路。Redis 故障了怎么辦這個問題值得想清楚。登錄接口在 Redis 不可用時應該快速失敗并返回友好提示而不是讓用戶在轉(zhuǎn)圈圈。有的業(yè)務對可用性要求極高會把 Redis 做成主從加哨兵或者干脆用集群模式但那是架構(gòu)層面的事了至少要在代碼里做好降級比如緩存 Redis 不可用標志走臨時白名單避免雪崩。第四個檢查日志。登錄這種高頻操作日志一定要有但絕不能冗長。打印用戶 id、token 前幾位、登錄結(jié)果和耗時不打印驗證碼明文、不打印完整 token這是安全和排障的平衡點。第五個檢查壓測。驗證碼接口和登錄接口是典型的高并發(fā)寫入場景用壓測工具灌一波看看 Redis 的 CPU、內(nèi)存和響應時間別抱僥幸心理該提前發(fā)現(xiàn)的問題一定要壓出來。最后再分享一個小經(jīng)驗。登錄模塊是整個系統(tǒng)的地基地基歪了后面全是歪的。我見過很多項目組上來就懟各種高大上的框架結(jié)果一頓操作猛如虎一問登錄態(tài)怎么存的答曰用的默認的 Session。不是說 Sesseion 不行而是你得知道你選的方案在將來項目變大時會不會成為瓶頸。我在這個點評項目里選擇了 Redis 存登錄態(tài)三臺實例隨意擴縮容登錄模塊從頭到尾沒出過狀態(tài)相關的事故這個方案經(jīng)受住了驗證。接下來這個系列要繼續(xù)講緩存穿透、熱點 key 和分布式鎖都是登錄做完之后緊接著要面對的真實問題回頭見。