面試刷題平臺項目總結

項目簡介：

面試刷題平臺是一款基于 Spring Boot + Redis+ MySQL+ Elasticsearch 的面試刷題平臺，運用 Druid + HotKey + Sa-Token+ Sentinel 提高了系統的性能和安全性。

第一階段，開發基礎的刷題平臺，帶大家熟悉項目開發流程，實戰 Spring Boot 應用的快速開發。

第二階段，對項目功能進行擴展，精選4個真實業務場景，實戰企業主流后端技術如 Redis 緩存和高級數據結構、Elasticsearch 搜索引擎、Druid 連接池、并發編程、熱 key 探測的應用。

第三階段，對項目安全性進行優化，比如基于Sentinel 進行網站流量控制和熔斷、基于 Nacos 實現動態的 IP 黑白名單、基于 Sa-Token 實現同端登錄沖突檢測.基于 Redis 實現分級反爬蟲策略等。

項目收獲：

如何結合 Redis + Caffeine + Hotkey 構建高性能實時緩存
如何利用 Elasticsearch 實現靈活高效的內容搜索
如何巧用 Redisson 高級數據結構，實現高性能的接口
如何實現流量控制和動態IP 黑白名單，增強網站安全性
如何實現登錄沖突檢測和分級反爬蟲策略，保護網站內容

用戶刷題日歷功能：

1、需求分析

為了鼓勵用戶多刷題并提升復盤體驗，系統需支持刷題日歷功能：每日用戶首次瀏覽題目自動記錄簽到，用戶可在前端通過圖表查看某一年內每日的刷題簽到情況。

2、技術方案

后端方案 - 位圖 (Bitmap)
位圖是一種用 bit 位存儲狀態的極致節省空間的數據結構，適合大規模布爾值存儲。在刷題簽到場景，每個用戶用位圖記錄一年 365 天的簽到情況，每位表示一天是否簽到（0未簽到，1已簽到）。

每年只需 46 字節存儲（46 × 8 ≥ 365天）。
100w 用戶 ≈ 43.8MB，1000w 用戶 ≈ 438MB，比Redis Set 節省數十倍內存。
位操作配合位運算，查詢和寫入效率高，適合低成本支撐千萬級用戶的簽到服務。

3、后端開發

查詢刷題簽到記錄接口優化

減少 Redis IO 次數（批量拉取，減少請求）
? 問題：循環內 .get(offset) 每天一次 Redis 請求，365 天等于 365 次請求，極大浪費網絡 IO。
? 優化方案：用 RBitSet.asBitSet() 一次性從 Redis 拉完整的 BitSet 到內存，后續直接走 JVM 內存查詢，只發一次請求。

精簡返回值，減少數據傳輸
? 問題：原本返回 Map<LocalDate, Boolean>，365 個鍵值對，數據量大、前端展示和后端計算都重。
? 優化方案：直接返回簽到天數 List，只返回用戶簽到的具體天數，大幅減少數據量和后端開銷，前端也好處理。

使用 nextSetBit 避免無意義遍歷
? 問題：以前用循環從 1 到 365 全量遍歷，遇到未簽到的天也強行 bitSet.get()，浪費 CPU。
? 優化方案：用 bitSet.nextSetBit(fromIndex) 跳躍式查找簽到天數，只遍歷有效位，CPU 計算量進一步降低。

總結一句話
從「多次 Redis IO」→「一次拉取內存」，從「全量 Map 返回」→「只返回簽到天數」，從「全量遍歷」→「跳躍查找」，讀請求的 Redis 壓力、CPU 開銷和網絡帶寬全方位優化，輕松應對高并發、低成本、大規模需求。

優化小結
總結出幾個實用優化思路

減少網絡請求或調用次數
減少接口傳輸數據的體積
減少循環和計算
通過客戶端計算減少服務端的壓力

分詞題目搜索功能

1、需求分析

MySQL 的 like 查詢只能簡單模糊匹配，不能同時匹配多個關鍵詞，而且數據量一大就很慢，復雜條件寫起來也費勁。而 Elasticsearch 是專門做搜索的，支持分詞、多個關鍵詞、相關性排序，搜索又快又準，用戶體驗更好。簡單說：MySQL 查得出，Elasticsearch 查得爽。

2、方案設計

設計 Elasticsearch 索引時，核心思路是根據業務搜索需求合理設置字段類型和分詞策略。

標題、內容、答案這種需要全文搜索的字段，一般用 text 類型配合中文分詞器（比如 ik_max_word 做索引，ik_smart 做搜索），支持更精準的匹配；
標簽、狀態這類用于精確過濾的字段，用 keyword；
數值型比如 userId 用 long，
時間字段用 date 并設置時間格式。
通過 aliases 可以實現索引平滑切換，方便后期無感知升級。

這樣設計兼顧了搜索準確性、查詢效率和索引的可維護性。

3.1、數據同步

全量同步，通過實現 CommandLineRunner 接口的run() 方法，在 Spring Boot 啟動完畢后自動執行從數據庫中全量獲取數據。

定時任務每分鐘自動從數據庫撈取近 5 分鐘內有變動的題目數據，同步到 Elasticsearch，確保 ES 數據是準實時的。
@Scheduled 定時任務：每分鐘觸發 run() 方法； MySQL 查詢：listQuestionWithDelete(fiveMinutesAgoDate) 查 5 分鐘內有改動的題；

3.2、ES接口降級策略實現

通過try-catch 實現降級策略，通過捕獲 Elasticsearch 查詢時的異常（比如超時、連接失敗），當 ES 查詢失敗時，程序自動進入 catch 邏輯，執行 MySQL 的模糊查詢作為兜底方案，確保接口不報錯、服務可用。

3.3、防止重復執行定時任務

在分布式部署或集群環境中，多個實例的定時任務可能在同一時間觸發同一個任務邏輯，造成：①任務重復執行，②數據重復寫入，③外部服務被重復調用

解決方案：基于 Redis 的分布式鎖RLock。通過給定時任務方法加上自定義注解 @DistributedLock，實現一個可配置、可自動釋放的分布式鎖攔截器，確保同一時刻只有一個節點能執行任務。

總結：使用 AOP + 分布式鎖注解（使用 Redisson 提供的 RLock.tryLock() 方法），可以確保在分布式環境下，同一時刻只有一個線程（通常指一個服務節點）能成功執行該定時任務，其他線程或節點會被鎖攔住或放棄執行。

題目批量管理功能

批處理優化
一般情況下，我們可以從以下多個角度對批處理任務進行優化。

健壯性

健壯性是指系統在面對異常情況或不合法輸入時仍能表現出合理的行為。一個健壯的系統能夠預見和處理異常，并且即使發生錯誤，也不會崩潰或產生不可預期的行為。

1、參數校驗提前

可以在數據庫操作前校驗參數，減少無效查詢。在當前添加題目到題庫的邏輯中，已校驗非空和題目、題庫存在性，但還缺少對題目是否已添加的校驗，導致可能重復插入，存在不必要的數據庫開銷。

2、異常處理

目前雖然有插入結果校驗和自定義異常，但部分異常未細化處理。可按異常類型分類處理，如唯一鍵沖突捕獲 DataIntegrityViolationException，數據庫或事務錯誤捕獲 DataAccessException，其他異常記錄詳細日志，便于排查。

穩定性

1、避免長事務

為避免長事務，批量操作應按批次分段處理，減少單次事務體量。若單條數據異常，只回滾當前批次，避免 10w 條全回滾，提升性能與穩定性。可通過新增方法實現分批事務控制。

具體實現：通過外層循環分批調用帶事務的方法，實現小批量事務處理，避免了長事務帶來的性能瓶頸和大范圍回滾風險，提升系統穩定性和并發處理能力。這里必須用 AopContext.currentProxy() 獲取當前類的代理對象來調用事務方法，因為 Spring 的事務是基于代理實現的，若直接用 this 調用，繞過了代理，事務不會生效。用代理調用才能保證事務攔截器生效，實現真正的事務控制。

2、重試

對于可能由于網絡不穩定等臨時原因偶發失敗的操作，可以設計重試機制提高系統的穩定性，適用于執行時間很長的任務。

具體實現：通過在for循環中捕獲異常，失敗時記錄重試次數并繼續嘗試，成功則跳出循環，超過最大重試次數仍失敗時拋出業務異常，實現簡單的重試機制保障操作可靠性。

性能優化

1、批量操作

當前代碼中，每個題目是單獨插入數據庫的，這會產生頻繁的數據庫交互。利用MyBatis Plus 的 saveBatch 方法，①降低數據庫連接和提交的頻率，②避免頻繁的數據庫交互，減少IO操作

2、SQL優化

最基本的 SQL優化原則，不使用 select * 來查詢數據，只查出需要的字段即可。不要返回整個Question對象，只返回題目ID即可。

3、并發編程

利用并發包中的 CompletableFuture +線程池來并發處理多個任務。CompletableFuture默認使用 ForkJoinPool 線程池，適合分治和遞歸任務。ForkJoinPool 采用工作竊取算法（從其他線程“竊取”任務），提高 CPU 利用率，通過拆分小任務并行執行，最后合并結果。

CompletableFuture 默認使用全局共享的 ForkJoinPool.commonPool()，多任務共用可能導致資源爭搶和阻塞，建議針對不同任務自定義線程池實現資源隔離。

自定義線程配置：核心線程數4、最大線程數10，線程空閑60秒后銷毀超過核心數的線程，使用容量為1000的阻塞隊列存放任務，拒絕策略為CallerRunsPolicy（由調用線程執行任務）

4、異步任務優化

立即執行異步任務：@Async注解
定時任務：將數據保存在Mysql中，通過Spring Scheduler定時任務掃描數據庫中未執行的任務。
消息隊列：對于對于長時間的批量任務，可以用消息隊列（RabbitMQ，Kafka）異步處理，將任務放入消息隊列，由消費者后臺異步執行。

5、數據庫連接調優

通過Druid復用數據庫連接，而不是在每次請求都新建和銷毀連接

Druid配置：初始連接數為10，最小空閑連接數為10，最大空閑連接數為10，超時等待（沒連接了，線程需要等多久）時間為6秒，每隔2秒檢測一次。

數據一致性

1、事務管理

我們目前已經使用了 @Transactional(rollbackFor = Exception.class)來保證一致性。如果任意一步操作失敗，整個事務會回滾，確保數據一致性。

2、并發管理

在高并發場景下，如果多個管理員同時向同一個題庫添加題目，可能會導致沖突或性能問題。為了解決并發問題，確保數據一致性和穩定性，可以有2種常見的策略

增加分布式鎖來防止同一個接口(或方法)在同一時間被多個管理員同時操作，比如使用 Redis + Redisson 實現分布式鎖。
如果要精細地對某個數據進行并發控制，可以選用樂觀鎖。比如通過給 questionBank 表增加一個 version 字段，在更新時檢查版本號是否一致，確保對同一個題庫的并發操作不會相互干擾。

自動緩存熱門題庫

1、需求分析

系統如何自動發現熱點數據將其緩存在本地或Redis中？
具體的規則：對于獲取題庫詳情的請求，如果5秒內訪問>=10 次，就要使用本地緩存將題庫詳情緩存 10 分鐘，之后都從本地緩存讀取。

2、方案設計

自動緩存熱門題庫需要以下五個步驟：

記錄訪問：用戶每訪問一次題庫，統計次數+1
訪問統計：統計一段時間內題庫的訪問次數。這是最難實現的一部分
閾值判斷：訪問頻率超過一定的閾值，變為熱點數據。
緩存數據：緩存熱點數據
獲取數據：后續訪問時，從緩存中獲取數據

HotKey組成部分

Worker：分布式計算集群，基于滑動窗口計算，根據dashboard里配置的rule規則，進行熱key推送。
Dashboard控制臺：ETCD集群，修改熱key規則配置信息
實例：拉起并監聽各worker信息；采集 key 使用數據，傳給 Worker，讓 Worker 判斷是不是熱 key

流程：

各worker上報自己信息到ETCD，維持心跳。
實例監采集 key 使用數據，傳給 Worker，讓 Worker 判斷是不是熱key。
實例建立和各worker的長連接，基于netty，將探測的key按hash算法分發到不同worker進行計算。
worker推送探測出的熱key到各實例，實例接受熱key信息，在JVM中緩存。

3、后端實現

HotKey配置規則：本地最大緩存Caffeine設置為10000（個鍵值對）；每隔1秒推送熱點Key

通過JdHotKeyStore.isHotKey(key) 用來判斷這個題目的 key 是否是熱點 key，就是看看這個題是不是近期高頻訪問、特別“燙手”的熱門數據。

再通過JdHotKeyStore.smartSet(key, questionBankVO)將判斷為熱點 key的數據緩存到本地緩存（Caffeine）

網站流量控制和熔斷（Sentinel）

1、需求分析

對查看題目列表接口整體限流

限流規則：

策略：整個接口每秒鐘不超過 10 次請求
阻塞操作：提示“系統壓力過大，請耐心等待”

熔斷規則：

熔斷條件：如果接口異常率超過 10%，或者慢調用(響應時長>3秒)的比例大于 20%，觸發 60 秒熔斷。
熔斷操作：直接返回本地數據(緩存或空數據)

單 IP 查看題目列表限流熔斷

限流規則：

策略：每個IP 地址每分鐘允許查看題目列表的次數不能超過 60 次。
阻塞操作：提示“訪問過于頻繁，請稍后再試”

熔斷規則:

熔斷條件：如果接口異常率超過 10%，或者慢調用(響應時長>3秒)的比例大于 20%，觸發 60 秒熔斷。
熔斷操作:直接返回本地數據(緩存或空數據)。

2、后端開發

使用 Sentinel 來進行資源保護，主要分為幾個步驟

定義資源
定義規則
檢驗規則是否生效

開發模式：用注解定義資源 +基于控制臺定義規則

對查看題目列表接口整體限流

資源的定義是通過 @SentinelResource 注解完成的，value 字段就代表 “資源名稱”。 blockHandler、fallback 分別指定限流/降級兜底方法

每次調用這個接口，Sentinel 底層就會創建一個 Entry，資源名 = listQuestionBankVOByPage，開始走限流、降級判斷；

單IP查看題目列表限流熔斷

1?、定義資源

資源名稱是：listQuestionVOByPage
通過：
- SphU.entry(“listQuestionVOByPage”, EntryType.IN, 1, remoteAddr)明確標識“按接口 + IP”作為限流和熔斷的維度。

2?、限流規則（ParamFlowRule）

目標：針對單個 IP 限流
規則配置：
- setParamIdx(0)：按第一個參數（remoteAddr，IP 地址）限流
- setCount(60)：每個 IP 每分鐘最多請求 60 次
- setDurationInSec(60)：統計周期 60 秒
效果：短時間內某個 IP 請求次數超限，直接限流。

3?、熔斷規則（DegradeRule）

慢調用熔斷：
- 過去 30 秒內，調用量超過 10 次
- 慢調用（>3秒）的比例超過 20% 時熔斷
- 熔斷時間：60 秒
異常率熔斷：
- 過去 30 秒內，調用量超過 10 次
- 異常比例超過 10% 時觸發熔斷
- 熔斷時間：60 秒
核心效果：接口響應時間持續過長或異常率高時主動熔斷，保護后端。

4?、代碼兜底邏輯

限流/熔斷命中時觸發 fallback：
- handleFallback()：可返回空數據或緩存數據
Tracer.trace()：主動記錄非限流業務異常
BlockException 判斷：精準區分業務異常 vs 限流/熔斷異常

按IP限流與單個接口限流的區別

資源名：listQuestionVOByPage 是唯一標識

無論是整體接口限流，還是基于 IP 限流，資源名都是一樣的，都是 “listQuestionVOByPage”，它代表了業務接口這個“大對象”。

1?、對整個接口限流

不傳熱點參數，或限流規則不配置熱點參數維度（ParamFlowRule）：
- 調用時：SphU.entry(“listQuestionVOByPage”)（沒有參數傳入）
- 限流規則針對整個資源整體請求數限制，比如每秒不超過 1000 次
- 這時限流統計的是所有請求加起來的流量，不區分用戶或 IP。

2?、對 IP 維度限流

調用時傳熱點參數（IP），并配置 ParamFlowRule 綁定參數索引：
- 調用時：SphU.entry(“listQuestionVOByPage”, EntryType.IN, 1, remoteAddr)
- 限流規則：setParamIdx(0)，表示按第一個參數（IP）做限流
- Sentinel 會針對每個不同 IP 單獨統計和限流，互不影響

動態IP黑名單過濾（Nacos）

1、需求分析

通過IP封禁，有效拉黑攻擊者，防止資源濫用。

2、方案設計

使用 Nacos 配置中心存儲和管理 IP 黑名單
后端服務利用 Web 過濾器判斷每個用戶請求的 IP
后端服務利用布隆過濾器過濾 IP 黑名單

3、后端實現

動態接收黑名單配置，用布隆過濾器高效判斷 IP 是否被拉黑，兼顧“性能高”“內存省”“更新靈活”。

1?、存儲結構：BitMapBloomFilter

bloomFilter：用布隆過濾器存儲黑名單 IP，快速判斷是否存在，查詢 O(1)，內存占用極低，允許極小誤判但不會漏判。

2?、isBlackIp() 方法

isBlackIp(String ip)：對外暴露接口，用布隆過濾器判斷某個 IP 是否是黑名單命中

3?、rebuildBlackIp() 方法

支持動態刷新黑名單：
- 接收最新的黑名單配置（configInfo），通常是字符串（YAML 格式）。
- 用 SnakeYAML 解析出 IP 列表。
- 同步加鎖確保黑名單重建時線程安全；對 BlackIpUtils.class 加鎖，是為了確保全局唯一的布隆過濾器在更新時不會出現多線程并發覆蓋，保障重建過程的原子性和數據完整性。
- 重新生成 bloomFilter 實例，切換成新的黑名單。

基于 Nacos 的動態配置監聽機制

NacosListener 通過實現 InitializingBean 接口，結合線程安全的 AtomicInteger 和異步線程池，在 Spring 啟動完成后第一時間注冊監聽器，同時配置變更的回調由 Nacos 客戶端通過長輪詢機制自動觸發，通過注冊 Listener 并保持 SDK 正常運行，就會在后臺自動拉配置、自動比對并調用 receiveConfigInfo() 方法確保系統可以動態感知黑名單配置變更并實時刷新本地數據，提升可用性和動態調控能力。

創建黑名單過濾器

黑名單應該對所有請求生效(不止是 Controller 的接口)，所以基于 WebFilter 實現而不是 AOP 切面。
WebFilter 的優先級高于 @Aspect 切面，因為它在整個 Web 請求生命周期中更早進行處理。請求進入時的順序:

WebFilter：首先，Webfilter 攔截 HTTP 請求，并可以根據邏輯決定是否繼續執行請求。
Spring AOP切面(@Aspect)：如果請求經過過濾器并進入 Spring 管理的 Bean(例如 Controller層)，此時切面生效，對匹配的Bean 方法進行攔截。
Controller層：如果 @Aspect 沒有阻止執行，最終請求到達 @Controller或@RestController 的方法。

題目分級反爬蟲

1、需求分析

知識付費類網站以內容為核心，一旦被惡意爬蟲大規模抓取，不僅可能造成數據泄露和濫用，還會加重服務器負擔，影響正常用戶體驗。因此，需要部署有效的反爬蟲機制來保障系統安全與內容價值。

2、技術方案

建議采用分級反爬蟲策略，先告警、再采取強制措施，可以有效減少誤封的風險:

如果每分鐘超過 10 道題目，則給管理員發送告警，比如發送郵件或者短信。
如果每分鐘超過 20 道題目，則直接將賬號踢下線，且進行封號操作。(或者限制一段時間無法訪問)

3、后端開發

設計 Redis 鍵值對要能區分出用戶和時間窗，示例 key 為 user:access:{userId}:{timestamp_in_minutes}

{userld} 是用戶 ID。
{timestamp_in_minutes}是當前的分鐘級時間戳，即將當前時間戳轉化為分鐘，這樣每分鐘的訪問都會被統計到一個 key 中。

每個 key 的 value，就是該用戶在這分鐘內的訪問次數。

Redis操作邏輯

在反爬蟲場景中，我們常用 Redis 來做訪問頻率統計，通過統計單位時間內某個 IP 或用戶的請求次數，判斷是否觸發限流或封禁。

傳統寫法的問題：
jedis.incr(key); // 第一步：計數
jedis.expire(key, 60); // 第二步：設置60秒過期。
問題：如果多線程訪問，你原本想統計“某個 IP 在 60 秒內訪問了多少次”；實際上由于每次訪問都把 TTL 重新設為 60s，所以這個 key 一直存在，永遠不會自動清除；

解決辦法：用 Lua 保證原子 + 只設一次 TTL 的

總結：在高并發場景中，incr 和 expire 是非原子操作，容易導致 TTL 被頻繁重置，造成 Redis key 永久存在，失去限流窗口的意義。通過 Lua 腳本保證“只設一次 TTL”，可以有效避免這個問題。