互联网业务幂等性实现之基于MySQL

背景

在互联网业务领域中,我们经常会遇到应用到请求幂等性问题,即多次重复请求,所得到的结果,和一次请求一致。

以某互联网电商的取消订单为例子,当订单取消,需要返回给消费者下单所消费的虚拟产品,如优惠券、红包、京豆等。通过幂等形式,确保返还给消费者的权益不多、不少。

那幂等性具体开发是怎么实现的呢?本文带来基于MySQL的UNIQUE KEY的实现方案。

实现

众所周知,UNIQUE KEY是数据库中的唯一索引,数据库的记录中不允许有重复的值,我们可以利用这点,在处理业务前,先进行唯一索引数据(如订单id)的插入操作:

  • 插入成功,说明是第一次插入,正常处理业务;
  • 插入失败,说明该业务逻辑已经处理过了,不做处理,提前返回;

如此,即可实现幂等性。

1.数据库设计

幂等性辅助表设计如下:

CREATETABLE `idempotent_validate` (
`id` bigintNOTNULL,
`create_time` time DEFAULT NULL,
`order_id` bigint DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `UK_orssam7fgn4uj0lo2sn4on6vg` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

其中的一个字段order_id,我们定义为唯一索引。

2.代码编写

我们主要实现了订单取消方法cancelOrder:

package com.example.idempotentmysql.service.impl;

import com.example.idempotentmysql.bean.IdempotentValidate;
import com.example.idempotentmysql.bean.OrderInfo;
import com.example.idempotentmysql.bean.ProductInfo;
import com.example.idempotentmysql.bean.UserInfo;
import com.example.idempotentmysql.repository.IdempotentValidateRepository;
import com.example.idempotentmysql.repository.OrderInfoRepository;
import com.example.idempotentmysql.repository.ProductInfoRepository;
import com.example.idempotentmysql.repository.UserInfoRepository;
import com.example.idempotentmysql.service.OrderService;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;

import javax.annotation.Resource;
import java.util.Optional;

/**
* 订单服务
*
* @author hongcunlin
*/
@Service
public class OrderServiceImpl implements OrderService {
/**
* 日志
*/
private static final Logger LOGGER = LoggerFactory.getLogger(OrderServiceImpl.class);

/**
* 用户repository
*/
@Resource
private UserInfoRepository userInfoRepository;

/**
* 商品repository
*/
@Resource
private ProductInfoRepository productInfoRepository;

/**
* 订单repository
*/
@Resource
private OrderInfoRepository orderInfoRepository;

/**
* 幂等性校验
*/
@Resource
private IdempotentValidateRepository idempotentValidateRepository;

/**
* 取消订单(带幂等性校验)
*
* @param orderId 订单id
*/
@Override
public void cancelOrder(Long orderId){
//1.幂等性校验
try {
IdempotentValidate idempotentValidate = new IdempotentValidate();
idempotentValidate.setOrderId(orderId);
idempotentValidateRepository.save(idempotentValidate);
} catch (Exception e){
LOGGER.info("订单退款幂等");
return;
}

//2.退款
Optional<OrderInfo> orderInfoOptional = orderInfoRepository.findById(orderId);
if (orderInfoOptional.isPresent()){
OrderInfo orderInfo = orderInfoOptional.get();
Optional<UserInfo> userInfoOptional = userInfoRepository.findById(orderInfo.getUserId());
Optional<ProductInfo> productInfoOptional = productInfoRepository.findById(orderInfo.getProductId());
if (userInfoOptional.isPresent()&& productInfoOptional.isPresent()){
UserInfo userInfo = userInfoOptional.get();
ProductInfo productInfo = productInfoOptional.get();
userInfo.setMoney(userInfo.getMoney().add(productInfo.getPrice()));
userInfoRepository.save(userInfo);
}
}
LOGGER.info("订单成功退款");
}
}

从代码中可以看到,我们在除了订单退款前,幂等性表先拿订单id进行插入操作,若插入成功,说明是第一次取消订单,执行下面的退款逻辑;

若插入失败,说明之前已经进行过退款逻辑了,我们提前返回,不做下面的退款操作。

如此,便实现了订单退款的幂等性。

3.测试

我们对订单进行3次取消操作:

package com.example.idempotentmysql.service;


import com.example.idempotentmysql.bean.OrderInfo;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;

import javax.annotation.Resource;

@SpringBootTest
public class OrderServiceTest {

@Resource
private OrderService orderService;

@Test
public void cancelOrderTest(){
orderService.cancelOrder(6L);
orderService.cancelOrder(6L);
orderService.cancelOrder(6L);
}
}

可以看到,只有第一次是退款成功的,后面2次触发幂等性,退款失败,符合我们的预期。

其他

幂等性的实现方式还有很多种,基于MySQL的UNIQUE KEY的实现方案,实现起来相当简单,仅适合业务简单,并发量不高的场景。原因是MySQL的qps有限,且MySQL作为系统的最底层的应用,过于后置,如果最终幂等返回,比较浪费前置的业务处理所消耗的资源。

本文代码已经上传到github上了,有需要的同学可以下载参考:https://github.com/larger5/idempotent-mysql

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/229150.html<

(0)
管理的头像管理
上一篇2025-04-18 15:29
下一篇 2025-04-18 15:31

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注