：契約設(shè)計、密碼存儲與唯一索引兜底)
1. 先釘死接口契約再動手寫代碼寫注冊接口這件事很多人第一反應(yīng)是打開 IDE 建個 Controller然后一邊寫一邊想字段。我見過太多項目在這個環(huán)節(jié)翻車前端調(diào)了兩天發(fā)現(xiàn)字段對不上測試提了十幾個為什么這里返回 500上線后運維發(fā)現(xiàn)日志里全是空指針。真正省時間的做法恰好相反——先把契約寫在紙上包括請求字段、返回結(jié)構(gòu)、錯誤碼、冪等規(guī)則再開始寫第一行業(yè)務(wù)代碼。注冊接口看著簡單它卻是整個賬號體系的入口字段定義一旦定下來后面改一次要牽動登錄、找回密碼、第三方綁定、用戶中心一大串模塊。這篇文章講的是「后端系統(tǒng)開發(fā)之——創(chuàng)建注冊接口」我會把它當成一次完整的實戰(zhàn)復(fù)盤來做從契約設(shè)計、密碼存儲、表結(jié)構(gòu)與唯一約束、事務(wù)與并發(fā)、頻控加固一直講到聯(lián)調(diào)自測。適合剛接觸后端業(yè)務(wù)開發(fā)、準備寫第一個正式接口的朋友也適合做了一兩年但一直靠能跑就行撐著的同行——里面有不少地方是踩過坑之后才知道該這么寫的。1.1 一個注冊請求到底該收哪些字段先把字段分成三類身份憑證、可選資料、上下文信息。身份憑證是必須的通常是手機號或郵箱二選一加一個密碼可選資料是昵稱、頭像、邀請碼這類缺了也能創(chuàng)建賬號上下文信息是客戶端類型、渠道來源、設(shè)備標識用來做風(fēng)控和后期分析一般不參與業(yè)務(wù)校驗。分清楚這三類好處是校驗邏輯可以分層身份憑證缺失直接 400可選資料缺失走默認值上下文信息缺失只記一條告警不阻斷流程。我見過把邀請碼做成必填的接口注冊轉(zhuǎn)化率直接掉了三成后來才發(fā)現(xiàn)是運營在某次活動頁跳轉(zhuǎn)時沒帶參數(shù)。下面這份請求體是我目前項目里用的最小集合可以直接參考{ account: 13800000000, password: Abc123456, nickname: 路人甲, channel: web, inviteCode: XK92A, captchaToken: c_8f3a... }幾個細節(jié)值得說清楚。account用一個字段同時承載手機號和郵箱靠正則區(qū)分類型好處是前端只渲染一個輸入框缺點是后端每次都要做類型判斷如果你的業(yè)務(wù)明確只支持手機號那就老老實實叫mobile別為了以后可能支持郵箱提前抽象抽象是有成本的。password只做長度和字符集校驗絕不在請求體里做業(yè)務(wù)語義上的復(fù)雜度提示那屬于前端體驗層的事后端只守住底線。captchaToken這類字段建議單獨抽出來別和業(yè)務(wù)字段混在一起因為它對應(yīng)的校驗邏輯是一次性消耗和冪等、事務(wù)的邊界完全不同。1.2 返回體與錯誤碼別讓前端靠猜返回結(jié)構(gòu)我堅持用統(tǒng)一信封{ code: 0, message: ok, data: { userId: 10231, token: eyJ... }, traceId: a1b2c3d4 }code為 0 表示成功非 0 是業(yè)務(wù)錯誤碼HTTP 狀態(tài)碼只用來表達傳輸層語義200/400/401/500不要用 HTTP 狀態(tài)碼承載業(yè)務(wù)錯誤否則前端要寫一大堆if (status 409)的分支網(wǎng)關(guān)層的統(tǒng)一重試策略也會被誤導(dǎo)。traceId是我強烈建議加上的字段用戶截圖報錯時你拿著 traceId 能直接定位到那一條完整日志鏈路排查效率的提升是數(shù)量級的。錯誤碼要給區(qū)間規(guī)劃別隨手編號區(qū)間含義示例0成功01000-1099參數(shù)與格式錯誤1001 賬號格式不正確1100-1199業(yè)務(wù)規(guī)則攔截1101 該賬號已注冊1200-1299頻控與風(fēng)控1201 操作過于頻繁1500-1599系統(tǒng)內(nèi)部異常1500 服務(wù)繁忙請稍后重試規(guī)劃好區(qū)間前端可以按百位做統(tǒng)一提示文案后端加新錯誤碼也不至于撞號。1.3 三個最容易被忽略的隱含需求第一是冪等。用戶手抖點兩下、網(wǎng)絡(luò)超時自動重試、客戶端做了一次重發(fā)這些場景在移動端是常態(tài)。注冊接口如果不做冪等結(jié)果就是數(shù)據(jù)庫里出現(xiàn)兩條同號賬號或者第二條請求報已注冊而用戶以為自己沒注冊成功。第二是來源校驗。開放公網(wǎng)的注冊接口一定會被掃加一個來源白名單或者簽名校驗?zāi)軗醯粝喈斠徊糠值图壞_本。第三是注冊成功后的返回內(nèi)容。要不要直接返回登錄 token我的做法是返回理由是省一次登錄往返用戶體驗上順滑很多代價是注冊接口要依賴簽發(fā) token 的模塊耦合度略高。如果團隊對登錄態(tài)有更嚴格的要求比如必須二次校驗設(shè)備指紋那就只返回 userId讓前端跳登錄頁。提示契約定稿后寫成一份接口文檔并納入版本管理字段增刪要走變更流程。我吃過一次虧某同學(xué)為了趕需求悄悄把nickname改成必填結(jié)果老版本 App 全量報錯。2. 密碼存儲的取舍算法、參數(shù)與那條 72 字節(jié)的暗線密碼這塊是最不該省事的地方也是最容易埋雷的地方。我見過用 MD5 存的、用 MD5 加固定鹽存的、用 Base64 當加密的每一種都能在出事后把團隊拖進深坑。2.1 為什么自己拼 MD5 加鹽基本等于沒加哈希算法的核心指標是計算速度。MD5 和 SHA-256 是為快設(shè)計的一張消費級顯卡每秒能算幾十億次。這意味著攻擊者拿到庫之后用常見密碼字典跑一遍弱密碼半小時內(nèi)就能還原出明文。加鹽確實能擋住彩虹表但擋不住針對單個賬號的暴力枚舉——因為快。真正適合存密碼的是慢哈希BCrypt、scrypt、Argon2 這一類設(shè)計目標就是故意算得慢而且慢的程度可以通過參數(shù)調(diào)節(jié)。它們內(nèi)置了每個用戶獨立的鹽輸出串里自帶算法標識、成本參數(shù)和鹽值不需要你額外建字段存鹽。這一點特別重要自己管理鹽的代碼十個有八個在某個分支里寫錯。2.2 成本參數(shù)到底該設(shè)多少BCrypt 的成本參數(shù)是cost每加 1計算耗時翻一倍。常用的cost10在普通云主機上單次哈希大約 50-100ms。這個數(shù)值不是拍腦袋定的要結(jié)合你的硬件和流量算一筆賬。估算邏輯是這樣的假設(shè)注冊加登錄合計峰值 300 QPS每次哈希按 80ms 計那么同時處于哈希計算中的請求數(shù)為 300 × 0.08 24。這部分是純 CPU 密集操作一個 4 核機器基本扛不住你會看到 CPU 打滿、請求排隊、P99 飆到幾秒。反過來說如果你現(xiàn)在只有 20 QPS那cost12完全沒問題安全性還更高。我給的經(jīng)驗區(qū)間是cost10起步實測單次耗時控制在 100ms 以內(nèi)壓測確認 CPU 余量大于 50%。真要更高強度就上 Argon2id 并調(diào)內(nèi)存參數(shù)或者把哈希計算挪到獨立的線程池/服務(wù)里別和業(yè)務(wù)線程搶資源。還有個參數(shù)叫strengthBCryptPasswordEncoder 里的版本默認 10注意它和cost是同一個東西的兩種叫法別在配置里寫成兩個值。2.3 BCrypt 只認前 72 字節(jié)這個坑很隱蔽這是我最想強調(diào)的一條。BCrypt 的算法設(shè)計只處理輸入的前 72 個字節(jié)超出部分被靜默截斷。也就是說如果你允許用戶設(shè)置超長密碼第 73 個字節(jié)之后的內(nèi)容完全不參與計算兩個前 72 字節(jié)相同的密碼會被判定為同一個密碼。更麻煩的是中文密碼——一個漢字在 UTF-8 下占 3 個字節(jié)72 字節(jié)大約只夠 24 個漢字。有些庫在超長時會直接拋異常Spring Security 的某些版本就會有些庫則默默截斷行為不一致。所以我的做法是在參數(shù)校驗層就把密碼長度卡死在 8 到 64 個字符并且明確按字節(jié)數(shù)再校驗一次不超過 72 字節(jié)。private static void checkPassword(String pwd) { if (pwd null || pwd.length() 8 || pwd.length() 64) { throw new BizException(1002, 密碼長度需在 8-64 個字符之間); } if (pwd.getBytes(StandardCharsets.UTF_8).length 72) { throw new BizException(1002, 密碼過于復(fù)雜請適當縮短); } }另外補一句pepper全局密鑰不是必須的但如果你擔心庫被拖走后成本參數(shù)不夠用可以在哈希前拼一段存在配置中心或環(huán)境變量里的密鑰。代價是密鑰輪換時所有存量密碼都要重算所以一般只在新項目里上老項目別折騰。3. 表結(jié)構(gòu)與唯一約束把并發(fā)問題交給數(shù)據(jù)庫寫業(yè)務(wù)代碼的人常有個錯覺覺得我在代碼里查過了沒重復(fù)那就不會重復(fù)。單線程下這話沒錯多線程和分布式環(huán)境下這行代碼等于沒寫。注冊接口的重復(fù)賬號問題最可靠的兜底方案永遠是數(shù)據(jù)庫的唯一索引。3.1 用戶表的最小字段集先上一份我認為比較克制、但足夠支撐后續(xù)擴展的建表語句CREATE TABLE t_user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, account VARCHAR(64) NOT NULL COMMENT 賬號手機號或郵箱已歸一化, account_type TINYINT NOT NULL DEFAULT 1 COMMENT 1手機號 2郵箱, password_hash VARCHAR(100) NOT NULL, nickname VARCHAR(32) NOT NULL DEFAULT , status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2禁用, register_channel VARCHAR(16) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted_at BIGINT NOT NULL DEFAULT 0 COMMENT 0 未刪除否則為刪除時間戳, PRIMARY KEY (id), UNIQUE KEY uk_account (account, deleted_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;幾個設(shè)計理由password_hash給 100 長度是因為 BCrypt 輸出固定 60 字符Argon2 可能更長留余量避免以后改表。status不要用布爾值業(yè)務(wù)早晚會有未激活已凍結(jié)已注銷這幾種狀態(tài)。時間字段統(tǒng)一用DATETIME并存 UTC別混用時間戳和字符串。3.2 軟刪除和唯一索引天生打架怎么解如果你直接UNIQUE KEY (account)那用戶注銷后想重新注冊同號就廢了——因為那條軟刪除的記錄還占著位置。常見解法有三種第一種是上面用的(account, deleted_at)組合唯一索引刪除時把deleted_at寫成刪除時刻的時間戳。因為未刪除記錄都是 0(account, 0)只能存在一條符合要求刪除后變成(account, 1723...)同號可以再注冊一條。這個方案唯一的坑是同一賬號被刪兩次會撞索引所以刪除邏輯里要先判斷deleted_at 0。第二種是物理刪除或者把賬號改寫比如加后綴實現(xiàn)簡單但丟失審計能力我不太推薦。第三種是單獨建一張注銷賬號表做歸檔主表物理刪除。適合合規(guī)要求高的場景。3.3 歸一化不做唯一索引就是個擺設(shè)這是我排查過最氣人的一類問題庫里出現(xiàn)了13800000000、138 0000 0000、13800000000尾部空格三條記錄唯一索引一條都沒攔住因為它們在字符串層面確實不相等。所以在進入業(yè)務(wù)邏輯之前必須做一次歸一化手機號去掉所有空格、橫線、括號和86前綴郵箱整體轉(zhuǎn)小寫嚴格說只有域名部分大小寫不敏感但實踐中整體小寫更省事且絕大多數(shù)服務(wù)商不區(qū)分賬號兩端trim。public static String normalize(String raw, int type) { if (raw null) return null; String s raw.trim(); if (type 1) { s s.replaceAll([\\s\\-()], ); if (s.startsWith(86)) s s.substring(3); if (s.startsWith(0086)) s s.substring(4); if (s.length() 13 s.startsWith(86)) s s.substring(2); } else { s s.toLowerCase(Locale.ROOT); } return s; }注意toLowerCase一定要帶Locale.ROOT不帶的話在土耳其語環(huán)境下I會被轉(zhuǎn)成?這是個真實存在過的經(jīng)典 bug。4. 接口實現(xiàn)骨架校驗、事務(wù)、異常三段切骨架理清楚之后代碼寫起來其實很快。我的分層習(xí)慣是把 Controller 做薄、Service 做業(yè)務(wù)編排、倉儲層只碰數(shù)據(jù)異常統(tǒng)一在一處兜。4.1 參數(shù)校驗分兩層別全塞進注解第一層是格式校驗用 Bean Validation 注解就能覆蓋非空、長度、正則。這一層的好處是失敗信息標準前端好處理。public class RegisterRequest { NotBlank(message 賬號不能為空) Size(max 64, message 賬號過長) private String account; NotBlank(message 密碼不能為空) private String password; Size(max 32, message 昵稱過長) private String nickname; private String channel; private String inviteCode; private String captchaToken; }第二層是業(yè)務(wù)校驗放 Service 里做賬號格式是否符合手機號/郵箱規(guī)則、密碼強度是否達標、驗證碼是否正確、賬號是否已存在。為什么不在注解里做完因為業(yè)務(wù)校驗往往要查庫、要調(diào)緩存、要讀配置放在參數(shù)綁定階段會讓事務(wù)和依賴注入變得很別扭。4.2 事務(wù)邊界要包住插入 初始化注冊不只是插一條用戶記錄通常還要初始化用戶資料、發(fā)積分、寫注冊流水、綁定渠道關(guān)系。這些動作要么全成功要么全回滾所以事務(wù)邊界必須包住它們。Transactional(rollbackFor Exception.class) public RegisterResult register(RegisterRequest req) { String account AccountUtil.normalize(req.getAccount(), type); checkPassword(req.getPassword()); if (userRepo.exists(account)) { throw new BizException(1101, 該賬號已注冊); } User user new User(); user.setAccount(account); user.setPasswordHash(passwordEncoder.encode(req.getPassword())); user.setNickname(defaultNickname(req.getNickname())); user.setRegisterChannel(req.getChannel()); try { userRepo.insert(user); } catch (DuplicateKeyException e) { throw new BizException(1101, 該賬號已注冊); } profileService.init(user.getId()); pointService.grantRegisterPoint(user.getId()); return new RegisterResult(user.getId(), tokenService.issue(user.getId())); }注意try-catch只包住 insert別把整個方法體包進去否則后續(xù)任何一處拋DuplicateKeyException比如 profile 表自己的唯一約束沖突都會被誤判成賬號已注冊排查起來非常痛苦。4.3 那個 exists 查詢到底要不要上面的代碼里我先查了一次exists然后插入時又靠唯一索引兜底。有人會問既然唯一索引能兜查這一次不是浪費我的判斷是要查但要知道它只是為了體驗。查詢的作用是讓 99% 的重復(fù)注冊請求走快速失敗路徑返回一個明確的已注冊而不是讓它們都觸發(fā)一次數(shù)據(jù)庫異常。異常路徑的成本高得多——要構(gòu)造異常對象、要回滾事務(wù)、日志里還會留一堆堆棧。所以這個查詢是優(yōu)化不是防線防線永遠是唯一索引。如果你的接口 QPS 很高這次查詢可以改成查緩存但要接受緩存和數(shù)據(jù)庫之間的短暫不一致最終仍以唯一索引為準。4.4 異常統(tǒng)一處理別把堆棧吐給前端用RestControllerAdvice收口所有異常業(yè)務(wù)異常轉(zhuǎn)成對應(yīng)的 code未捕獲異常統(tǒng)一轉(zhuǎn) 1500 并打日志帶上 traceId、入?yún)⒚撁艉髢?nèi)容。ExceptionHandler(BizException.class) public Result? handleBiz(BizException e) { return Result.fail(e.getCode(), e.getMessage()); } ExceptionHandler(Exception.class) public Result? handleOther(Exception e) { log.error(register error traceId{}, TraceContext.get(), e); return Result.fail(1500, 服務(wù)繁忙請稍后重試); }入?yún)⑷罩疽欢ㄒ撁?。密碼、驗證碼這些字段在打印請求體前要替換成***我見過某次排查問題直接把日志拖出來發(fā)群里里面幾百條明文密碼的場面。5. 一次重復(fù)賬號的完整排查鏈路理論講完說個真實復(fù)盤細節(jié)做了模糊處理。某次上線后第二天運營反饋有用戶在后臺看到兩個一模一樣的手機號只是 id 不同。這條線索足夠把整個鏈路翻一遍。5.1 現(xiàn)象確認到底是數(shù)據(jù)重復(fù)還是展示重復(fù)第一步不是改代碼是確認現(xiàn)象。我拉了三樣?xùn)|西那兩條記錄的完整字段、對應(yīng)時間段的接口訪問日志、以及用戶的操作軌跡。結(jié)果很快出來兩條記錄創(chuàng)建時間相差 1.2 秒created_at精確到秒級別的差距register_channel一條是web一條是h5。這說明是同一個人在兩個端先后點了注冊而不是數(shù)據(jù)同步問題。5.2 逐層排除為什么唯一索引沒攔住接下來就是最關(guān)鍵的一步——查索引。執(zhí)行SHOW CREATE TABLE t_user發(fā)現(xiàn)線上表根本沒有uk_account這個索引。追問之后才知道當初建表腳本里有但某次加字段的變更腳本是照著舊版本建的把唯一索引漏掉了DDL 執(zhí)行時也沒人核對。這里我要強調(diào)排查思路遇到本該被約束住卻沒約束住的問題第一順位永遠是確認約束是否存在第二順位才是確認約束是否生效比如字段是否被隱式轉(zhuǎn)換、是否有 NULL。別一上來就懷疑框架、懷疑事務(wù)隔離級別那是最費時間的方向。順便查了下SHOW INDEX FROM t_user確認只有主鍵。問題定位完成。5.3 修復(fù)與驗證以及怎么防止再犯修復(fù)分三步走先補索引建之前要先清理存量重復(fù)數(shù)據(jù)否則 DDL 直接失敗再加應(yīng)用層的兜底捕獲最后把這次事故變成一個可執(zhí)行的檢查項。清理重復(fù)數(shù)據(jù)的 SQL 大致是這樣保留每組最早的一條DELETE t1 FROM t_user t1 INNER JOIN t_user t2 ON t1.account t2.account AND t1.id t2.id WHERE t1.deleted_at 0 AND t2.deleted_at 0;加索引用ALTER TABLE t_user ADD UNIQUE KEY uk_account (account, deleted_at)注意大表要評估鎖表風(fēng)險必要時用在線 DDL 工具在低峰期執(zhí)行。驗證階段我寫了一個并發(fā)測試腳本開 50 個線程同時用同一個手機號注冊期望結(jié)果是 1 條成功、49 條返回 1101。修復(fù)前這個用例必然失敗修復(fù)后必須 100% 通過。這個腳本后來被我放進了回歸用例集每次改動注冊相關(guān)代碼都跑一遍。至于防止再犯我做的事很樸素把關(guān)鍵索引清單寫進發(fā)布檢查表每次涉及表結(jié)構(gòu)變更發(fā)布前必須對照清單核驗一遍。檢查項驗證方式頻率賬號唯一索引存在SHOW INDEX FROM t_user每次表變更索引列與歸一化邏輯一致代碼 review每次改動并發(fā)重復(fù)注冊用例通過自動化腳本每次發(fā)布存量重復(fù)數(shù)據(jù)為 0定時巡檢 SQL每天6. 上線前的加固頻控、驗證碼與那些看不見的成本接口功能跑通只是及格線真正決定它能不能放在公網(wǎng)上的是防護做得夠不夠。6.1 頻控放在網(wǎng)關(guān)還是業(yè)務(wù)層我的答案是兩層都放粒度不同。網(wǎng)關(guān)層做粗粒度限流比如單 IP 每分鐘 60 次目的是擋住明顯的腳本掃描成本極低配置幾行就完事。業(yè)務(wù)層做細粒度控制比如同一手機號 60 秒內(nèi)只能發(fā)一次驗證碼同一設(shè)備指紋 24 小時內(nèi)最多注冊 3 個賬號這類規(guī)則需要讀業(yè)務(wù)數(shù)據(jù)放網(wǎng)關(guān)不合適。業(yè)務(wù)層頻控用 Redis 的滑動窗口或者簡單的SET key value NX EX就夠了別一上來就上復(fù)雜組件。關(guān)鍵在于 key 的設(shè)計要能區(qū)分維度reg:mobile:{account}、reg:ip:{ip}、reg:device:{deviceId}三個維度任一超限就攔。6.2 注冊接口要不要提示該賬號已注冊這是個產(chǎn)品和技術(shù)要一起決策的點。從安全角度直接提示已注冊意味著接口可以被用來枚舉哪些手機號在你們平臺注冊過這是實打?qū)嵉男畔⑿孤?。但從業(yè)務(wù)角度注冊頁不提示的話用戶體驗極差——用戶輸完密碼點提交得到一句操作失敗然后呢我的實踐結(jié)論是注冊場景直接提示登錄和找回密碼場景模糊處理。理由是注冊頁本身就要發(fā)驗證碼驗證碼環(huán)節(jié)已經(jīng)把枚舉成本抬得很高了每次枚舉都要消耗一條短信而登錄接口如果提示密碼錯誤而不是賬號不存在攻擊者就無法批量判斷賬號是否存在。這個取舍沒有標準答案但要明確寫進設(shè)計文檔別讓后人以為你忘了。6.3 注冊成功后的異步動作歡迎消息、初始化推薦數(shù)據(jù)、發(fā)券、埋點上報這些動作都不該阻塞注冊響應(yīng)。我的做法是發(fā)一條領(lǐng)域事件異步消費。但這里有個坑異步動作失敗要不要回滾注冊答案通常是不要。注冊是主流程發(fā)券失敗可以補償不能因為營銷系統(tǒng)掛了讓用戶注冊不了。所以異步消費必須做重試和死信處理并且要有對賬機制——每天跑一次注冊用戶數(shù) vs 發(fā)券記錄數(shù)差得多就報警。7. 自測清單讓接口在提測前就接近可用我?guī)У捻椖坷镒越涌谔釡y前必須自己跑完一份清單這份清單幫我省下了大量來回溝通。7.1 邊界用例按這個順序過一遍用例期望結(jié)果正常手機號 合規(guī)密碼成功返回 userId 和 token手機號帶空格、帶 86歸一化后成功郵箱大小寫混寫歸一化后可登錄密碼 7 位 / 65 位返回 1002密碼 64 個漢字192 字節(jié)返回 1002不得靜默截斷已注冊賬號重復(fù)提交返回 1101同賬號并發(fā) 50 次1 成功 49 失敗驗證碼錯誤 / 過期 / 重復(fù)使用分別返回對應(yīng)錯誤碼超頻提交返回 1201數(shù)據(jù)庫連接斷開返回 1500日志有 traceId最后一條特別容易被忽略。我習(xí)慣在測試環(huán)境手動停一下數(shù)據(jù)庫連接池看接口返回的是不是友好的 1500而不是一個 500 加一段堆棧。這個動作花不了一分鐘但能避免上線后前端拿到看不懂的響應(yīng)。7.2 壓測看什么指標注冊接口的壓測重點不是吞吐而是哈希計算對 CPU 的影響。我會關(guān)注三個數(shù)單次請求耗時中位數(shù)、P99、以及壓測期間機器的 CPU 使用率曲線。如果 P99 是中位數(shù)的 5 倍以上基本可以斷定是哈希線程池排隊或者數(shù)據(jù)庫連接池不夠而不是業(yè)務(wù)邏輯慢。另外要觀察 Redis 頻控 key 的增長速度如果發(fā)現(xiàn)某個 IP 維度產(chǎn)生了海量 key說明限流閾值設(shè)得太松需要收緊。最后分享一個我在實際操作中的習(xí)慣注冊接口的每一次改動我都會把上面那份清單里最靠前的三條和并發(fā)那條重新跑一遍不管改動多小。這四條覆蓋了歸一化、校驗、唯一約束和冪等四個最容易出問題的地方跑完心里就踏實了。 后端注冊接口實戰(zhàn)：契約設(shè)計、密碼存儲與唯一索引兜底
1. 先釘死接口契約再動手寫代碼寫注冊接口這件事很多人第一反應(yīng)是打開 IDE 建個 Controller然后一邊寫一邊想字段。我見過太多項目在這個環(huán)節(jié)翻車前端調(diào)了兩天發(fā)現(xiàn)字段對不上測試提了十幾個為什么這里返回 500上線后運維發(fā)現(xiàn)日志里全是空指針。真正省時間的做法恰好相反——先把契約寫在紙上包括請求字段、返回結(jié)構(gòu)、錯誤碼、冪等規(guī)則再開始寫第一行業(yè)務(wù)代碼。注冊接口看著簡單它卻是整個賬號體系的入口字段定義一旦定下來后面改一次要牽動登錄、找回密碼、第三方綁定、用戶中心一大串模塊。這篇文章講的是「后端系統(tǒng)開發(fā)之——創(chuàng)建注冊接口」我會把它當成一次完整的實戰(zhàn)復(fù)盤來做從契約設(shè)計、密碼存儲、表結(jié)構(gòu)與唯一約束、事務(wù)與并發(fā)、頻控加固一直講到聯(lián)調(diào)自測。適合剛接觸后端業(yè)務(wù)開發(fā)、準備寫第一個正式接口的朋友也適合做了一兩年但一直靠能跑就行撐著的同行——里面有不少地方是踩過坑之后才知道該這么寫的。1.1 一個注冊請求到底該收哪些字段先把字段分成三類身份憑證、可選資料、上下文信息。身份憑證是必須的通常是手機號或郵箱二選一加一個密碼可選資料是昵稱、頭像、邀請碼這類缺了也能創(chuàng)建賬號上下文信息是客戶端類型、渠道來源、設(shè)備標識用來做風(fēng)控和后期分析一般不參與業(yè)務(wù)校驗。分清楚這三類好處是校驗邏輯可以分層身份憑證缺失直接 400可選資料缺失走默認值上下文信息缺失只記一條告警不阻斷流程。我見過把邀請碼做成必填的接口注冊轉(zhuǎn)化率直接掉了三成后來才發(fā)現(xiàn)是運營在某次活動頁跳轉(zhuǎn)時沒帶參數(shù)。下面這份請求體是我目前項目里用的最小集合可以直接參考{ account: 13800000000, password: Abc123456, nickname: 路人甲, channel: web, inviteCode: XK92A, captchaToken: c_8f3a... }幾個細節(jié)值得說清楚。account用一個字段同時承載手機號和郵箱靠正則區(qū)分類型好處是前端只渲染一個輸入框缺點是后端每次都要做類型判斷如果你的業(yè)務(wù)明確只支持手機號那就老老實實叫mobile別為了以后可能支持郵箱提前抽象抽象是有成本的。password只做長度和字符集校驗絕不在請求體里做業(yè)務(wù)語義上的復(fù)雜度提示那屬于前端體驗層的事后端只守住底線。captchaToken這類字段建議單獨抽出來別和業(yè)務(wù)字段混在一起因為它對應(yīng)的校驗邏輯是一次性消耗和冪等、事務(wù)的邊界完全不同。1.2 返回體與錯誤碼別讓前端靠猜返回結(jié)構(gòu)我堅持用統(tǒng)一信封{ code: 0, message: ok, data: { userId: 10231, token: eyJ... }, traceId: a1b2c3d4 }code為 0 表示成功非 0 是業(yè)務(wù)錯誤碼HTTP 狀態(tài)碼只用來表達傳輸層語義200/400/401/500不要用 HTTP 狀態(tài)碼承載業(yè)務(wù)錯誤否則前端要寫一大堆if (status 409)的分支網(wǎng)關(guān)層的統(tǒng)一重試策略也會被誤導(dǎo)。traceId是我強烈建議加上的字段用戶截圖報錯時你拿著 traceId 能直接定位到那一條完整日志鏈路排查效率的提升是數(shù)量級的。錯誤碼要給區(qū)間規(guī)劃別隨手編號區(qū)間含義示例0成功01000-1099參數(shù)與格式錯誤1001 賬號格式不正確1100-1199業(yè)務(wù)規(guī)則攔截1101 該賬號已注冊1200-1299頻控與風(fēng)控1201 操作過于頻繁1500-1599系統(tǒng)內(nèi)部異常1500 服務(wù)繁忙請稍后重試規(guī)劃好區(qū)間前端可以按百位做統(tǒng)一提示文案后端加新錯誤碼也不至于撞號。1.3 三個最容易被忽略的隱含需求第一是冪等。用戶手抖點兩下、網(wǎng)絡(luò)超時自動重試、客戶端做了一次重發(fā)這些場景在移動端是常態(tài)。注冊接口如果不做冪等結(jié)果就是數(shù)據(jù)庫里出現(xiàn)兩條同號賬號或者第二條請求報已注冊而用戶以為自己沒注冊成功。第二是來源校驗。開放公網(wǎng)的注冊接口一定會被掃加一個來源白名單或者簽名校驗?zāi)軗醯粝喈斠徊糠值图壞_本。第三是注冊成功后的返回內(nèi)容。要不要直接返回登錄 token我的做法是返回理由是省一次登錄往返用戶體驗上順滑很多代價是注冊接口要依賴簽發(fā) token 的模塊耦合度略高。如果團隊對登錄態(tài)有更嚴格的要求比如必須二次校驗設(shè)備指紋那就只返回 userId讓前端跳登錄頁。提示契約定稿后寫成一份接口文檔并納入版本管理字段增刪要走變更流程。我吃過一次虧某同學(xué)為了趕需求悄悄把nickname改成必填結(jié)果老版本 App 全量報錯。2. 密碼存儲的取舍算法、參數(shù)與那條 72 字節(jié)的暗線密碼這塊是最不該省事的地方也是最容易埋雷的地方。我見過用 MD5 存的、用 MD5 加固定鹽存的、用 Base64 當加密的每一種都能在出事后把團隊拖進深坑。2.1 為什么自己拼 MD5 加鹽基本等于沒加哈希算法的核心指標是計算速度。MD5 和 SHA-256 是為快設(shè)計的一張消費級顯卡每秒能算幾十億次。這意味著攻擊者拿到庫之后用常見密碼字典跑一遍弱密碼半小時內(nèi)就能還原出明文。加鹽確實能擋住彩虹表但擋不住針對單個賬號的暴力枚舉——因為快。真正適合存密碼的是慢哈希BCrypt、scrypt、Argon2 這一類設(shè)計目標就是故意算得慢而且慢的程度可以通過參數(shù)調(diào)節(jié)。它們內(nèi)置了每個用戶獨立的鹽輸出串里自帶算法標識、成本參數(shù)和鹽值不需要你額外建字段存鹽。這一點特別重要自己管理鹽的代碼十個有八個在某個分支里寫錯。2.2 成本參數(shù)到底該設(shè)多少BCrypt 的成本參數(shù)是cost每加 1計算耗時翻一倍。常用的cost10在普通云主機上單次哈希大約 50-100ms。這個數(shù)值不是拍腦袋定的要結(jié)合你的硬件和流量算一筆賬。估算邏輯是這樣的假設(shè)注冊加登錄合計峰值 300 QPS每次哈希按 80ms 計那么同時處于哈希計算中的請求數(shù)為 300 × 0.08 24。這部分是純 CPU 密集操作一個 4 核機器基本扛不住你會看到 CPU 打滿、請求排隊、P99 飆到幾秒。反過來說如果你現(xiàn)在只有 20 QPS那cost12完全沒問題安全性還更高。我給的經(jīng)驗區(qū)間是cost10起步實測單次耗時控制在 100ms 以內(nèi)壓測確認 CPU 余量大于 50%。真要更高強度就上 Argon2id 并調(diào)內(nèi)存參數(shù)或者把哈希計算挪到獨立的線程池/服務(wù)里別和業(yè)務(wù)線程搶資源。還有個參數(shù)叫strengthBCryptPasswordEncoder 里的版本默認 10注意它和cost是同一個東西的兩種叫法別在配置里寫成兩個值。2.3 BCrypt 只認前 72 字節(jié)這個坑很隱蔽這是我最想強調(diào)的一條。BCrypt 的算法設(shè)計只處理輸入的前 72 個字節(jié)超出部分被靜默截斷。也就是說如果你允許用戶設(shè)置超長密碼第 73 個字節(jié)之后的內(nèi)容完全不參與計算兩個前 72 字節(jié)相同的密碼會被判定為同一個密碼。更麻煩的是中文密碼——一個漢字在 UTF-8 下占 3 個字節(jié)72 字節(jié)大約只夠 24 個漢字。有些庫在超長時會直接拋異常Spring Security 的某些版本就會有些庫則默默截斷行為不一致。所以我的做法是在參數(shù)校驗層就把密碼長度卡死在 8 到 64 個字符并且明確按字節(jié)數(shù)再校驗一次不超過 72 字節(jié)。private static void checkPassword(String pwd) { if (pwd null || pwd.length() 8 || pwd.length() 64) { throw new BizException(1002, 密碼長度需在 8-64 個字符之間); } if (pwd.getBytes(StandardCharsets.UTF_8).length 72) { throw new BizException(1002, 密碼過于復(fù)雜請適當縮短); } }另外補一句pepper全局密鑰不是必須的但如果你擔心庫被拖走后成本參數(shù)不夠用可以在哈希前拼一段存在配置中心或環(huán)境變量里的密鑰。代價是密鑰輪換時所有存量密碼都要重算所以一般只在新項目里上老項目別折騰。3. 表結(jié)構(gòu)與唯一約束把并發(fā)問題交給數(shù)據(jù)庫寫業(yè)務(wù)代碼的人常有個錯覺覺得我在代碼里查過了沒重復(fù)那就不會重復(fù)。單線程下這話沒錯多線程和分布式環(huán)境下這行代碼等于沒寫。注冊接口的重復(fù)賬號問題最可靠的兜底方案永遠是數(shù)據(jù)庫的唯一索引。3.1 用戶表的最小字段集先上一份我認為比較克制、但足夠支撐后續(xù)擴展的建表語句CREATE TABLE t_user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, account VARCHAR(64) NOT NULL COMMENT 賬號手機號或郵箱已歸一化, account_type TINYINT NOT NULL DEFAULT 1 COMMENT 1手機號 2郵箱, password_hash VARCHAR(100) NOT NULL, nickname VARCHAR(32) NOT NULL DEFAULT , status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2禁用, register_channel VARCHAR(16) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted_at BIGINT NOT NULL DEFAULT 0 COMMENT 0 未刪除否則為刪除時間戳, PRIMARY KEY (id), UNIQUE KEY uk_account (account, deleted_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;幾個設(shè)計理由password_hash給 100 長度是因為 BCrypt 輸出固定 60 字符Argon2 可能更長留余量避免以后改表。status不要用布爾值業(yè)務(wù)早晚會有未激活已凍結(jié)已注銷這幾種狀態(tài)。時間字段統(tǒng)一用DATETIME并存 UTC別混用時間戳和字符串。3.2 軟刪除和唯一索引天生打架怎么解如果你直接UNIQUE KEY (account)那用戶注銷后想重新注冊同號就廢了——因為那條軟刪除的記錄還占著位置。常見解法有三種第一種是上面用的(account, deleted_at)組合唯一索引刪除時把deleted_at寫成刪除時刻的時間戳。因為未刪除記錄都是 0(account, 0)只能存在一條符合要求刪除后變成(account, 1723...)同號可以再注冊一條。這個方案唯一的坑是同一賬號被刪兩次會撞索引所以刪除邏輯里要先判斷deleted_at 0。第二種是物理刪除或者把賬號改寫比如加后綴實現(xiàn)簡單但丟失審計能力我不太推薦。第三種是單獨建一張注銷賬號表做歸檔主表物理刪除。適合合規(guī)要求高的場景。3.3 歸一化不做唯一索引就是個擺設(shè)這是我排查過最氣人的一類問題庫里出現(xiàn)了13800000000、138 0000 0000、13800000000尾部空格三條記錄唯一索引一條都沒攔住因為它們在字符串層面確實不相等。所以在進入業(yè)務(wù)邏輯之前必須做一次歸一化手機號去掉所有空格、橫線、括號和86前綴郵箱整體轉(zhuǎn)小寫嚴格說只有域名部分大小寫不敏感但實踐中整體小寫更省事且絕大多數(shù)服務(wù)商不區(qū)分賬號兩端trim。public static String normalize(String raw, int type) { if (raw null) return null; String s raw.trim(); if (type 1) { s s.replaceAll([\\s\\-()], ); if (s.startsWith(86)) s s.substring(3); if (s.startsWith(0086)) s s.substring(4); if (s.length() 13 s.startsWith(86)) s s.substring(2); } else { s s.toLowerCase(Locale.ROOT); } return s; }注意toLowerCase一定要帶Locale.ROOT不帶的話在土耳其語環(huán)境下I會被轉(zhuǎn)成?這是個真實存在過的經(jīng)典 bug。4. 接口實現(xiàn)骨架校驗、事務(wù)、異常三段切骨架理清楚之后代碼寫起來其實很快。我的分層習(xí)慣是把 Controller 做薄、Service 做業(yè)務(wù)編排、倉儲層只碰數(shù)據(jù)異常統(tǒng)一在一處兜。4.1 參數(shù)校驗分兩層別全塞進注解第一層是格式校驗用 Bean Validation 注解就能覆蓋非空、長度、正則。這一層的好處是失敗信息標準前端好處理。public class RegisterRequest { NotBlank(message 賬號不能為空) Size(max 64, message 賬號過長) private String account; NotBlank(message 密碼不能為空) private String password; Size(max 32, message 昵稱過長) private String nickname; private String channel; private String inviteCode; private String captchaToken; }第二層是業(yè)務(wù)校驗放 Service 里做賬號格式是否符合手機號/郵箱規(guī)則、密碼強度是否達標、驗證碼是否正確、賬號是否已存在。為什么不在注解里做完因為業(yè)務(wù)校驗往往要查庫、要調(diào)緩存、要讀配置放在參數(shù)綁定階段會讓事務(wù)和依賴注入變得很別扭。4.2 事務(wù)邊界要包住插入 初始化注冊不只是插一條用戶記錄通常還要初始化用戶資料、發(fā)積分、寫注冊流水、綁定渠道關(guān)系。這些動作要么全成功要么全回滾所以事務(wù)邊界必須包住它們。Transactional(rollbackFor Exception.class) public RegisterResult register(RegisterRequest req) { String account AccountUtil.normalize(req.getAccount(), type); checkPassword(req.getPassword()); if (userRepo.exists(account)) { throw new BizException(1101, 該賬號已注冊); } User user new User(); user.setAccount(account); user.setPasswordHash(passwordEncoder.encode(req.getPassword())); user.setNickname(defaultNickname(req.getNickname())); user.setRegisterChannel(req.getChannel()); try { userRepo.insert(user); } catch (DuplicateKeyException e) { throw new BizException(1101, 該賬號已注冊); } profileService.init(user.getId()); pointService.grantRegisterPoint(user.getId()); return new RegisterResult(user.getId(), tokenService.issue(user.getId())); }注意try-catch只包住 insert別把整個方法體包進去否則后續(xù)任何一處拋DuplicateKeyException比如 profile 表自己的唯一約束沖突都會被誤判成賬號已注冊排查起來非常痛苦。4.3 那個 exists 查詢到底要不要上面的代碼里我先查了一次exists然后插入時又靠唯一索引兜底。有人會問既然唯一索引能兜查這一次不是浪費我的判斷是要查但要知道它只是為了體驗。查詢的作用是讓 99% 的重復(fù)注冊請求走快速失敗路徑返回一個明確的已注冊而不是讓它們都觸發(fā)一次數(shù)據(jù)庫異常。異常路徑的成本高得多——要構(gòu)造異常對象、要回滾事務(wù)、日志里還會留一堆堆棧。所以這個查詢是優(yōu)化不是防線防線永遠是唯一索引。如果你的接口 QPS 很高這次查詢可以改成查緩存但要接受緩存和數(shù)據(jù)庫之間的短暫不一致最終仍以唯一索引為準。4.4 異常統(tǒng)一處理別把堆棧吐給前端用RestControllerAdvice收口所有異常業(yè)務(wù)異常轉(zhuǎn)成對應(yīng)的 code未捕獲異常統(tǒng)一轉(zhuǎn) 1500 并打日志帶上 traceId、入?yún)⒚撁艉髢?nèi)容。ExceptionHandler(BizException.class) public Result? handleBiz(BizException e) { return Result.fail(e.getCode(), e.getMessage()); } ExceptionHandler(Exception.class) public Result? handleOther(Exception e) { log.error(register error traceId{}, TraceContext.get(), e); return Result.fail(1500, 服務(wù)繁忙請稍后重試); }入?yún)⑷罩疽欢ㄒ撁?。密碼、驗證碼這些字段在打印請求體前要替換成***我見過某次排查問題直接把日志拖出來發(fā)群里里面幾百條明文密碼的場面。5. 一次重復(fù)賬號的完整排查鏈路理論講完說個真實復(fù)盤細節(jié)做了模糊處理。某次上線后第二天運營反饋有用戶在后臺看到兩個一模一樣的手機號只是 id 不同。這條線索足夠把整個鏈路翻一遍。5.1 現(xiàn)象確認到底是數(shù)據(jù)重復(fù)還是展示重復(fù)第一步不是改代碼是確認現(xiàn)象。我拉了三樣?xùn)|西那兩條記錄的完整字段、對應(yīng)時間段的接口訪問日志、以及用戶的操作軌跡。結(jié)果很快出來兩條記錄創(chuàng)建時間相差 1.2 秒created_at精確到秒級別的差距register_channel一條是web一條是h5。這說明是同一個人在兩個端先后點了注冊而不是數(shù)據(jù)同步問題。5.2 逐層排除為什么唯一索引沒攔住接下來就是最關(guān)鍵的一步——查索引。執(zhí)行SHOW CREATE TABLE t_user發(fā)現(xiàn)線上表根本沒有uk_account這個索引。追問之后才知道當初建表腳本里有但某次加字段的變更腳本是照著舊版本建的把唯一索引漏掉了DDL 執(zhí)行時也沒人核對。這里我要強調(diào)排查思路遇到本該被約束住卻沒約束住的問題第一順位永遠是確認約束是否存在第二順位才是確認約束是否生效比如字段是否被隱式轉(zhuǎn)換、是否有 NULL。別一上來就懷疑框架、懷疑事務(wù)隔離級別那是最費時間的方向。順便查了下SHOW INDEX FROM t_user確認只有主鍵。問題定位完成。5.3 修復(fù)與驗證以及怎么防止再犯修復(fù)分三步走先補索引建之前要先清理存量重復(fù)數(shù)據(jù)否則 DDL 直接失敗再加應(yīng)用層的兜底捕獲最后把這次事故變成一個可執(zhí)行的檢查項。清理重復(fù)數(shù)據(jù)的 SQL 大致是這樣保留每組最早的一條DELETE t1 FROM t_user t1 INNER JOIN t_user t2 ON t1.account t2.account AND t1.id t2.id WHERE t1.deleted_at 0 AND t2.deleted_at 0;加索引用ALTER TABLE t_user ADD UNIQUE KEY uk_account (account, deleted_at)注意大表要評估鎖表風(fēng)險必要時用在線 DDL 工具在低峰期執(zhí)行。驗證階段我寫了一個并發(fā)測試腳本開 50 個線程同時用同一個手機號注冊期望結(jié)果是 1 條成功、49 條返回 1101。修復(fù)前這個用例必然失敗修復(fù)后必須 100% 通過。這個腳本后來被我放進了回歸用例集每次改動注冊相關(guān)代碼都跑一遍。至于防止再犯我做的事很樸素把關(guān)鍵索引清單寫進發(fā)布檢查表每次涉及表結(jié)構(gòu)變更發(fā)布前必須對照清單核驗一遍。檢查項驗證方式頻率賬號唯一索引存在SHOW INDEX FROM t_user每次表變更索引列與歸一化邏輯一致代碼 review每次改動并發(fā)重復(fù)注冊用例通過自動化腳本每次發(fā)布存量重復(fù)數(shù)據(jù)為 0定時巡檢 SQL每天6. 上線前的加固頻控、驗證碼與那些看不見的成本接口功能跑通只是及格線真正決定它能不能放在公網(wǎng)上的是防護做得夠不夠。6.1 頻控放在網(wǎng)關(guān)還是業(yè)務(wù)層我的答案是兩層都放粒度不同。網(wǎng)關(guān)層做粗粒度限流比如單 IP 每分鐘 60 次目的是擋住明顯的腳本掃描成本極低配置幾行就完事。業(yè)務(wù)層做細粒度控制比如同一手機號 60 秒內(nèi)只能發(fā)一次驗證碼同一設(shè)備指紋 24 小時內(nèi)最多注冊 3 個賬號這類規(guī)則需要讀業(yè)務(wù)數(shù)據(jù)放網(wǎng)關(guān)不合適。業(yè)務(wù)層頻控用 Redis 的滑動窗口或者簡單的SET key value NX EX就夠了別一上來就上復(fù)雜組件。關(guān)鍵在于 key 的設(shè)計要能區(qū)分維度reg:mobile:{account}、reg:ip:{ip}、reg:device:{deviceId}三個維度任一超限就攔。6.2 注冊接口要不要提示該賬號已注冊這是個產(chǎn)品和技術(shù)要一起決策的點。從安全角度直接提示已注冊意味著接口可以被用來枚舉哪些手機號在你們平臺注冊過這是實打?qū)嵉男畔⑿孤?。但從業(yè)務(wù)角度注冊頁不提示的話用戶體驗極差——用戶輸完密碼點提交得到一句操作失敗然后呢我的實踐結(jié)論是注冊場景直接提示登錄和找回密碼場景模糊處理。理由是注冊頁本身就要發(fā)驗證碼驗證碼環(huán)節(jié)已經(jīng)把枚舉成本抬得很高了每次枚舉都要消耗一條短信而登錄接口如果提示密碼錯誤而不是賬號不存在攻擊者就無法批量判斷賬號是否存在。這個取舍沒有標準答案但要明確寫進設(shè)計文檔別讓后人以為你忘了。6.3 注冊成功后的異步動作歡迎消息、初始化推薦數(shù)據(jù)、發(fā)券、埋點上報這些動作都不該阻塞注冊響應(yīng)。我的做法是發(fā)一條領(lǐng)域事件異步消費。但這里有個坑異步動作失敗要不要回滾注冊答案通常是不要。注冊是主流程發(fā)券失敗可以補償不能因為營銷系統(tǒng)掛了讓用戶注冊不了。所以異步消費必須做重試和死信處理并且要有對賬機制——每天跑一次注冊用戶數(shù) vs 發(fā)券記錄數(shù)差得多就報警。7. 自測清單讓接口在提測前就接近可用我?guī)У捻椖坷镒越涌谔釡y前必須自己跑完一份清單這份清單幫我省下了大量來回溝通。7.1 邊界用例按這個順序過一遍用例期望結(jié)果正常手機號 合規(guī)密碼成功返回 userId 和 token手機號帶空格、帶 86歸一化后成功郵箱大小寫混寫歸一化后可登錄密碼 7 位 / 65 位返回 1002密碼 64 個漢字192 字節(jié)返回 1002不得靜默截斷已注冊賬號重復(fù)提交返回 1101同賬號并發(fā) 50 次1 成功 49 失敗驗證碼錯誤 / 過期 / 重復(fù)使用分別返回對應(yīng)錯誤碼超頻提交返回 1201數(shù)據(jù)庫連接斷開返回 1500日志有 traceId最后一條特別容易被忽略。我習(xí)慣在測試環(huán)境手動停一下數(shù)據(jù)庫連接池看接口返回的是不是友好的 1500而不是一個 500 加一段堆棧。這個動作花不了一分鐘但能避免上線后前端拿到看不懂的響應(yīng)。7.2 壓測看什么指標注冊接口的壓測重點不是吞吐而是哈希計算對 CPU 的影響。我會關(guān)注三個數(shù)單次請求耗時中位數(shù)、P99、以及壓測期間機器的 CPU 使用率曲線。如果 P99 是中位數(shù)的 5 倍以上基本可以斷定是哈希線程池排隊或者數(shù)據(jù)庫連接池不夠而不是業(yè)務(wù)邏輯慢。另外要觀察 Redis 頻控 key 的增長速度如果發(fā)現(xiàn)某個 IP 維度產(chǎn)生了海量 key說明限流閾值設(shè)得太松需要收緊。最后分享一個我在實際操作中的習(xí)慣注冊接口的每一次改動我都會把上面那份清單里最靠前的三條和并發(fā)那條重新跑一遍不管改動多小。這四條覆蓋了歸一化、校驗、唯一約束和冪等四個最容易出問題的地方跑完心里就踏實了。