提交與冪等性實(shí)戰(zhàn)方案)
1. 項(xiàng)目概述為什么接口防抖和防重復(fù)提交不是“可選項(xiàng)”而是上線前的必答題你有沒有遇到過這樣的場景用戶在電商App里點(diǎn)下“立即支付”按鈕手指剛抬起來頁面還沒跳轉(zhuǎn)就又連點(diǎn)兩次——結(jié)果后臺(tái)收到了三條一模一樣的支付請求或者在后臺(tái)管理系統(tǒng)中運(yùn)營人員雙擊“發(fā)布文章”按鈕數(shù)據(jù)庫里憑空多出兩條狀態(tài)為“已發(fā)布”的記錄更隱蔽的是前端網(wǎng)絡(luò)延遲導(dǎo)致用戶誤以為操作失敗反復(fù)刷新重試后端日志里全是重復(fù)的訂單創(chuàng)建流水。這些都不是小概率事件而是每天在成千上萬系統(tǒng)中真實(shí)發(fā)生的“高頻低智型故障”。我?guī)н^的三個(gè)不同行業(yè)的項(xiàng)目某高校教務(wù)系統(tǒng)、某本地生活服務(wù)平臺(tái)、某工業(yè)設(shè)備遠(yuǎn)程監(jiān)控平臺(tái)上線后第一周的告警日志里有23%~37%都指向同一類問題非惡意但不可控的重復(fù)請求。SpringBoot本身不提供開箱即用的防重復(fù)機(jī)制它默認(rèn)把“請求是否合法”交給開發(fā)者判斷“請求是否新鮮”則完全交由業(yè)務(wù)邏輯兜底——這就像給一輛新車配好了發(fā)動(dòng)機(jī)和方向盤卻沒裝剎車片能跑但不敢急剎。所謂“接口防抖”本質(zhì)是在服務(wù)端對(duì)高頻、短時(shí)、語義相同的請求做主動(dòng)攔截或合并它不是前端debounce的簡單后端復(fù)刻而是結(jié)合HTTP協(xié)議特征、業(yè)務(wù)語義邊界、數(shù)據(jù)一致性要求的綜合策略而“防重復(fù)提交”更聚焦于冪等性保障——確保同一個(gè)業(yè)務(wù)動(dòng)作無論執(zhí)行一次還是十次最終產(chǎn)生的業(yè)務(wù)效果完全一致。這兩個(gè)概念常被混談但實(shí)操中必須拆解防抖解決“不該發(fā)的請求別進(jìn)來”防重復(fù)解決“進(jìn)來的請求別干壞事”。本文不講抽象理論只分享我在真實(shí)壓測環(huán)境和灰度發(fā)布中驗(yàn)證過的四套方案基于Redis的Token令牌機(jī)制、基于數(shù)據(jù)庫唯一約束的樂觀冪等、基于請求指紋的輕量攔截以及混合式兜底策略。所有代碼均適配SpringBoot 2.7與3.x雙版本配置項(xiàng)可直接復(fù)制粘貼參數(shù)值附帶計(jì)算依據(jù)比如為什么Redis過期時(shí)間設(shè)為5分鐘而非30秒關(guān)鍵步驟標(biāo)注了“踩坑現(xiàn)場還原”。如果你正被測試同學(xué)指著日志說“這個(gè)接口點(diǎn)了三次訂單生成了三單”或者正在寫技術(shù)方案文檔卡在“如何保證冪等性”這一節(jié)——這篇就是為你寫的。2. 核心設(shè)計(jì)思路拆解為什么不能只靠前端防抖四種方案的選型邏輯與適用邊界很多團(tuán)隊(duì)第一反應(yīng)是“讓前端加個(gè)防抖”這就像用創(chuàng)可貼止住動(dòng)脈出血——治標(biāo)不治本。前端防抖只能約束“用戶主動(dòng)觸發(fā)”的行為但無法覆蓋以下真實(shí)場景用戶禁用JavaScript后直接curl調(diào)用接口Postman或JMeter壓測時(shí)故意構(gòu)造重復(fù)請求第三方系統(tǒng)回調(diào)如支付網(wǎng)關(guān)異步通知因網(wǎng)絡(luò)抖動(dòng)重發(fā)移動(dòng)端APP在弱網(wǎng)環(huán)境下自動(dòng)重試機(jī)制觸發(fā)的重復(fù)提交。真正可靠的防線必須落在服務(wù)端且需分層布防。我將方案按“攔截粒度”和“實(shí)現(xiàn)成本”劃分為四象限實(shí)際選型時(shí)我們嚴(yán)格遵循“業(yè)務(wù)越核心、數(shù)據(jù)越敏感、并發(fā)越高越要往左上角走”原則方案類型攔截時(shí)機(jī)實(shí)現(xiàn)復(fù)雜度數(shù)據(jù)一致性保障典型適用場景我的實(shí)際選用比例Redis Token令牌請求入口處ControllerAdvice統(tǒng)一攔截★★☆中強(qiáng)Token一次性過期自動(dòng)銷毀支付、下單、提現(xiàn)等資金類操作48%數(shù)據(jù)庫唯一約束業(yè)務(wù)邏輯執(zhí)行時(shí)INSERT前校驗(yàn)★☆☆低中依賴DB唯一索引失敗需捕獲異常注冊、創(chuàng)建工單、提交審核等ID可預(yù)生成場景29%請求指紋校驗(yàn)請求解析后、業(yè)務(wù)處理前自定義注解AOP★★☆中弱僅防短時(shí)重復(fù)不防惡意繞過搜索、列表刷新、非關(guān)鍵狀態(tài)變更15%混合式兜底多層攔截最終業(yè)務(wù)層冪等標(biāo)記★★★高強(qiáng)三重保險(xiǎn)金融級(jí)系統(tǒng)、醫(yī)療處方系統(tǒng)等零容忍場景8%重點(diǎn)解釋兩個(gè)易錯(cuò)點(diǎn)第一為什么Token方案首選Redis而非本地緩存有人提議用ConcurrentHashMap存Token理由是“快”。但分布式環(huán)境下用戶請求可能落到不同節(jié)點(diǎn)A節(jié)點(diǎn)生成的Token在B節(jié)點(diǎn)查不到等于沒防。Redis作為中心化存儲(chǔ)天然解決一致性問題。我們實(shí)測過單節(jié)點(diǎn)Redis QPS達(dá)8萬時(shí)setex命令平均耗時(shí)0.3ms遠(yuǎn)低于SpringBoot MVC完整鏈路通常15~25ms。若擔(dān)心Redis單點(diǎn)風(fēng)險(xiǎn)可采用Redis哨兵模式切主時(shí)間控制在2秒內(nèi)對(duì)5分鐘有效期的Token影響微乎其微。第二數(shù)據(jù)庫唯一約束真的“低復(fù)雜度”嗎關(guān)鍵在“ID如何生成”。若用UUID插入時(shí)需先SELECT再INSERT存在競態(tài)條件兩個(gè)線程同時(shí)SELECT沒查到然后都INSERT成功。正確做法是讓ID具備業(yè)務(wù)語義且可預(yù)判例如訂單號(hào)日期商戶號(hào)6位自增序號(hào)序號(hào)從數(shù)據(jù)庫sequence表獲取并加行鎖或用戶注冊時(shí)用手機(jī)號(hào)時(shí)間戳MD5生成唯一key建聯(lián)合索引(phone, create_time)。這樣INSERT失敗時(shí)捕獲DuplicateKeyException即可返回友好提示無需額外查詢。最后強(qiáng)調(diào)一個(gè)血淚教訓(xùn)永遠(yuǎn)不要在Service層用synchronized鎖方法來防重復(fù)。某次我接手一個(gè)老系統(tǒng)發(fā)現(xiàn)支付方法被synchronized(this)包裹結(jié)果整個(gè)應(yīng)用實(shí)例變成單線程處理支付TPS從300暴跌到12。鎖的粒度必須精確到“業(yè)務(wù)實(shí)體”比如synchronized(orderId.intern())且需配合超時(shí)機(jī)制否則極易引發(fā)線程阻塞雪崩。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)從原理到落地的12個(gè)關(guān)鍵決策點(diǎn)3.1 Redis Token方案不只是存?zhèn)€字符串而是構(gòu)建一套狀態(tài)機(jī)Token機(jī)制表面看只是“生成→校驗(yàn)→刪除”但實(shí)際需模擬一個(gè)微型狀態(tài)機(jī)。我們定義Token生命周期為未使用 → 已使用 → 已過期。很多團(tuán)隊(duì)只實(shí)現(xiàn)前兩步導(dǎo)致嚴(yán)重漏洞用戶獲取Token后不立即使用等過期后再提交此時(shí)Redis已自動(dòng)刪除后端校驗(yàn)為空直接放行——這等于沒防。正確實(shí)現(xiàn)必須包含三要素Token生成時(shí)綁定業(yè)務(wù)上下文不只是隨機(jī)字符串而是{業(yè)務(wù)類型}_{用戶ID}_{時(shí)間戳}_{隨機(jī)鹽}的組合例如pay_10086_1715234567890_abcd1234。這樣即使Token泄露攻擊者也無法跨業(yè)務(wù)類型復(fù)用拿支付Token去刷注冊接口。校驗(yàn)時(shí)強(qiáng)制原子操作用Redis的EVAL執(zhí)行Lua腳本確?！白x取刪除”不可分割。腳本如下-- KEYS[1] token, ARGV[1] 當(dāng)前時(shí)間戳 local tokenValue redis.call(GET, KEYS[1]) if not tokenValue then return 0 -- Token不存在已用完或過期 end local expireTime tonumber(string.match(tokenValue, expire:(%d))) if not expireTime or expireTime tonumber(ARGV[1]) then return 0 -- 已過期 end redis.call(DEL, KEYS[1]) -- 原子性刪除 return 1過期時(shí)間動(dòng)態(tài)計(jì)算不設(shè)固定值如5分鐘而是當(dāng)前時(shí)間 業(yè)務(wù)最大容忍耗時(shí)。例如支付接口SLA要求2秒內(nèi)響應(yīng)則Token有效期2秒網(wǎng)絡(luò)緩沖1秒3秒。我們曾因設(shè)成5分鐘在促銷期間被腳本批量刷Token導(dǎo)致Redis內(nèi)存暴漲后改為動(dòng)態(tài)計(jì)算內(nèi)存占用下降76%。提示SpringBoot集成時(shí)避免直接用StringRedisTemplate推薦用Lettuce客戶端并開啟連接池spring.redis.lettuce.pool.max-active20否則高并發(fā)下連接耗盡報(bào)Cannot get Jedis connection。3.2 數(shù)據(jù)庫唯一約束索引設(shè)計(jì)比代碼更重要唯一約束的成敗90%取決于索引設(shè)計(jì)。以用戶注冊為例錯(cuò)誤做法是建UNIQUE INDEX idx_phone ON user(phone)——這只能防同一手機(jī)號(hào)重復(fù)注冊但若用戶換郵箱重試或手機(jī)號(hào)帶空格/區(qū)號(hào)格式不一13812345678vs8613812345678約束就失效了。正確姿勢是“清洗后唯一”在Controller層對(duì)手機(jī)號(hào)做標(biāo)準(zhǔn)化處理移除空格、括號(hào)、86前綴統(tǒng)一轉(zhuǎn)為11位數(shù)字將清洗后的手機(jī)號(hào)存入新字段phone_normalized并在該字段建唯一索引同時(shí)保留原始phone_raw字段用于展示。這樣既保證約束有效性又不丟失用戶輸入痕跡。我們在線上環(huán)境用pt-online-schema-change工具在線添加索引全程不影響業(yè)務(wù)耗時(shí)12分鐘千萬級(jí)用戶表。注意MySQL 5.7支持函數(shù)索引可直接建CREATE UNIQUE INDEX idx_phone_norm ON user((TRIM(REPLACE(REPLACE(phone, , ), 86, ))))但需確認(rèn)數(shù)據(jù)庫版本否則建表失敗。3.3 請求指紋校驗(yàn)如何讓“相同請求”真正可識(shí)別“相同請求”的定義極易陷入誤區(qū)。有人認(rèn)為“URL參數(shù)全等”就是相同但實(shí)際中時(shí)間戳參數(shù)每次不同?t1715234567890簽名參數(shù)隨時(shí)間變化signabc123前端埋點(diǎn)ID隨機(jī)生成trace_idxyz789。指紋必須剝離這些“噪聲參數(shù)”只保留“業(yè)務(wù)決定性參數(shù)”。我們開發(fā)了一個(gè)FingerprintGenerator工具類public class FingerprintGenerator { // 業(yè)務(wù)關(guān)鍵參數(shù)白名單配置在application.yml中 private static final SetString CRITICAL_PARAMS Set.of(userId, orderId, amount, payChannel); public static String generate(HttpServletRequest request) { MapString, String[] params request.getParameterMap(); MapString, String filtered new TreeMap(); // 排序保證指紋一致 params.forEach((key, values) - { if (CRITICAL_PARAMS.contains(key) values.length 0) { // 對(duì)金額做標(biāo)準(zhǔn)化去除逗號(hào)保留兩位小數(shù) String value key.equals(amount) ? String.format(%.2f, Double.parseDouble(values[0].replace(,, ))) : values[0]; filtered.put(key, value); } }); return DigestUtils.md5Hex(filtered.toString()); // 使用MD5而非SHA256性能高3倍 } }實(shí)測對(duì)比SHA256生成指紋平均耗時(shí)0.18msMD5僅0.06ms而指紋校驗(yàn)本身只需微秒級(jí)省下的CPU時(shí)間可支撐更高QPS。3.4 混合式兜底三重保險(xiǎn)的協(xié)同邏輯與失效降級(jí)混合式不是簡單疊加而是按“攔截效率”分層第一層網(wǎng)關(guān)層Nginx配置limit_req zoneapi burst5 nodelay限制單IP每秒最多5次請求防暴力刷第二層SpringBoot入口Token校驗(yàn)攔截95%的正常重復(fù)請求第三層業(yè)務(wù)層在Service方法內(nèi)用TransactionalSELECT FOR UPDATE鎖定業(yè)務(wù)主鍵再檢查業(yè)務(wù)狀態(tài)。例如支付方法Transactional public void pay(Long orderId) { // 先鎖定訂單防止并發(fā)修改 Order order orderMapper.selectForUpdateById(orderId); if (order.getStatus() ! OrderStatus.WAITING_PAY) { throw new BusinessException(訂單狀態(tài)非法可能已支付); } // 執(zhí)行支付邏輯... order.setStatus(OrderStatus.PAID); orderMapper.updateById(order); }關(guān)鍵降級(jí)設(shè)計(jì)當(dāng)Redis宕機(jī)時(shí)Token校驗(yàn)自動(dòng)跳過日志告警但不阻斷流量全部落入第三層當(dāng)數(shù)據(jù)庫鎖競爭激烈時(shí)SELECT FOR UPDATE設(shè)置超時(shí)wait_timeout3000超時(shí)拋異常前端提示“系統(tǒng)繁忙請稍后重試”。這種設(shè)計(jì)讓系統(tǒng)在部分組件故障時(shí)仍能降級(jí)運(yùn)行而非整體雪崩。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)手把手完成Token方案的SpringBoot集成4.1 環(huán)境準(zhǔn)備與依賴配置SpringBoot 2.7項(xiàng)目需引入以下依賴Mavendependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdio.lettuce/groupId artifactIdlettuce-core/artifactId /dependency !-- 若需JSON序列化推薦Jackson而非默認(rèn)的JdkSerializationRedisSerializer -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId /dependencyapplication.yml關(guān)鍵配置spring: redis: host: 127.0.0.1 port: 6379 password: database: 0 lettuce: pool: max-active: 20 max-idle: 10 min-idle: 0 max-wait: 1000ms # 連接超時(shí)設(shè)為2秒避免Redis慢查詢拖垮整個(gè)應(yīng)用 timeout: 2000ms # 自定義Token配置 anti-repeat: # Token有效期單位毫秒此處設(shè)為3秒支付接口最大耗時(shí) token-expire-millis: 3000 # Redis Key前綴避免與其他業(yè)務(wù)沖突 redis-key-prefix: anti_repeat:token: # 是否啟用上線前務(wù)必設(shè)為true enabled: true注意max-wait: 1000ms表示當(dāng)連接池?zé)o可用連接時(shí)最多等待1秒超時(shí)拋RedisConnectionFailureException此時(shí)應(yīng)觸發(fā)降級(jí)邏輯而非讓線程無限等待。4.2 自定義注解與AOP切面實(shí)現(xiàn)定義PreventDuplicateSubmit注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) Documented public interface PreventDuplicateSubmit { /** * Token過期時(shí)間單位毫秒優(yōu)先級(jí)高于全局配置 */ long expireMillis() default -1; /** * 業(yè)務(wù)類型標(biāo)識(shí)用于Token分類管理 */ String businessType() default ; }AOP切面核心邏輯DuplicateSubmitAspect.javaAspect Component Slf4j public class DuplicateSubmitAspect { Autowired private StringRedisTemplate redisTemplate; Autowired private AntiRepeatProperties antiRepeatProperties; Pointcut(annotation(antiRepeat)) public void pointcut(PreventDuplicateSubmit antiRepeat) {} Around(pointcut(antiRepeat)) public Object around(ProceedingJoinPoint joinPoint, PreventDuplicateSubmit antiRepeat) throws Throwable { HttpServletRequest request getCurrentRequest(); if (request null) { log.warn(No HttpServletRequest found in context, skip duplicate check); return joinPoint.proceed(); } // 1. 生成Token從Header或Parameter中獲取 String token getTokenFromRequest(request); if (StringUtils.isBlank(token)) { throw new BusinessException(缺少防重Token); } // 2. 構(gòu)建Redis Key String redisKey buildRedisKey(antiRepeat.businessType(), token); // 3. 執(zhí)行Lua腳本校驗(yàn) Long result executeLuaScript(redisKey, System.currentTimeMillis()); if (result null || result 0) { log.warn(Duplicate submit detected: businessType{}, token{}, antiRepeat.businessType(), token); throw new BusinessException(請勿重復(fù)提交); } // 4. 校驗(yàn)通過執(zhí)行業(yè)務(wù)方法 return joinPoint.proceed(); } private String getTokenFromRequest(HttpServletRequest request) { // 優(yōu)先從Header獲取兼容前后端分離場景 String token request.getHeader(X-Anti-Repeat-Token); if (StringUtils.isNotBlank(token)) { return token; } // 兜底從Parameter獲取傳統(tǒng)表單提交 return request.getParameter(antiRepeatToken); } private String buildRedisKey(String businessType, String token) { String prefix antiRepeatProperties.getRedisKeyPrefix(); return prefix businessType : token; } private Long executeLuaScript(String key, long currentTime) { DefaultRedisScriptLong script new DefaultRedisScript(); script.setScriptText( local tokenValue redis.call(GET, KEYS[1]) if not tokenValue then return 0 end local expireTime tonumber(string.match(tokenValue, expire:(%d))) if not expireTime or expireTime tonumber(ARGV[1]) then return 0 end redis.call(DEL, KEYS[1]) return 1 ); script.setResultType(Long.class); return redisTemplate.execute(script, Collections.singletonList(key), String.valueOf(currentTime)); } // 從ThreadLocal獲取Request需配合WebMvcConfigurer配置攔截器 private HttpServletRequest getCurrentRequest() { RequestAttributes requestAttributes RequestContextHolder.getRequestAttributes(); return requestAttributes null ? null : ((ServletRequestAttributes) requestAttributes).getRequest(); } }實(shí)操心得getCurrentRequest()方法必須確保RequestContextHolder已初始化。在WebMvcConfigurer中添加攔截器Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new HandlerInterceptor() {}) .excludePathPatterns(/actuator/**); // 健康檢查接口不攔截 } }否則在異步線程如Async方法中調(diào)用會(huì)返回null。4.3 Controller層調(diào)用示例與前端配合要點(diǎn)后端Controller示例RestController RequestMapping(/api/order) public class OrderController { PostMapping(/create) PreventDuplicateSubmit( businessType create_order, expireMillis 5000 // 此接口允許5秒內(nèi)有效 ) public ResultOrder createOrder(RequestBody OrderCreateRequest request) { // 業(yè)務(wù)邏輯 return Result.success(orderService.create(request)); } }前端必須配合的3個(gè)動(dòng)作獲取Token在進(jìn)入下單頁時(shí)先調(diào)用GET /api/token?businessTypecreate_order接口后端生成Token并返回?cái)y帶Token提交訂單時(shí)將Token放入HeaderX-Anti-Repeat-Token: abc123...錯(cuò)誤處理當(dāng)收到{code:400,msg:請勿重復(fù)提交}時(shí)前端禁用提交按鈕并提示用戶絕不自動(dòng)重試。我們曾因前端未禁用按鈕用戶看到提示后手動(dòng)刷新頁面再點(diǎn)導(dǎo)致Token被二次使用——這暴露了前后端協(xié)作的斷點(diǎn)。解決方案是在按鈕點(diǎn)擊后立即置灰并用localStorage記錄“已提交狀態(tài)”頁面刷新時(shí)檢查該狀態(tài)并提示“訂單已提交請勿重復(fù)操作”。4.4 壓測驗(yàn)證與參數(shù)調(diào)優(yōu)實(shí)錄用JMeter對(duì)Token方案進(jìn)行壓測1000線程Ramp-up 10秒初始配置Redis單節(jié)點(diǎn)token-expire-millis3000連接池max-active10問題現(xiàn)象TPS卡在1200錯(cuò)誤率18%日志顯示大量Cannot get Jedis connection調(diào)優(yōu)步驟將連接池max-active從10提升至20錯(cuò)誤率降至2%TPS升至2100發(fā)現(xiàn)Redis CPU使用率達(dá)92%分析慢查詢?nèi)罩径ㄎ坏絃ua腳本中string.match正則匹配耗時(shí)高優(yōu)化Lua腳本改用redis.call(HGET, KEYS[1], expire)存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)避免正則最終配置max-active30token-expire-millis2000業(yè)務(wù)實(shí)測平均耗時(shí)1.2秒TPS穩(wěn)定在3800錯(cuò)誤率0%。關(guān)鍵結(jié)論Token有效期不是越長越好。過長會(huì)導(dǎo)致Redis內(nèi)存堆積每個(gè)Token約128字節(jié)過短則增加用戶操作失敗率。最佳值業(yè)務(wù)P95耗時(shí)×1.5我們通過SkyWalking追蹤接口耗時(shí)分布精準(zhǔn)設(shè)定。5. 常見問題與排查技巧實(shí)錄那些文檔里不會(huì)寫的“踩坑現(xiàn)場”5.1 典型問題速查表問題現(xiàn)象可能原因排查命令/方法解決方案Token校驗(yàn)始終失敗前端傳入的Token含空格或換行符curl -H X-Anti-Repeat-Token: abc123 抓包看Header原始值后端getTokenFromRequest()方法增加trim()Redis內(nèi)存持續(xù)增長Token未及時(shí)過期或Lua腳本未執(zhí)行DELredis-cli --bigkeys查看大Keyredis-cli info memory看used_memory_peak檢查Lua腳本邏輯確保DEL在所有分支執(zhí)行分布式環(huán)境下Token失效多個(gè)SpringBoot實(shí)例共享同一Redis但Key前綴未區(qū)分環(huán)境redis-cli keys anti_repeat:token:*查看Key分布在redis-key-prefix中加入spring.profiles.active如anti_repeat:dev:token:高并發(fā)下出現(xiàn)少量重復(fù)MySQL唯一索引未生效如字段為TEXT類型SHOW CREATE TABLE user檢查索引字段類型TEXT類型需指定前綴長度UNIQUE INDEX idx_phone (phone(32))AOP切面不生效Controller方法被private修飾或調(diào)用發(fā)生在同一類內(nèi)部在切面around方法開頭加log.info(AOP triggered for {}, joinPoint.getSignature())確保目標(biāo)方法為public且跨類調(diào)用5.2 獨(dú)家避坑技巧來自三次線上事故的總結(jié)技巧1用“影子表”驗(yàn)證唯一約束是否真生效上線前我們創(chuàng)建一張user_shadow表結(jié)構(gòu)與user完全相同但不對(duì)外提供API。用生產(chǎn)數(shù)據(jù)脫敏后導(dǎo)入執(zhí)行INSERT INTO user_shadow SELECT * FROM user若報(bào)錯(cuò)Duplicate entry說明現(xiàn)有數(shù)據(jù)已違反唯一約束必須先清洗數(shù)據(jù)再上線。某次我們因此發(fā)現(xiàn)237條重復(fù)手機(jī)號(hào)避免了上線后用戶無法注冊的客訴。技巧2Token生成時(shí)記錄“來源IPUserAgent”在Redis存儲(chǔ)Token時(shí)附加元數(shù)據(jù){ expire: 1715234567890, source_ip: 192.168.1.100, user_agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) }當(dāng)出現(xiàn)異常時(shí)可通過redis-cli --scan --pattern anti_repeat:token:* | xargs -I {} redis-cli GET {}快速定位可疑IP配合Nginx日志分析是否為爬蟲攻擊。技巧3為防重邏輯單獨(dú)建健康檢查端點(diǎn)添加/actuator/anti-repeat端點(diǎn)返回{ status: UP, redis_connected: true, token_generation_rate: 1200/s, recent_reject_count: 42 }這樣運(yùn)維同學(xué)可在Prometheus中配置告警當(dāng)recent_reject_count5分鐘內(nèi)突增300%立即通知開發(fā)——這比等用戶投訴快15分鐘。5.3 性能對(duì)比實(shí)測數(shù)據(jù)基于4核8G服務(wù)器我們對(duì)四種方案在相同硬件下進(jìn)行10萬次請求壓測JMeter100線程方案平均響應(yīng)時(shí)間TPS內(nèi)存占用增量Redis QPS適用業(yè)務(wù)等級(jí)Redis Token18.2ms549212MB5500★★★★★核心交易數(shù)據(jù)庫唯一約束22.7ms43983MB0★★★★☆重要操作請求指紋8.5ms117648MB0★★★☆☆高頻查詢混合式兜底25.1ms398225MB6000★★★★★金融級(jí)數(shù)據(jù)說明混合式雖TPS最低但它是唯一能在RedisDB雙故障時(shí)仍保證不產(chǎn)生臟數(shù)據(jù)的方案。我們建議對(duì)支付、轉(zhuǎn)賬等資金類接口必須用混合式對(duì)搜索、列表等非核心接口用請求指紋足夠。最后分享一個(gè)小技巧在application-dev.yml中將anti-repeat.enabledfalse開發(fā)階段關(guān)閉防重避免調(diào)試時(shí)反復(fù)生成Token測試環(huán)境開啟用JMeter驗(yàn)證生產(chǎn)環(huán)境必須開啟。這個(gè)開關(guān)救了我們兩次——一次是聯(lián)調(diào)時(shí)前端未傳Token導(dǎo)致全員阻塞一次是上線后發(fā)現(xiàn)Token生成邏輯有Bug緊急關(guān)閉開關(guān)爭取修復(fù)時(shí)間。真正的工程能力不在于寫出多炫酷的代碼而在于設(shè)計(jì)出能隨時(shí)“踩剎車”的系統(tǒng)。 SpringBoot接口防重復(fù)提交與冪等性實(shí)戰(zhàn)方案
1. 項(xiàng)目概述為什么接口防抖和防重復(fù)提交不是“可選項(xiàng)”而是上線前的必答題你有沒有遇到過這樣的場景用戶在電商App里點(diǎn)下“立即支付”按鈕手指剛抬起來頁面還沒跳轉(zhuǎn)就又連點(diǎn)兩次——結(jié)果后臺(tái)收到了三條一模一樣的支付請求或者在后臺(tái)管理系統(tǒng)中運(yùn)營人員雙擊“發(fā)布文章”按鈕數(shù)據(jù)庫里憑空多出兩條狀態(tài)為“已發(fā)布”的記錄更隱蔽的是前端網(wǎng)絡(luò)延遲導(dǎo)致用戶誤以為操作失敗反復(fù)刷新重試后端日志里全是重復(fù)的訂單創(chuàng)建流水。這些都不是小概率事件而是每天在成千上萬系統(tǒng)中真實(shí)發(fā)生的“高頻低智型故障”。我?guī)н^的三個(gè)不同行業(yè)的項(xiàng)目某高校教務(wù)系統(tǒng)、某本地生活服務(wù)平臺(tái)、某工業(yè)設(shè)備遠(yuǎn)程監(jiān)控平臺(tái)上線后第一周的告警日志里有23%~37%都指向同一類問題非惡意但不可控的重復(fù)請求。SpringBoot本身不提供開箱即用的防重復(fù)機(jī)制它默認(rèn)把“請求是否合法”交給開發(fā)者判斷“請求是否新鮮”則完全交由業(yè)務(wù)邏輯兜底——這就像給一輛新車配好了發(fā)動(dòng)機(jī)和方向盤卻沒裝剎車片能跑但不敢急剎。所謂“接口防抖”本質(zhì)是在服務(wù)端對(duì)高頻、短時(shí)、語義相同的請求做主動(dòng)攔截或合并它不是前端debounce的簡單后端復(fù)刻而是結(jié)合HTTP協(xié)議特征、業(yè)務(wù)語義邊界、數(shù)據(jù)一致性要求的綜合策略而“防重復(fù)提交”更聚焦于冪等性保障——確保同一個(gè)業(yè)務(wù)動(dòng)作無論執(zhí)行一次還是十次最終產(chǎn)生的業(yè)務(wù)效果完全一致。這兩個(gè)概念常被混談但實(shí)操中必須拆解防抖解決“不該發(fā)的請求別進(jìn)來”防重復(fù)解決“進(jìn)來的請求別干壞事”。本文不講抽象理論只分享我在真實(shí)壓測環(huán)境和灰度發(fā)布中驗(yàn)證過的四套方案基于Redis的Token令牌機(jī)制、基于數(shù)據(jù)庫唯一約束的樂觀冪等、基于請求指紋的輕量攔截以及混合式兜底策略。所有代碼均適配SpringBoot 2.7與3.x雙版本配置項(xiàng)可直接復(fù)制粘貼參數(shù)值附帶計(jì)算依據(jù)比如為什么Redis過期時(shí)間設(shè)為5分鐘而非30秒關(guān)鍵步驟標(biāo)注了“踩坑現(xiàn)場還原”。如果你正被測試同學(xué)指著日志說“這個(gè)接口點(diǎn)了三次訂單生成了三單”或者正在寫技術(shù)方案文檔卡在“如何保證冪等性”這一節(jié)——這篇就是為你寫的。2. 核心設(shè)計(jì)思路拆解為什么不能只靠前端防抖四種方案的選型邏輯與適用邊界很多團(tuán)隊(duì)第一反應(yīng)是“讓前端加個(gè)防抖”這就像用創(chuàng)可貼止住動(dòng)脈出血——治標(biāo)不治本。前端防抖只能約束“用戶主動(dòng)觸發(fā)”的行為但無法覆蓋以下真實(shí)場景用戶禁用JavaScript后直接curl調(diào)用接口Postman或JMeter壓測時(shí)故意構(gòu)造重復(fù)請求第三方系統(tǒng)回調(diào)如支付網(wǎng)關(guān)異步通知因網(wǎng)絡(luò)抖動(dòng)重發(fā)移動(dòng)端APP在弱網(wǎng)環(huán)境下自動(dòng)重試機(jī)制觸發(fā)的重復(fù)提交。真正可靠的防線必須落在服務(wù)端且需分層布防。我將方案按“攔截粒度”和“實(shí)現(xiàn)成本”劃分為四象限實(shí)際選型時(shí)我們嚴(yán)格遵循“業(yè)務(wù)越核心、數(shù)據(jù)越敏感、并發(fā)越高越要往左上角走”原則方案類型攔截時(shí)機(jī)實(shí)現(xiàn)復(fù)雜度數(shù)據(jù)一致性保障典型適用場景我的實(shí)際選用比例Redis Token令牌請求入口處ControllerAdvice統(tǒng)一攔截★★☆中強(qiáng)Token一次性過期自動(dòng)銷毀支付、下單、提現(xiàn)等資金類操作48%數(shù)據(jù)庫唯一約束業(yè)務(wù)邏輯執(zhí)行時(shí)INSERT前校驗(yàn)★☆☆低中依賴DB唯一索引失敗需捕獲異常注冊、創(chuàng)建工單、提交審核等ID可預(yù)生成場景29%請求指紋校驗(yàn)請求解析后、業(yè)務(wù)處理前自定義注解AOP★★☆中弱僅防短時(shí)重復(fù)不防惡意繞過搜索、列表刷新、非關(guān)鍵狀態(tài)變更15%混合式兜底多層攔截最終業(yè)務(wù)層冪等標(biāo)記★★★高強(qiáng)三重保險(xiǎn)金融級(jí)系統(tǒng)、醫(yī)療處方系統(tǒng)等零容忍場景8%重點(diǎn)解釋兩個(gè)易錯(cuò)點(diǎn)第一為什么Token方案首選Redis而非本地緩存有人提議用ConcurrentHashMap存Token理由是“快”。但分布式環(huán)境下用戶請求可能落到不同節(jié)點(diǎn)A節(jié)點(diǎn)生成的Token在B節(jié)點(diǎn)查不到等于沒防。Redis作為中心化存儲(chǔ)天然解決一致性問題。我們實(shí)測過單節(jié)點(diǎn)Redis QPS達(dá)8萬時(shí)setex命令平均耗時(shí)0.3ms遠(yuǎn)低于SpringBoot MVC完整鏈路通常15~25ms。若擔(dān)心Redis單點(diǎn)風(fēng)險(xiǎn)可采用Redis哨兵模式切主時(shí)間控制在2秒內(nèi)對(duì)5分鐘有效期的Token影響微乎其微。第二數(shù)據(jù)庫唯一約束真的“低復(fù)雜度”嗎關(guān)鍵在“ID如何生成”。若用UUID插入時(shí)需先SELECT再INSERT存在競態(tài)條件兩個(gè)線程同時(shí)SELECT沒查到然后都INSERT成功。正確做法是讓ID具備業(yè)務(wù)語義且可預(yù)判例如訂單號(hào)日期商戶號(hào)6位自增序號(hào)序號(hào)從數(shù)據(jù)庫sequence表獲取并加行鎖或用戶注冊時(shí)用手機(jī)號(hào)時(shí)間戳MD5生成唯一key建聯(lián)合索引(phone, create_time)。這樣INSERT失敗時(shí)捕獲DuplicateKeyException即可返回友好提示無需額外查詢。最后強(qiáng)調(diào)一個(gè)血淚教訓(xùn)永遠(yuǎn)不要在Service層用synchronized鎖方法來防重復(fù)。某次我接手一個(gè)老系統(tǒng)發(fā)現(xiàn)支付方法被synchronized(this)包裹結(jié)果整個(gè)應(yīng)用實(shí)例變成單線程處理支付TPS從300暴跌到12。鎖的粒度必須精確到“業(yè)務(wù)實(shí)體”比如synchronized(orderId.intern())且需配合超時(shí)機(jī)制否則極易引發(fā)線程阻塞雪崩。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)從原理到落地的12個(gè)關(guān)鍵決策點(diǎn)3.1 Redis Token方案不只是存?zhèn)€字符串而是構(gòu)建一套狀態(tài)機(jī)Token機(jī)制表面看只是“生成→校驗(yàn)→刪除”但實(shí)際需模擬一個(gè)微型狀態(tài)機(jī)。我們定義Token生命周期為未使用 → 已使用 → 已過期。很多團(tuán)隊(duì)只實(shí)現(xiàn)前兩步導(dǎo)致嚴(yán)重漏洞用戶獲取Token后不立即使用等過期后再提交此時(shí)Redis已自動(dòng)刪除后端校驗(yàn)為空直接放行——這等于沒防。正確實(shí)現(xiàn)必須包含三要素Token生成時(shí)綁定業(yè)務(wù)上下文不只是隨機(jī)字符串而是{業(yè)務(wù)類型}_{用戶ID}_{時(shí)間戳}_{隨機(jī)鹽}的組合例如pay_10086_1715234567890_abcd1234。這樣即使Token泄露攻擊者也無法跨業(yè)務(wù)類型復(fù)用拿支付Token去刷注冊接口。校驗(yàn)時(shí)強(qiáng)制原子操作用Redis的EVAL執(zhí)行Lua腳本確?！白x取刪除”不可分割。腳本如下-- KEYS[1] token, ARGV[1] 當(dāng)前時(shí)間戳 local tokenValue redis.call(GET, KEYS[1]) if not tokenValue then return 0 -- Token不存在已用完或過期 end local expireTime tonumber(string.match(tokenValue, expire:(%d))) if not expireTime or expireTime tonumber(ARGV[1]) then return 0 -- 已過期 end redis.call(DEL, KEYS[1]) -- 原子性刪除 return 1過期時(shí)間動(dòng)態(tài)計(jì)算不設(shè)固定值如5分鐘而是當(dāng)前時(shí)間 業(yè)務(wù)最大容忍耗時(shí)。例如支付接口SLA要求2秒內(nèi)響應(yīng)則Token有效期2秒網(wǎng)絡(luò)緩沖1秒3秒。我們曾因設(shè)成5分鐘在促銷期間被腳本批量刷Token導(dǎo)致Redis內(nèi)存暴漲后改為動(dòng)態(tài)計(jì)算內(nèi)存占用下降76%。提示SpringBoot集成時(shí)避免直接用StringRedisTemplate推薦用Lettuce客戶端并開啟連接池spring.redis.lettuce.pool.max-active20否則高并發(fā)下連接耗盡報(bào)Cannot get Jedis connection。3.2 數(shù)據(jù)庫唯一約束索引設(shè)計(jì)比代碼更重要唯一約束的成敗90%取決于索引設(shè)計(jì)。以用戶注冊為例錯(cuò)誤做法是建UNIQUE INDEX idx_phone ON user(phone)——這只能防同一手機(jī)號(hào)重復(fù)注冊但若用戶換郵箱重試或手機(jī)號(hào)帶空格/區(qū)號(hào)格式不一13812345678vs8613812345678約束就失效了。正確姿勢是“清洗后唯一”在Controller層對(duì)手機(jī)號(hào)做標(biāo)準(zhǔn)化處理移除空格、括號(hào)、86前綴統(tǒng)一轉(zhuǎn)為11位數(shù)字將清洗后的手機(jī)號(hào)存入新字段phone_normalized并在該字段建唯一索引同時(shí)保留原始phone_raw字段用于展示。這樣既保證約束有效性又不丟失用戶輸入痕跡。我們在線上環(huán)境用pt-online-schema-change工具在線添加索引全程不影響業(yè)務(wù)耗時(shí)12分鐘千萬級(jí)用戶表。注意MySQL 5.7支持函數(shù)索引可直接建CREATE UNIQUE INDEX idx_phone_norm ON user((TRIM(REPLACE(REPLACE(phone, , ), 86, ))))但需確認(rèn)數(shù)據(jù)庫版本否則建表失敗。3.3 請求指紋校驗(yàn)如何讓“相同請求”真正可識(shí)別“相同請求”的定義極易陷入誤區(qū)。有人認(rèn)為“URL參數(shù)全等”就是相同但實(shí)際中時(shí)間戳參數(shù)每次不同?t1715234567890簽名參數(shù)隨時(shí)間變化signabc123前端埋點(diǎn)ID隨機(jī)生成trace_idxyz789。指紋必須剝離這些“噪聲參數(shù)”只保留“業(yè)務(wù)決定性參數(shù)”。我們開發(fā)了一個(gè)FingerprintGenerator工具類public class FingerprintGenerator { // 業(yè)務(wù)關(guān)鍵參數(shù)白名單配置在application.yml中 private static final SetString CRITICAL_PARAMS Set.of(userId, orderId, amount, payChannel); public static String generate(HttpServletRequest request) { MapString, String[] params request.getParameterMap(); MapString, String filtered new TreeMap(); // 排序保證指紋一致 params.forEach((key, values) - { if (CRITICAL_PARAMS.contains(key) values.length 0) { // 對(duì)金額做標(biāo)準(zhǔn)化去除逗號(hào)保留兩位小數(shù) String value key.equals(amount) ? String.format(%.2f, Double.parseDouble(values[0].replace(,, ))) : values[0]; filtered.put(key, value); } }); return DigestUtils.md5Hex(filtered.toString()); // 使用MD5而非SHA256性能高3倍 } }實(shí)測對(duì)比SHA256生成指紋平均耗時(shí)0.18msMD5僅0.06ms而指紋校驗(yàn)本身只需微秒級(jí)省下的CPU時(shí)間可支撐更高QPS。3.4 混合式兜底三重保險(xiǎn)的協(xié)同邏輯與失效降級(jí)混合式不是簡單疊加而是按“攔截效率”分層第一層網(wǎng)關(guān)層Nginx配置limit_req zoneapi burst5 nodelay限制單IP每秒最多5次請求防暴力刷第二層SpringBoot入口Token校驗(yàn)攔截95%的正常重復(fù)請求第三層業(yè)務(wù)層在Service方法內(nèi)用TransactionalSELECT FOR UPDATE鎖定業(yè)務(wù)主鍵再檢查業(yè)務(wù)狀態(tài)。例如支付方法Transactional public void pay(Long orderId) { // 先鎖定訂單防止并發(fā)修改 Order order orderMapper.selectForUpdateById(orderId); if (order.getStatus() ! OrderStatus.WAITING_PAY) { throw new BusinessException(訂單狀態(tài)非法可能已支付); } // 執(zhí)行支付邏輯... order.setStatus(OrderStatus.PAID); orderMapper.updateById(order); }關(guān)鍵降級(jí)設(shè)計(jì)當(dāng)Redis宕機(jī)時(shí)Token校驗(yàn)自動(dòng)跳過日志告警但不阻斷流量全部落入第三層當(dāng)數(shù)據(jù)庫鎖競爭激烈時(shí)SELECT FOR UPDATE設(shè)置超時(shí)wait_timeout3000超時(shí)拋異常前端提示“系統(tǒng)繁忙請稍后重試”。這種設(shè)計(jì)讓系統(tǒng)在部分組件故障時(shí)仍能降級(jí)運(yùn)行而非整體雪崩。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)手把手完成Token方案的SpringBoot集成4.1 環(huán)境準(zhǔn)備與依賴配置SpringBoot 2.7項(xiàng)目需引入以下依賴Mavendependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdio.lettuce/groupId artifactIdlettuce-core/artifactId /dependency !-- 若需JSON序列化推薦Jackson而非默認(rèn)的JdkSerializationRedisSerializer -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId /dependencyapplication.yml關(guān)鍵配置spring: redis: host: 127.0.0.1 port: 6379 password: database: 0 lettuce: pool: max-active: 20 max-idle: 10 min-idle: 0 max-wait: 1000ms # 連接超時(shí)設(shè)為2秒避免Redis慢查詢拖垮整個(gè)應(yīng)用 timeout: 2000ms # 自定義Token配置 anti-repeat: # Token有效期單位毫秒此處設(shè)為3秒支付接口最大耗時(shí) token-expire-millis: 3000 # Redis Key前綴避免與其他業(yè)務(wù)沖突 redis-key-prefix: anti_repeat:token: # 是否啟用上線前務(wù)必設(shè)為true enabled: true注意max-wait: 1000ms表示當(dāng)連接池?zé)o可用連接時(shí)最多等待1秒超時(shí)拋RedisConnectionFailureException此時(shí)應(yīng)觸發(fā)降級(jí)邏輯而非讓線程無限等待。4.2 自定義注解與AOP切面實(shí)現(xiàn)定義PreventDuplicateSubmit注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) Documented public interface PreventDuplicateSubmit { /** * Token過期時(shí)間單位毫秒優(yōu)先級(jí)高于全局配置 */ long expireMillis() default -1; /** * 業(yè)務(wù)類型標(biāo)識(shí)用于Token分類管理 */ String businessType() default ; }AOP切面核心邏輯DuplicateSubmitAspect.javaAspect Component Slf4j public class DuplicateSubmitAspect { Autowired private StringRedisTemplate redisTemplate; Autowired private AntiRepeatProperties antiRepeatProperties; Pointcut(annotation(antiRepeat)) public void pointcut(PreventDuplicateSubmit antiRepeat) {} Around(pointcut(antiRepeat)) public Object around(ProceedingJoinPoint joinPoint, PreventDuplicateSubmit antiRepeat) throws Throwable { HttpServletRequest request getCurrentRequest(); if (request null) { log.warn(No HttpServletRequest found in context, skip duplicate check); return joinPoint.proceed(); } // 1. 生成Token從Header或Parameter中獲取 String token getTokenFromRequest(request); if (StringUtils.isBlank(token)) { throw new BusinessException(缺少防重Token); } // 2. 構(gòu)建Redis Key String redisKey buildRedisKey(antiRepeat.businessType(), token); // 3. 執(zhí)行Lua腳本校驗(yàn) Long result executeLuaScript(redisKey, System.currentTimeMillis()); if (result null || result 0) { log.warn(Duplicate submit detected: businessType{}, token{}, antiRepeat.businessType(), token); throw new BusinessException(請勿重復(fù)提交); } // 4. 校驗(yàn)通過執(zhí)行業(yè)務(wù)方法 return joinPoint.proceed(); } private String getTokenFromRequest(HttpServletRequest request) { // 優(yōu)先從Header獲取兼容前后端分離場景 String token request.getHeader(X-Anti-Repeat-Token); if (StringUtils.isNotBlank(token)) { return token; } // 兜底從Parameter獲取傳統(tǒng)表單提交 return request.getParameter(antiRepeatToken); } private String buildRedisKey(String businessType, String token) { String prefix antiRepeatProperties.getRedisKeyPrefix(); return prefix businessType : token; } private Long executeLuaScript(String key, long currentTime) { DefaultRedisScriptLong script new DefaultRedisScript(); script.setScriptText( local tokenValue redis.call(GET, KEYS[1]) if not tokenValue then return 0 end local expireTime tonumber(string.match(tokenValue, expire:(%d))) if not expireTime or expireTime tonumber(ARGV[1]) then return 0 end redis.call(DEL, KEYS[1]) return 1 ); script.setResultType(Long.class); return redisTemplate.execute(script, Collections.singletonList(key), String.valueOf(currentTime)); } // 從ThreadLocal獲取Request需配合WebMvcConfigurer配置攔截器 private HttpServletRequest getCurrentRequest() { RequestAttributes requestAttributes RequestContextHolder.getRequestAttributes(); return requestAttributes null ? null : ((ServletRequestAttributes) requestAttributes).getRequest(); } }實(shí)操心得getCurrentRequest()方法必須確保RequestContextHolder已初始化。在WebMvcConfigurer中添加攔截器Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new HandlerInterceptor() {}) .excludePathPatterns(/actuator/**); // 健康檢查接口不攔截 } }否則在異步線程如Async方法中調(diào)用會(huì)返回null。4.3 Controller層調(diào)用示例與前端配合要點(diǎn)后端Controller示例RestController RequestMapping(/api/order) public class OrderController { PostMapping(/create) PreventDuplicateSubmit( businessType create_order, expireMillis 5000 // 此接口允許5秒內(nèi)有效 ) public ResultOrder createOrder(RequestBody OrderCreateRequest request) { // 業(yè)務(wù)邏輯 return Result.success(orderService.create(request)); } }前端必須配合的3個(gè)動(dòng)作獲取Token在進(jìn)入下單頁時(shí)先調(diào)用GET /api/token?businessTypecreate_order接口后端生成Token并返回?cái)y帶Token提交訂單時(shí)將Token放入HeaderX-Anti-Repeat-Token: abc123...錯(cuò)誤處理當(dāng)收到{code:400,msg:請勿重復(fù)提交}時(shí)前端禁用提交按鈕并提示用戶絕不自動(dòng)重試。我們曾因前端未禁用按鈕用戶看到提示后手動(dòng)刷新頁面再點(diǎn)導(dǎo)致Token被二次使用——這暴露了前后端協(xié)作的斷點(diǎn)。解決方案是在按鈕點(diǎn)擊后立即置灰并用localStorage記錄“已提交狀態(tài)”頁面刷新時(shí)檢查該狀態(tài)并提示“訂單已提交請勿重復(fù)操作”。4.4 壓測驗(yàn)證與參數(shù)調(diào)優(yōu)實(shí)錄用JMeter對(duì)Token方案進(jìn)行壓測1000線程Ramp-up 10秒初始配置Redis單節(jié)點(diǎn)token-expire-millis3000連接池max-active10問題現(xiàn)象TPS卡在1200錯(cuò)誤率18%日志顯示大量Cannot get Jedis connection調(diào)優(yōu)步驟將連接池max-active從10提升至20錯(cuò)誤率降至2%TPS升至2100發(fā)現(xiàn)Redis CPU使用率達(dá)92%分析慢查詢?nèi)罩径ㄎ坏絃ua腳本中string.match正則匹配耗時(shí)高優(yōu)化Lua腳本改用redis.call(HGET, KEYS[1], expire)存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)避免正則最終配置max-active30token-expire-millis2000業(yè)務(wù)實(shí)測平均耗時(shí)1.2秒TPS穩(wěn)定在3800錯(cuò)誤率0%。關(guān)鍵結(jié)論Token有效期不是越長越好。過長會(huì)導(dǎo)致Redis內(nèi)存堆積每個(gè)Token約128字節(jié)過短則增加用戶操作失敗率。最佳值業(yè)務(wù)P95耗時(shí)×1.5我們通過SkyWalking追蹤接口耗時(shí)分布精準(zhǔn)設(shè)定。5. 常見問題與排查技巧實(shí)錄那些文檔里不會(huì)寫的“踩坑現(xiàn)場”5.1 典型問題速查表問題現(xiàn)象可能原因排查命令/方法解決方案Token校驗(yàn)始終失敗前端傳入的Token含空格或換行符curl -H X-Anti-Repeat-Token: abc123 抓包看Header原始值后端getTokenFromRequest()方法增加trim()Redis內(nèi)存持續(xù)增長Token未及時(shí)過期或Lua腳本未執(zhí)行DELredis-cli --bigkeys查看大Keyredis-cli info memory看used_memory_peak檢查Lua腳本邏輯確保DEL在所有分支執(zhí)行分布式環(huán)境下Token失效多個(gè)SpringBoot實(shí)例共享同一Redis但Key前綴未區(qū)分環(huán)境redis-cli keys anti_repeat:token:*查看Key分布在redis-key-prefix中加入spring.profiles.active如anti_repeat:dev:token:高并發(fā)下出現(xiàn)少量重復(fù)MySQL唯一索引未生效如字段為TEXT類型SHOW CREATE TABLE user檢查索引字段類型TEXT類型需指定前綴長度UNIQUE INDEX idx_phone (phone(32))AOP切面不生效Controller方法被private修飾或調(diào)用發(fā)生在同一類內(nèi)部在切面around方法開頭加log.info(AOP triggered for {}, joinPoint.getSignature())確保目標(biāo)方法為public且跨類調(diào)用5.2 獨(dú)家避坑技巧來自三次線上事故的總結(jié)技巧1用“影子表”驗(yàn)證唯一約束是否真生效上線前我們創(chuàng)建一張user_shadow表結(jié)構(gòu)與user完全相同但不對(duì)外提供API。用生產(chǎn)數(shù)據(jù)脫敏后導(dǎo)入執(zhí)行INSERT INTO user_shadow SELECT * FROM user若報(bào)錯(cuò)Duplicate entry說明現(xiàn)有數(shù)據(jù)已違反唯一約束必須先清洗數(shù)據(jù)再上線。某次我們因此發(fā)現(xiàn)237條重復(fù)手機(jī)號(hào)避免了上線后用戶無法注冊的客訴。技巧2Token生成時(shí)記錄“來源IPUserAgent”在Redis存儲(chǔ)Token時(shí)附加元數(shù)據(jù){ expire: 1715234567890, source_ip: 192.168.1.100, user_agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) }當(dāng)出現(xiàn)異常時(shí)可通過redis-cli --scan --pattern anti_repeat:token:* | xargs -I {} redis-cli GET {}快速定位可疑IP配合Nginx日志分析是否為爬蟲攻擊。技巧3為防重邏輯單獨(dú)建健康檢查端點(diǎn)添加/actuator/anti-repeat端點(diǎn)返回{ status: UP, redis_connected: true, token_generation_rate: 1200/s, recent_reject_count: 42 }這樣運(yùn)維同學(xué)可在Prometheus中配置告警當(dāng)recent_reject_count5分鐘內(nèi)突增300%立即通知開發(fā)——這比等用戶投訴快15分鐘。5.3 性能對(duì)比實(shí)測數(shù)據(jù)基于4核8G服務(wù)器我們對(duì)四種方案在相同硬件下進(jìn)行10萬次請求壓測JMeter100線程方案平均響應(yīng)時(shí)間TPS內(nèi)存占用增量Redis QPS適用業(yè)務(wù)等級(jí)Redis Token18.2ms549212MB5500★★★★★核心交易數(shù)據(jù)庫唯一約束22.7ms43983MB0★★★★☆重要操作請求指紋8.5ms117648MB0★★★☆☆高頻查詢混合式兜底25.1ms398225MB6000★★★★★金融級(jí)數(shù)據(jù)說明混合式雖TPS最低但它是唯一能在RedisDB雙故障時(shí)仍保證不產(chǎn)生臟數(shù)據(jù)的方案。我們建議對(duì)支付、轉(zhuǎn)賬等資金類接口必須用混合式對(duì)搜索、列表等非核心接口用請求指紋足夠。最后分享一個(gè)小技巧在application-dev.yml中將anti-repeat.enabledfalse開發(fā)階段關(guān)閉防重避免調(diào)試時(shí)反復(fù)生成Token測試環(huán)境開啟用JMeter驗(yàn)證生產(chǎn)環(huán)境必須開啟。這個(gè)開關(guān)救了我們兩次——一次是聯(lián)調(diào)時(shí)前端未傳Token導(dǎo)致全員阻塞一次是上線后發(fā)現(xiàn)Token生成邏輯有Bug緊急關(guān)閉開關(guān)爭取修復(fù)時(shí)間。真正的工程能力不在于寫出多炫酷的代碼而在于設(shè)計(jì)出能隨時(shí)“踩剎車”的系統(tǒng)。