2026最新打卡簽到面試真題拆解
官方文檔動(dòng)輒幾百頁(yè)，翻來(lái)覆去全是術(shù)語(yǔ)，面試時(shí)根本抓不住重點(diǎn)。很多候選人背了一堆八股文，結(jié)果面試官問(wèn)一句“怎么防止用戶刷分”，腦子瞬間空白。
2026年的后端開(kāi)發(fā)，對(duì)高并發(fā)場(chǎng)景下的數(shù)據(jù)一致性要求更高。打卡簽到看似簡(jiǎn)單，實(shí)則是考察Redis原子性、數(shù)據(jù)庫(kù)鎖機(jī)制、分布式事務(wù)邊界的絕佳載體。
今天這篇內(nèi)容，直接跳過(guò)那些晦澀的理論推導(dǎo)。我們直擊大廠面試高頻考點(diǎn)，把簽到系統(tǒng)的核心邏輯拆碎揉爛。不管你是準(zhǔn)備秋招、春招，還是內(nèi)部晉升，把這篇文章吃透，簽到模塊的面試問(wèn)題基本能拿滿分。
考點(diǎn)梳理：面試官到底在考什么
別被“打卡簽到”這個(gè)名詞騙了，它不是讓你去實(shí)現(xiàn)一個(gè)按鈕。在面試語(yǔ)境下，它背后藏著三個(gè)核心考點(diǎn)。
第一，高并發(fā)下的冪等性處理。
早晚高峰，百萬(wàn)級(jí)用戶同時(shí)點(diǎn)擊簽到。如果系統(tǒng)不做冪等控制，同一個(gè)用戶可能扣掉多次積分，或者寫(xiě)入多條重復(fù)記錄。面試官想聽(tīng)的是：你怎么保證“一人一天只簽一次”？是用Redis的SETNX，還是數(shù)據(jù)庫(kù)的唯一索引？
第二，數(shù)據(jù)一致性與最終一致性權(quán)衡。
簽到成功需要更新用戶表積分，同時(shí)插入簽到流水表。如果更新積分成功，但插入流水失敗，數(shù)據(jù)就臟了。是強(qiáng)一致性的本地事務(wù)，還是允許短暫不一致的最終一致性？這里涉及消息隊(duì)列、補(bǔ)償機(jī)制的選型。
第三，時(shí)間邊界與跨天處理。
服務(wù)器時(shí)區(qū)、用戶時(shí)區(qū)、夏令時(shí)切換。凌晨0點(diǎn)0分0秒那一刻，數(shù)據(jù)庫(kù)里到底是前一天的記錄還是新一天的？這個(gè)細(xì)節(jié)，很多候選人根本想不到，但卻是線上事故的重災(zāi)區(qū)。
官方文檔里關(guān)于Redis事務(wù)的描述，往往只給了幾個(gè)命令示例，卻沒(méi)告訴你在高并發(fā)下MULTI和EXEC的延遲抖動(dòng)問(wèn)題。面試中，如果你能主動(dòng)指出這點(diǎn)，直接加分。
標(biāo)準(zhǔn)答法：結(jié)構(gòu)化表達(dá)模板
回答技術(shù)面試題，切忌像背書(shū)一樣從頭講到尾。建議采用“結(jié)論先行 + 方案對(duì)比 + 落地細(xì)節(jié)”的結(jié)構(gòu)。
第一步，直接給出選型結(jié)論。
“針對(duì)簽到場(chǎng)景，我推薦采用 Redis 做前置校驗(yàn)，數(shù)據(jù)庫(kù)做最終落庫(kù)。利用 Redis 的原子性操作保證冪等，利用數(shù)據(jù)庫(kù)唯一索引做兜底?！?第二步，簡(jiǎn)述核心流程。
“用戶請(qǐng)求進(jìn)入網(wǎng)關(guān)，先查 Redis。如果 Key 不存在，執(zhí)行 SETNX 嘗試占坑。成功則異步發(fā)送消息到 MQ，由消費(fèi)者更新數(shù)據(jù)庫(kù)積分并寫(xiě)入流水。失敗則直接返回‘已簽到’?！?第三步，拋出關(guān)鍵難點(diǎn)與解決方案。
“這里最大的風(fēng)險(xiǎn)是 Redis 與 DB 的數(shù)據(jù)不同步。比如 Redis 占坑成功，但 MQ 消息丟失。我的對(duì)策是：數(shù)據(jù)庫(kù)表增加唯一索引 (user_id, sign_date)。即使 Redis 掛了，數(shù)據(jù)庫(kù)層也能攔截重復(fù)數(shù)據(jù)。同時(shí)，通過(guò)定時(shí)任務(wù)掃描 Redis 中存在但 DB 中無(wú)記錄的‘孤兒數(shù)據(jù)’，進(jìn)行補(bǔ)償刪除?！?注意，不要只說(shuō)“用Redis”。要說(shuō)出為什么用Redis（快、原子性），以及用了之后有什么風(fēng)險(xiǎn)（數(shù)據(jù)不一致），最后給出兜底方案（DB唯一索引+補(bǔ)償任務(wù)）。這才是有實(shí)戰(zhàn)經(jīng)驗(yàn)的答法。
代碼實(shí)現(xiàn)：Redis + MySQL 實(shí)戰(zhàn)
光說(shuō)不練假把式。下面給出一段 Java 實(shí)現(xiàn)，涵蓋 Redis 原子操作與數(shù)據(jù)庫(kù)兜底邏輯。這段代碼可以直接作為面試白板編程的參考。
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Service;import java.time.LocalDate;
import java.util.concurrent.TimeUnit;@Service
public class SignService {private final RedisTemplateString, String redisTemplate;private final JdbcTemplate jdbcTemplate;// 構(gòu)造函數(shù)注入，省略...public String doSign(Long userId) {// 1. 獲取當(dāng)前業(yè)務(wù)日期，注意時(shí)區(qū)處理LocalDate today = LocalDate.now();String signKey = String.format(sign:%s:%d, today.toString(), userId);// 2. 使用 SETNX 原子操作，確保冪等// NX: 只在不存在時(shí)設(shè)置// EX: 設(shè)置過(guò)期時(shí)間，比如7天后自動(dòng)清理，防止Redis內(nèi)存溢出Boolean isSuccess = redisTemplate.opsForValue().setIfAbsent(signKey, 1, 7, TimeUnit.DAYS);if (Boolean.FALSE.equals(isSuccess)) {return 已簽到，請(qǐng)勿重復(fù)操作;}try {// 3. 數(shù)據(jù)庫(kù)落庫(kù)，利用唯一索引兜底// 假設(shè)表結(jié)構(gòu): user_sign_log (id, user_id, sign_date, create_time)// 索引: UNIQUE KEY uk_user_date (user_id, sign_date)jdbcTemplate.update(INSERT INTO user_sign_log (user_id, sign_date, create_time) VALUES (?, ?, NOW()),userId, today.toString());// 4. 更新用戶積分 (此處省略積分邏輯，實(shí)際應(yīng)放在事務(wù)中或異步處理)jdbcTemplate.update(UPDATE user SET points = points + 1 WHERE id = ?,userId);return 簽到成功;} catch (Exception e) {// 5. 異常補(bǔ)償：如果DB插入失敗，必須刪除Redis Key，否則用戶今天無(wú)法簽到redisTemplate.delete(signKey);// 記錄錯(cuò)誤日志，觸發(fā)告警// log.error(Sign failed for user: {}, userId, e);throw new RuntimeException(系統(tǒng)繁忙，請(qǐng)稍后重試);}}
}逐行講解關(guān)鍵細(xì)節(jié)：Key 的設(shè)計(jì)：sign:{date}:{userId}。日期作為Key的一部分，天然隔離了不同日期的數(shù)據(jù)。過(guò)期時(shí)間設(shè)為7天，是一個(gè)經(jīng)驗(yàn)值，既覆蓋了可能的查詢需求，又控制了內(nèi)存占用。
setIfAbsent：這是 SETNX 的 Java 封裝。它是原子的，不存在“查了沒(méi)有 - 再設(shè)置”的時(shí)間窗口，杜絕了并發(fā)穿透。
唯一索引兜底：代碼中 INSERT 語(yǔ)句依賴數(shù)據(jù)庫(kù)的唯一索引 uk_user_date。如果 Redis 故障導(dǎo)致 setIfAbsent 誤判，或者網(wǎng)絡(luò)抖動(dòng)導(dǎo)致重復(fù)請(qǐng)求到達(dá) DB，唯一索引會(huì)拋出 DuplicateKeyException。
異常補(bǔ)償邏輯：這是最容易被忽略的點(diǎn)。如果 DB 插入失敗，必須刪除 Redis Key。否則，用戶雖然這次簽到失敗，但 Redis 里已經(jīng)有了記錄，導(dǎo)致他今天永遠(yuǎn)無(wú)法再簽到。這就是“狀態(tài)回滾”的重要性。追問(wèn)與延伸：高階場(chǎng)景應(yīng)對(duì)
面試官不會(huì)滿足于基礎(chǔ)實(shí)現(xiàn)，往往會(huì)追問(wèn)極端場(chǎng)景。
追問(wèn)一：如果 Redis 集群發(fā)生了主從切換，數(shù)據(jù)丟失了怎么辦？
答：Redis 持久化機(jī)制（AOF/RDB）通常能恢復(fù)大部分?jǐn)?shù)據(jù)，但極端情況下可能丟數(shù)據(jù)。如果 Redis 里的 Key 丟了，用戶會(huì)再次點(diǎn)擊簽到。此時(shí) setIfAbsent 會(huì)成功，請(qǐng)求進(jìn)入 DB。由于 DB 有唯一索引，插入會(huì)失敗，拋出異常。我們?cè)?catch 塊中會(huì)刪除 Redis Key 并提示用戶。雖然用戶體驗(yàn)不佳（報(bào)錯(cuò)），但數(shù)據(jù)不會(huì)重復(fù)，保證了業(yè)務(wù)正確性。這是“可用性”讓位于“一致性”的取舍。
追問(wèn)二：如何防止腳本刷單？
答：僅靠后端邏輯不夠。前端需要增加驗(yàn)證碼或滑塊驗(yàn)證。后端接口需要增加簽名校驗(yàn)（Sign），防止重放攻擊。此外，可以結(jié)合 IP 限流、設(shè)備指紋識(shí)別。如果短時(shí)間內(nèi)同一 IP 發(fā)起大量不同用戶的簽到請(qǐng)求，觸發(fā)風(fēng)控系統(tǒng)攔截。
追問(wèn)三：連續(xù)簽到30天獎(jiǎng)勵(lì)怎么實(shí)現(xiàn)？
答：不要每次簽到都去查過(guò)去30天的記錄，性能太差。建議在用戶表或獨(dú)立的簽到狀態(tài)表中，維護(hù)一個(gè) last_sign_date 和 continuous_days 字段。如果 today 等于 last_sign_date + 1，則 continuous_days 加 1。
如果 today 不等于 last_sign_date + 1，則 continuous_days 重置為 1。
如果 continuous_days 達(dá)到 30，發(fā)放獎(jiǎng)勵(lì)。
這種 O(1) 復(fù)雜度的方案，比 O(N) 查詢流水表高效得多。關(guān)于官方文檔的補(bǔ)充：
Redis 官方文檔在 SET 命令中明確指出了 NX 和 EX 可以同時(shí)使用，且是原子操作。很多候選人不知道這一點(diǎn)，以為需要先 SETNX 再 EXPIRE，這是典型的非原子操作，高并發(fā)下會(huì)導(dǎo)致 Key 永不過(guò)期，引發(fā)內(nèi)存泄漏。面試中引用官方文檔細(xì)節(jié)，能極大提升專業(yè)度。
記憶口訣：快速?gòu)?fù)盤(pán)防遺忘
面試前緊張容易忘，記住這個(gè)口訣：
“鍵值帶日期，NX防并發(fā)；
DB有索引，兜底保安全；
異常要回滾，刪Key別忘干；
連簽用字段，別查流水單?！辨I值帶日期：Key 設(shè)計(jì)要包含業(yè)務(wù)日期，方便過(guò)期清理。
NX防并發(fā)：用 SETNX 原子操作做前置攔截。
DB有索引：數(shù)據(jù)庫(kù)必須加唯一索引，作為最后一道防線。
兜底保安全：Redis 掛了或誤判，DB 能攔住重復(fù)數(shù)據(jù)。
異常要回滾：DB 失敗必須刪 Redis Key，否則用戶卡死。
連簽用字段：連續(xù)簽到狀態(tài)存在字段里，別每次查表。簽到系統(tǒng)雖小，但五臟俱全。它涵蓋了緩存一致性、冪等性設(shè)計(jì)、異常補(bǔ)償、性能優(yōu)化等多個(gè)后端核心概念。把這幾個(gè)點(diǎn)串起來(lái)，你就不是只會(huì)背八股文的人了。
你在實(shí)際項(xiàng)目中，是傾向于用 Redis 做強(qiáng)一致性校驗(yàn)，還是直接依賴數(shù)據(jù)庫(kù)唯一索引扛并發(fā)？這兩種方案在高并發(fā)下的表現(xiàn)差異，你更常用哪種寫(xiě)法？評(píng)論區(qū)交流。 2026最新打卡簽到面試真題拆解
2026最新打卡簽到面試真題拆解
官方文檔動(dòng)輒幾百頁(yè)，翻來(lái)覆去全是術(shù)語(yǔ)，面試時(shí)根本抓不住重點(diǎn)。很多候選人背了一堆八股文，結(jié)果面試官問(wèn)一句“怎么防止用戶刷分”，腦子瞬間空白。
2026年的后端開(kāi)發(fā)，對(duì)高并發(fā)場(chǎng)景下的數(shù)據(jù)一致性要求更高。打卡簽到看似簡(jiǎn)單，實(shí)則是考察Redis原子性、數(shù)據(jù)庫(kù)鎖機(jī)制、分布式事務(wù)邊界的絕佳載體。
今天這篇內(nèi)容，直接跳過(guò)那些晦澀的理論推導(dǎo)。我們直擊大廠面試高頻考點(diǎn)，把簽到系統(tǒng)的核心邏輯拆碎揉爛。不管你是準(zhǔn)備秋招、春招，還是內(nèi)部晉升，把這篇文章吃透，簽到模塊的面試問(wèn)題基本能拿滿分。
考點(diǎn)梳理：面試官到底在考什么
別被“打卡簽到”這個(gè)名詞騙了，它不是讓你去實(shí)現(xiàn)一個(gè)按鈕。在面試語(yǔ)境下，它背后藏著三個(gè)核心考點(diǎn)。
第一，高并發(fā)下的冪等性處理。
早晚高峰，百萬(wàn)級(jí)用戶同時(shí)點(diǎn)擊簽到。如果系統(tǒng)不做冪等控制，同一個(gè)用戶可能扣掉多次積分，或者寫(xiě)入多條重復(fù)記錄。面試官想聽(tīng)的是：你怎么保證“一人一天只簽一次”？是用Redis的SETNX，還是數(shù)據(jù)庫(kù)的唯一索引？
第二，數(shù)據(jù)一致性與最終一致性權(quán)衡。
簽到成功需要更新用戶表積分，同時(shí)插入簽到流水表。如果更新積分成功，但插入流水失敗，數(shù)據(jù)就臟了。是強(qiáng)一致性的本地事務(wù)，還是允許短暫不一致的最終一致性？這里涉及消息隊(duì)列、補(bǔ)償機(jī)制的選型。
第三，時(shí)間邊界與跨天處理。
服務(wù)器時(shí)區(qū)、用戶時(shí)區(qū)、夏令時(shí)切換。凌晨0點(diǎn)0分0秒那一刻，數(shù)據(jù)庫(kù)里到底是前一天的記錄還是新一天的？這個(gè)細(xì)節(jié)，很多候選人根本想不到，但卻是線上事故的重災(zāi)區(qū)。
官方文檔里關(guān)于Redis事務(wù)的描述，往往只給了幾個(gè)命令示例，卻沒(méi)告訴你在高并發(fā)下MULTI和EXEC的延遲抖動(dòng)問(wèn)題。面試中，如果你能主動(dòng)指出這點(diǎn)，直接加分。
標(biāo)準(zhǔn)答法：結(jié)構(gòu)化表達(dá)模板
回答技術(shù)面試題，切忌像背書(shū)一樣從頭講到尾。建議采用“結(jié)論先行 + 方案對(duì)比 + 落地細(xì)節(jié)”的結(jié)構(gòu)。
第一步，直接給出選型結(jié)論。
“針對(duì)簽到場(chǎng)景，我推薦采用 Redis 做前置校驗(yàn)，數(shù)據(jù)庫(kù)做最終落庫(kù)。利用 Redis 的原子性操作保證冪等，利用數(shù)據(jù)庫(kù)唯一索引做兜底?！?第二步，簡(jiǎn)述核心流程。
“用戶請(qǐng)求進(jìn)入網(wǎng)關(guān)，先查 Redis。如果 Key 不存在，執(zhí)行 SETNX 嘗試占坑。成功則異步發(fā)送消息到 MQ，由消費(fèi)者更新數(shù)據(jù)庫(kù)積分并寫(xiě)入流水。失敗則直接返回‘已簽到’?！?第三步，拋出關(guān)鍵難點(diǎn)與解決方案。
“這里最大的風(fēng)險(xiǎn)是 Redis 與 DB 的數(shù)據(jù)不同步。比如 Redis 占坑成功，但 MQ 消息丟失。我的對(duì)策是：數(shù)據(jù)庫(kù)表增加唯一索引 (user_id, sign_date)。即使 Redis 掛了，數(shù)據(jù)庫(kù)層也能攔截重復(fù)數(shù)據(jù)。同時(shí)，通過(guò)定時(shí)任務(wù)掃描 Redis 中存在但 DB 中無(wú)記錄的‘孤兒數(shù)據(jù)’，進(jìn)行補(bǔ)償刪除?！?注意，不要只說(shuō)“用Redis”。要說(shuō)出為什么用Redis（快、原子性），以及用了之后有什么風(fēng)險(xiǎn)（數(shù)據(jù)不一致），最后給出兜底方案（DB唯一索引+補(bǔ)償任務(wù)）。這才是有實(shí)戰(zhàn)經(jīng)驗(yàn)的答法。
代碼實(shí)現(xiàn)：Redis + MySQL 實(shí)戰(zhàn)
光說(shuō)不練假把式。下面給出一段 Java 實(shí)現(xiàn)，涵蓋 Redis 原子操作與數(shù)據(jù)庫(kù)兜底邏輯。這段代碼可以直接作為面試白板編程的參考。
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Service;import java.time.LocalDate;
import java.util.concurrent.TimeUnit;@Service
public class SignService {private final RedisTemplateString, String redisTemplate;private final JdbcTemplate jdbcTemplate;// 構(gòu)造函數(shù)注入，省略...public String doSign(Long userId) {// 1. 獲取當(dāng)前業(yè)務(wù)日期，注意時(shí)區(qū)處理LocalDate today = LocalDate.now();String signKey = String.format(sign:%s:%d, today.toString(), userId);// 2. 使用 SETNX 原子操作，確保冪等// NX: 只在不存在時(shí)設(shè)置// EX: 設(shè)置過(guò)期時(shí)間，比如7天后自動(dòng)清理，防止Redis內(nèi)存溢出Boolean isSuccess = redisTemplate.opsForValue().setIfAbsent(signKey, 1, 7, TimeUnit.DAYS);if (Boolean.FALSE.equals(isSuccess)) {return 已簽到，請(qǐng)勿重復(fù)操作;}try {// 3. 數(shù)據(jù)庫(kù)落庫(kù)，利用唯一索引兜底// 假設(shè)表結(jié)構(gòu): user_sign_log (id, user_id, sign_date, create_time)// 索引: UNIQUE KEY uk_user_date (user_id, sign_date)jdbcTemplate.update(INSERT INTO user_sign_log (user_id, sign_date, create_time) VALUES (?, ?, NOW()),userId, today.toString());// 4. 更新用戶積分 (此處省略積分邏輯，實(shí)際應(yīng)放在事務(wù)中或異步處理)jdbcTemplate.update(UPDATE user SET points = points + 1 WHERE id = ?,userId);return 簽到成功;} catch (Exception e) {// 5. 異常補(bǔ)償：如果DB插入失敗，必須刪除Redis Key，否則用戶今天無(wú)法簽到redisTemplate.delete(signKey);// 記錄錯(cuò)誤日志，觸發(fā)告警// log.error(Sign failed for user: {}, userId, e);throw new RuntimeException(系統(tǒng)繁忙，請(qǐng)稍后重試);}}
}逐行講解關(guān)鍵細(xì)節(jié)：Key 的設(shè)計(jì)：sign:{date}:{userId}。日期作為Key的一部分，天然隔離了不同日期的數(shù)據(jù)。過(guò)期時(shí)間設(shè)為7天，是一個(gè)經(jīng)驗(yàn)值，既覆蓋了可能的查詢需求，又控制了內(nèi)存占用。
setIfAbsent：這是 SETNX 的 Java 封裝。它是原子的，不存在“查了沒(méi)有 - 再設(shè)置”的時(shí)間窗口，杜絕了并發(fā)穿透。
唯一索引兜底：代碼中 INSERT 語(yǔ)句依賴數(shù)據(jù)庫(kù)的唯一索引 uk_user_date。如果 Redis 故障導(dǎo)致 setIfAbsent 誤判，或者網(wǎng)絡(luò)抖動(dòng)導(dǎo)致重復(fù)請(qǐng)求到達(dá) DB，唯一索引會(huì)拋出 DuplicateKeyException。
異常補(bǔ)償邏輯：這是最容易被忽略的點(diǎn)。如果 DB 插入失敗，必須刪除 Redis Key。否則，用戶雖然這次簽到失敗，但 Redis 里已經(jīng)有了記錄，導(dǎo)致他今天永遠(yuǎn)無(wú)法再簽到。這就是“狀態(tài)回滾”的重要性。追問(wèn)與延伸：高階場(chǎng)景應(yīng)對(duì)
面試官不會(huì)滿足于基礎(chǔ)實(shí)現(xiàn)，往往會(huì)追問(wèn)極端場(chǎng)景。
追問(wèn)一：如果 Redis 集群發(fā)生了主從切換，數(shù)據(jù)丟失了怎么辦？
答：Redis 持久化機(jī)制（AOF/RDB）通常能恢復(fù)大部分?jǐn)?shù)據(jù)，但極端情況下可能丟數(shù)據(jù)。如果 Redis 里的 Key 丟了，用戶會(huì)再次點(diǎn)擊簽到。此時(shí) setIfAbsent 會(huì)成功，請(qǐng)求進(jìn)入 DB。由于 DB 有唯一索引，插入會(huì)失敗，拋出異常。我們?cè)?catch 塊中會(huì)刪除 Redis Key 并提示用戶。雖然用戶體驗(yàn)不佳（報(bào)錯(cuò)），但數(shù)據(jù)不會(huì)重復(fù)，保證了業(yè)務(wù)正確性。這是“可用性”讓位于“一致性”的取舍。
追問(wèn)二：如何防止腳本刷單？
答：僅靠后端邏輯不夠。前端需要增加驗(yàn)證碼或滑塊驗(yàn)證。后端接口需要增加簽名校驗(yàn)（Sign），防止重放攻擊。此外，可以結(jié)合 IP 限流、設(shè)備指紋識(shí)別。如果短時(shí)間內(nèi)同一 IP 發(fā)起大量不同用戶的簽到請(qǐng)求，觸發(fā)風(fēng)控系統(tǒng)攔截。
追問(wèn)三：連續(xù)簽到30天獎(jiǎng)勵(lì)怎么實(shí)現(xiàn)？
答：不要每次簽到都去查過(guò)去30天的記錄，性能太差。建議在用戶表或獨(dú)立的簽到狀態(tài)表中，維護(hù)一個(gè) last_sign_date 和 continuous_days 字段。如果 today 等于 last_sign_date + 1，則 continuous_days 加 1。
如果 today 不等于 last_sign_date + 1，則 continuous_days 重置為 1。
如果 continuous_days 達(dá)到 30，發(fā)放獎(jiǎng)勵(lì)。
這種 O(1) 復(fù)雜度的方案，比 O(N) 查詢流水表高效得多。關(guān)于官方文檔的補(bǔ)充：
Redis 官方文檔在 SET 命令中明確指出了 NX 和 EX 可以同時(shí)使用，且是原子操作。很多候選人不知道這一點(diǎn)，以為需要先 SETNX 再 EXPIRE，這是典型的非原子操作，高并發(fā)下會(huì)導(dǎo)致 Key 永不過(guò)期，引發(fā)內(nèi)存泄漏。面試中引用官方文檔細(xì)節(jié)，能極大提升專業(yè)度。
記憶口訣：快速?gòu)?fù)盤(pán)防遺忘
面試前緊張容易忘，記住這個(gè)口訣：
“鍵值帶日期，NX防并發(fā)；
DB有索引，兜底保安全；
異常要回滾，刪Key別忘干；
連簽用字段，別查流水單?！辨I值帶日期：Key 設(shè)計(jì)要包含業(yè)務(wù)日期，方便過(guò)期清理。
NX防并發(fā)：用 SETNX 原子操作做前置攔截。
DB有索引：數(shù)據(jù)庫(kù)必須加唯一索引，作為最后一道防線。
兜底保安全：Redis 掛了或誤判，DB 能攔住重復(fù)數(shù)據(jù)。
異常要回滾：DB 失敗必須刪 Redis Key，否則用戶卡死。
連簽用字段：連續(xù)簽到狀態(tài)存在字段里，別每次查表。簽到系統(tǒng)雖小，但五臟俱全。它涵蓋了緩存一致性、冪等性設(shè)計(jì)、異常補(bǔ)償、性能優(yōu)化等多個(gè)后端核心概念。把這幾個(gè)點(diǎn)串起來(lái)，你就不是只會(huì)背八股文的人了。
你在實(shí)際項(xiàng)目中，是傾向于用 Redis 做強(qiáng)一致性校驗(yàn)，還是直接依賴數(shù)據(jù)庫(kù)唯一索引扛并發(fā)？這兩種方案在高并發(fā)下的表現(xiàn)差異，你更常用哪種寫(xiě)法？評(píng)論區(qū)交流。