SpringBoot項目中實現(xiàn)接口冪等的代碼詳解
前言
在 Spring Boot 項目中實現(xiàn)接口冪等性是確保系統(tǒng)數(shù)據(jù)一致性和可靠性的關(guān)鍵手段,尤其在支付、訂單等核心業(yè)務(wù)場景中。下面我將為你介紹幾種常見的實現(xiàn)方案、選擇建議以及一些注意事項。
| 方案 | 核心機制 | 實現(xiàn)復(fù)雜度 | 性能影響 | 外部依賴 | 典型適用場景 |
|---|---|---|---|---|---|
| ?Token 令牌? | 預(yù)生成一次性令牌,使用后即焚 | 低 | 中 | Redis | 用戶下單、支付 |
| ?數(shù)據(jù)庫唯一索引? | 利用數(shù)據(jù)庫唯一約束防止重復(fù)數(shù)據(jù)插入 | 低 | 低 | 數(shù)據(jù)庫 | 數(shù)據(jù)插入操作,如支付記錄創(chuàng)建 |
| ?數(shù)據(jù)庫樂觀鎖? | 通過版本號控制更新,避免重復(fù)更新 | 中 | 低 | 數(shù)據(jù)庫 | 更新操作,如庫存扣減 |
| ?分布式鎖? | 加鎖確保同一業(yè)務(wù)標識的請求串行處理 | 中 | 中 | Redis/ZooKeeper | 高并發(fā)場景,如秒殺、搶券 |
| ?請求摘要? | 計算請求參數(shù)哈希值作為冪等鍵 | 中 | 低 | Redis | 參數(shù)固定的重復(fù)請求 |
1. Token 令牌機制
這種方式要求客戶端在發(fā)起業(yè)務(wù)請求前,先獲取一個服務(wù)器頒發(fā)的唯一令牌(Token),并在后續(xù)請求中攜帶該令牌。
?實現(xiàn)步驟:
服務(wù)端提供獲取 Token 的接口,生成一個唯一 Token(如 UUID)并存入 Redis,設(shè)置合理的過期時間。
客戶端調(diào)用業(yè)務(wù)接口時,在 HTTP Header(如 Idempotent-Token)中攜帶此 Token。
服務(wù)端攔截請求,檢查 Redis 中是否存在該 Token:
- 若存在,則刪除該 Token(
redis.delete(key))并繼續(xù)執(zhí)行業(yè)務(wù)邏輯。 - 若不存在,說明是重復(fù)請求,直接返回重復(fù)操作結(jié)果。
?優(yōu)點?:對業(yè)務(wù)代碼侵入性相對較小,安全性較高,能有效防止重復(fù)提交。
?缺點?:需額外一次獲取 Token 的請求,依賴 Redis 等外部存儲。
?代碼示意 (使用 AOP 簡化)??:
// 1. 自定義冪等注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Idempotent {
long timeout() default 10; // 過期時間,單位分鐘
}
// 2. AOP 實現(xiàn)
@Aspect
@Component
public class IdempotentAspect {
@Autowired
private StringRedisTemplate redisTemplate;
@Around("@annotation(idempotent)")
public Object around(ProceedingJoinPoint joinPoint, Idempotent idempotent) throws Throwable {
HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
String token = request.getHeader("Idempotent-Token");
// ... 校驗 Token 是否為空...
String key = "idempotent:token:" + token;
// 原子性驗證并刪除 Token
Boolean isDeleted = redisTemplate.delete(key);
if (Boolean.FALSE.equals(isDeleted)) {
throw new BusinessException("請求已處理,請勿重復(fù)提交");
}
return joinPoint.proceed();
}
}
// 3. 在控制器方法上使用注解
@PostMapping("/order")
@Idempotent(timeout = 10)
public Result createOrder(@RequestBody OrderRequest request) {
// 業(yè)務(wù)邏輯
}
使用 AOP 可以使業(yè)務(wù)代碼更簡潔。
2. 數(shù)據(jù)庫唯一約束
利用數(shù)據(jù)庫本身的唯一性索引來保證重復(fù)請求不會插入多條記錄。
?實現(xiàn)步驟:
- 在數(shù)據(jù)庫表中為能唯一標識業(yè)務(wù)的字段(如訂單號
order_no、支付流水號transaction_id)創(chuàng)建唯一索引。 - 執(zhí)行業(yè)務(wù)邏輯插入數(shù)據(jù)時,如果重復(fù)插入,數(shù)據(jù)庫會拋出
DataIntegrityViolationException等異常。 - 捕獲該異常,并根據(jù)業(yè)務(wù)需求處理(如查詢已存在的記錄并返回)。
?優(yōu)點?:實現(xiàn)簡單,可靠性高,利用數(shù)據(jù)庫特性,強一致性。
?缺點?:依賴于數(shù)據(jù)庫,高并發(fā)時可能產(chǎn)生較多異常,需合理處理。
?代碼示意?:
@Service
public class PaymentService {
@Autowired
private PaymentRepository paymentRepository;
@Transactional
public PaymentResponse processPayment(PaymentRequest request) {
try {
Payment payment = new Payment();
payment.setOrderNo(request.getOrderNo());
payment.setTransactionId(request.getTransactionId()); // 此字段有唯一索引
payment.setAmount(request.getAmount());
paymentRepository.save(payment);
// ...其他支付邏輯...
return new PaymentResponse(true, "支付成功");
} catch (DataIntegrityViolationException e) {
// 捕獲唯一約束違反異常
Payment existingPayment = paymentRepository.findByTransactionId(request.getTransactionId());
return new PaymentResponse(true, "支付已處理", existingPayment.getId());
}
}
}
通常需要結(jié)合 @Transactional注解保證事務(wù)性。
3. 數(shù)據(jù)庫樂觀鎖
通過數(shù)據(jù)庫的版本號字段實現(xiàn),適用于更新操作。
?實現(xiàn)步驟:
- 在數(shù)據(jù)庫表中增加一個
version字段。 - 更新數(shù)據(jù)時,在 SQL 語句中同時更新版本號并校驗舊版本號:
update table set column = new_value, version = version + 1 where id = #{id} and version = #{oldVersion}。 - 根據(jù)更新返回的影響行數(shù)判斷是否更新成功。如果影響行數(shù)為 0,說明版本號不符或記錄已被更新,可能是重復(fù)請求或數(shù)據(jù)沖突。
?優(yōu)點?:避免使用悲觀鎖的性能開銷,適合讀多寫少的場景。
?缺點?:如果并發(fā)沖突多,失敗次數(shù)會增加。
?代碼示意 (MyBatis-Plus 示例)??:
// 實體類
@Data
public class InventoryItemDO {
private Long id;
private Integer sellableQuantity;
@Version // 樂觀鎖版本號字段注解
private Integer version;
}
// Mapper 接口中使用
public interface InventoryItemMapper extends BaseMapper<InventoryItemDO> {
// MyBatis-Plus 會自動在更新時帶上版本條件
}
// Service 中調(diào)用 updateById 方法時,MyBatis-Plus 會自動處理版本號
4. 分布式鎖
在分布式環(huán)境下,使用分布式鎖(如基于 Redis)確保對同一業(yè)務(wù)鍵的操作是串行的。
?實現(xiàn)步驟:
- 獲取鎖:在執(zhí)行業(yè)務(wù)邏輯前,嘗試獲取一個分布式鎖,鎖的 Key 通常由業(yè)務(wù)標識生成(如
lock:order:1001)。 - 處理業(yè)務(wù):獲取鎖成功后,先檢查是否已處理過(可選,二次校驗),再執(zhí)行業(yè)務(wù)邏輯。
- 釋放鎖:最后釋放分布式鎖。
?優(yōu)點?:適用于分布式和高并發(fā)場景,能有效保證強一致性。
?缺點?:實現(xiàn)相對復(fù)雜,依賴外部分布式鎖服務(wù)(如 Redis),獲取釋放鎖會增加響應(yīng)時間。
?代碼示意 (使用 Redisson)??:
@Service
public class SeckillService {
@Autowired
private RedissonClient redissonClient;
@Autowired
private OrderRepository orderRepository;
public SeckillResponse seckill(SeckillRequest request) {
String lockKey = "lock:seckill:" + request.getGoodsId();
RLock lock = redissonClient.getLock(lockKey);
try {
if (lock.tryLock(3, 10, TimeUnit.SECONDS)) { // 嘗試獲取鎖,等待3秒,鎖持有10秒
// 二次校驗:查詢是否已下單,防止重復(fù)處理
if (orderRepository.existsByUserIdAndGoodsId(request.getUserId(), request.getGoodsId())) {
return SeckillResponse.alreadyOrdered();
}
// 執(zhí)行業(yè)務(wù)邏輯...
return SeckillResponse.success();
} else {
throw new BusinessException("系統(tǒng)繁忙,請稍后再試");
}
} finally {
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
}
}
分布式鎖常與唯一索引等其他冪等方案結(jié)合使用,形成雙重保障。
5. 請求摘要(內(nèi)容指紋)
將請求參數(shù)(如請求體)通過哈希算法(如 MD5、SHA-256)生成一個唯一摘要,以此作為冪等鍵。
?實現(xiàn)步驟:
- 接收到請求后,計算請求參數(shù)的摘要(如對 JSON 請求體計算 MD5)。
- 以該摘要為 Key,嘗試在 Redis 中執(zhí)行
setIfAbsent(SETNX)操作。 - 如果設(shè)置成功,說明是首次請求,執(zhí)行業(yè)務(wù)邏輯。
- 如果設(shè)置失敗(Key 已存在),說明是重復(fù)請求,直接返回之前的處理結(jié)果或錯誤信息。
?優(yōu)點?:客戶端無需額外操作,對用戶透明。
?缺點?:計算摘要有性能損耗,需確保計算摘要的參數(shù)能唯一標識業(yè)務(wù)操作,否則可能誤判。
?代碼示意?:
@PostMapping("/transfer")
public Result transfer(@RequestBody TransferRequest request) {
String idempotentKey = generateIdempotentKey(request); // 根據(jù)請求參數(shù)生成摘要
String redisKey = "idempotent:digest:" + idempotentKey;
// 原子性地設(shè)置鍵值,僅當鍵不存在時
Boolean isFirstRequest = redisTemplate.opsForValue().setIfAbsent(redisKey, "processing", 24, TimeUnit.HOURS);
if (Boolean.FALSE.equals(isFirstRequest)) {
// 重復(fù)請求,可根據(jù)業(yè)務(wù)查詢之前的結(jié)果或直接返回錯誤
return Result.fail("請勿重復(fù)提交");
}
try {
// 執(zhí)行業(yè)務(wù)邏輯...
return Result.success();
} finally {
// 可選:業(yè)務(wù)成功完成后,可以更新Redis中的狀態(tài);若失敗,可刪除鍵允許重試
// redisTemplate.delete(redisKey);
}
}
此方法的關(guān)鍵在于生成冪等鍵的算法要能準確識別重復(fù)請求。
如何選擇冪等方案?
選擇哪種方案取決于你的具體業(yè)務(wù)場景、性能要求和系統(tǒng)架構(gòu):
- ?Token 機制?:非常適合用戶交互相關(guān)的操作,如防止表單重復(fù)提交、訂單重復(fù)創(chuàng)建。需要客戶端配合。
- ?數(shù)據(jù)庫唯一約束/索引?:最適合數(shù)據(jù)插入類的操作,簡單、可靠、成本低。是許多場景的首選。
- ?樂觀鎖?:非常適合數(shù)據(jù)更新類的操作,特別是在并發(fā)更新同一數(shù)據(jù)的場景。
- ?分布式鎖?:適用于分布式環(huán)境下需要強一致性的復(fù)雜業(yè)務(wù)邏輯,或高并發(fā)秒殺場景。要注意性能開銷和死鎖問題。
- ?請求摘要?:適合接口回調(diào)、第三方通知等客戶端不可控,但請求內(nèi)容固定的場景。
注意事項
- ?冪等鍵的生成與傳遞?:冪等鍵(Token、業(yè)務(wù)ID等)需要保證全局唯一性。常見的生成方式有 UUID、雪花算法(Snowflake)等。同時,需要和調(diào)用方約定好傳遞方式,如放在 HTTP Header(如
Idempotency-Key)中。 - ?異常處理與重試?:設(shè)計冪等時要考慮業(yè)務(wù)失敗的情況。例如,在 Token 機制中,如果業(yè)務(wù)執(zhí)行失敗,可能需要歸還 Token? 允許客戶端重試。在請求摘要模式中,也需考慮失敗后是否刪除 Redis 中的鍵。
- ?冪等與并發(fā)的區(qū)別?:冪等主要解決重復(fù)請求問題(可能非并發(fā)),而并發(fā)控制解決同時操作的問題。兩者常結(jié)合使用,例如用分布式鎖處理并發(fā),用唯一索引保證最終冪等。
- ?HTTP 方法的冪等性?:了解 RESTful API 中不同 HTTP 方法的冪等性語義對你設(shè)計接口有幫助(例如,GET、PUT、DELETE 通常是冪等的,而 POST 不是)。
總結(jié)
實現(xiàn)接口冪等性是構(gòu)建健壯分布式系統(tǒng)的關(guān)鍵。你可以根據(jù)實際業(yè)務(wù)場景選擇最合適的方案,很多時候這些方案會組合使用以達到最佳效果。
以上就是SpringBoot項目中實現(xiàn)接口冪等的代碼詳解的詳細內(nèi)容,更多關(guān)于SpringBoot實現(xiàn)接口冪等的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Java Web開發(fā)中過濾器和監(jiān)聽器使用詳解
這篇文章主要為大家詳細介紹了Java中的過濾器Filter和監(jiān)聽器Listener的使用以及二者的區(qū)別,文中的示例代碼講解詳細,需要的可以參考一下2022-10-10
Spring Security單項目權(quán)限設(shè)計過程解析
這篇文章主要介紹了Spring Security單項目權(quán)限設(shè)計過程解析,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習或者工作具有一定的參考學(xué)習價值,需要的朋友可以參考下2019-11-11
關(guān)于Spring源碼深度解析(AOP功能源碼解析)
這篇文章主要介紹了關(guān)于Spring源碼深度解析(AOP功能源碼解析),具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-07-07

