高并发情况下数据库数据更新操作失败的重试机制

本文探讨了在项目中使用乐观锁遇到的并发问题,并通过自定义AOP切面和Spring-retry框架实现重试机制,确保数据一致性。重点介绍了如何使用@IsTryAgain注解和方法返回值判断重试条件,以及如何在Spring中配置@Retryable注解进行自动重试。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

正文!!!!!!!!!!!!!!!!!!

在做项目统计公告的浏览量功能时,对数据库采用了version字段,也就是乐观锁来保证数据的一致与正确性。但也导致了新的问题,当A在修改数据库数据的代码执行过程中,此时数据库的这条数据已经被B用户正好修改了,此时A用户在执行update数据时,就无法匹配条件where version = version,这样就导致这条数据无法更新到数据库中去。这就引出了重试机制。

重试机制:顾名思义就是在程序抛出异常或者自己指定的时来时进行重试来进行相应的数据操作。

重试机制实现的方法:

  • 环绕通知的切面AOP
  • spring-retry框架(添加依赖即可)

1.环绕通知的切面实现
①:创建自定义注解

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface IsTryAgain {
}

注解名字随意。
②:创建切面

@Aspect
@Component
public class IsTryAgainAspect {
    private static final Logger logger = LoggerFactory.getLogger(IsTryAgainAspect.class);
    private static final int DEFAULT_MAX_RETRIES = 5;

    private int maxRetries = DEFAULT_MAX_RETRIES;

//    @Order(1)
    @Pointcut("@annotation(IsTryAgain)")
    public void tryAgainPointcut() {

    }

    @Around("tryAgainPointcut()")
    public void doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
        int numAttempts = 0;
        do {
            numAttempts++;
            Integer result = (Integer) pjp.proceed();//获取方法的返回值来判断,可根据实际情况修改类型
            if (result > 0) {
                break;
            }
            //等待一个随机的时间   错峰
            waitForLock();
        } while (numAttempts <= this.maxRetries);
        MethodSignature signature = (MethodSignature)pjp.getSignature();
        Method method = signature.getMethod();
        logger.warn("retry failure, method: [{}]", method.toString());
    }

    public void setMaxRetries(int maxRetries) {
        this.maxRetries = maxRetries;
    }

    //等待随机时间进行重试
    private void waitForLock() {
        Random random = new Random();
        try {
            Thread.sleep(random.nextInt(10) + 1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

贴上全部代码自己研究吧,
重点说下这个,因为有的使用异常来判断是否重试,我这里是获取方法的返回值来判断是否重试,具体可以根据自己的需求来!
在这里插入图片描述
因为我是update语句,返回值只会有0和1,所以可以根据实际情况来判定重试的时机!!!!

③在需要重试的方法上加上注解,一般是加在逻辑service层上
在这里插入图片描述


二.使用框架spring_retry实现

注:这个方法是在网上看到的,具体效果有用与否未实验,有需要自取

①:pom.xml文件添加依赖

<!--retry-->
<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.2.5.RELEASE</version>
</dependency>

② :在需要重试机制的方法上添加注解

/**
 * 测试重试
 *
 * @Retryable的参数说明: •value:抛出指定异常才会重试
 * •include:和value一样,默认为空,当exclude也为空时,默认所以异常
 * •exclude:指定不处理的异常
 * •maxAttempts:最大重试次数,默认3次
 * •backoff:重试等待策略,默认使用@Backoff,@Backoff的value默认为1000L,我们设置为2000L;
 * multiplier(指定延迟倍数)默认为0,表示固定暂停1秒后进行重试
 */
@Retryable(value = RetryException.class, maxAttempts = 3, backoff = @Backoff(delay = 2000L, multiplier = 1))
public BaseResponse testRetry(){
//逻辑关系
};

③:在业务异常处抛出指定异常,建议抛出框架定义的异常RetryException(这种就是指定异常来进行重试时机的判定)

结束!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


<think>好的,用户现在问的是高并发情况下如何保证页面和数据库的一致性。这个问题挺常见的,尤其是在系统设计面试或者实际开发中。我需要先理清楚用户的需求。他们可能是在开发一个高流量的应用,比如电商秒杀或者抢票系统,遇到了数据不一致的问题,想要了解解决方案。 首先,我要回顾一下高并发场景下的常见问题。当大量请求同时访问系统时,数据库可能成为瓶颈,导致响应变慢甚至崩溃。这时候,如果处理不当,页面显示的数据数据库的实际数据可能不一致,比如库存超卖或者余额显示错误。 接下来,我需要考虑用户可能已经知道的知识。他们可能了解基本的数据库事务和锁机制,但可能不清楚在高并发下如何优化。或者他们可能听说过缓存、队列等技术,但不知道如何具体应用。所以回答需要覆盖基础概念,同时深入一些高级策略。 然后,我应该分步骤讲解解决方案。第一步可能是数据库层面的优化,比如使用事务和锁,但也要提到悲观锁和乐观锁的区别,以及它们的适用场景。然后引入缓存,比如Redis,说明缓存和数据库的双写问题,以及如何通过延迟双删或者消息队列来保证一致性。 接下来是引入消息队列,比如Kafka或者RabbitMQ,用来削峰填谷,异步处理请求,这样可以减轻数据库压力,同时通过顺序消费保证一致性。这里需要提到分布式事务,比如TCC或者Saga模式,但也要指出它们的复杂性。 然后,页面静态化和限流降级也是重要的策略。静态化可以减少对后端服务的压力,而限流和降级可以在系统过载时保护核心功能,避免雪崩效应。最后,幂等性设计是为了防止重复请求导致的数据错误,比如使用唯一ID或者Token机制。 还要考虑用户可能的后续问题,比如如何选择具体的方案,或者实际应用中遇到的坑。这时候在回答中给出相关的问题链接会很有帮助,比如分布式事务的实现细节或者缓存更新的策略。 需要注意的是,用户之前的问题是关于消息中间件的区别,现在转向一致性问题,可能需要连接两者,比如消息队列在保证一致性中的作用。同时,回答需要结构清晰,分点说明,每个策略都有原理和实例,让用户容易理解。 最后,要确保语言简洁,避免技术术语过多,但又要准确。可能需要检查是否有遗漏的关键点,比如数据库读写分离、分库分表的影响,或者缓存穿透、雪崩的问题,但这些可能超出当前问题的范围,可以适当提及或留给相关问题部分。</think>在高并发场景下,保障页面展示与数据库数据一致性是系统设计的核心挑战之一。以下是关键策略及技术实现的分步解析: --- ### 一、**核心矛盾分析** - **问题根源**:当海量请求同时触发数据修改(如秒杀、抢购)时,数据库读写竞争激烈,若处理不当会导致: - **超卖**:库存显示为负数 - **脏读**:页面显示未提交的临时数据 - **更新丢失**:多个请求覆盖彼此的结果 --- ### 二、**基础一致性保障方案** #### 1. **数据库层面控制** - **悲观锁**(如 `SELECT ... FOR UPDATE`) ```sql BEGIN; SELECT stock FROM product WHERE id=1 FOR UPDATE; -- 行级锁 UPDATE product SET stock=stock-1 WHERE id=1; COMMIT; ``` *适用场景*:强一致性要求高,但并发性能较低 - **乐观锁**(版本号/CAS机制) ```sql UPDATE product SET stock=stock-1, version=version+1 WHERE id=1 AND version=当前查询到的版本号; ``` *优势*:无锁竞争,适合读多写少场景 #### 2. **缓存层隔离** - **旁路缓存模式**(Cache-Aside): ```mermaid graph LR A[请求] --> B{缓存是否存在?} B -->|是| C[直接返回缓存] B -->|否| D[查数据库] --> E[更新缓存] ``` - **缓存一致性风险**: - 双写不一致(并发更新导致缓存与数据库不同步) - 解决方案:延迟双删(先删缓存→更新数据库→延迟再删缓存) --- ### 三、**高并发进阶方案** #### 1. **队列削峰** - **消息队列异步化**(如 Kafka/RocketMQ) ```mermaid graph LR A[用户请求] --> B[消息队列] B --> C[消费者集群] --> D[数据库] ``` - 关键设计: - 消息顺序消费(保证操作时序) - 失败重试机制(Dead Letter Queue) #### 2. **分布式事务** - **TCC模式**(Try-Confirm-Cancel): - Try阶段:预留资源(如冻结库存) - Confirm阶段:实际扣减(需幂等设计) - Cancel阶段:回滚预留 - **Saga模式**: - 通过补偿事务实现最终一致性(适用于长事务) #### 3. **页面静态化** - **CDN+本地缓存**: - 静态页面展示近似数据(如"库存>10件") - 动态校验通过后才允许下单 #### 4. **限流降级** - **令牌桶算法**: ```python # 伪代码示例 if token_bucket.get_token(): process_request() else: return "系统繁忙,请重试" ``` - **熔断机制**:Hystrix/Sentinel 监控异常阈值 --- ### 四、**实战案例:秒杀系统设计** 1. **前置校验**:用户资格验证(过滤无效请求) 2. **库存预热**:提前将库存加载到 Redis 3. **分段扣减**:Redis Lua脚本原子操作 ```lua -- Redis原子操作示例 if tonumber(redis.call('GET', 'stock')) > 0 then redis.call('DECR', 'stock') return 1 -- 成功 else return 0 -- 失败 end ``` 4. **异步落库**:通过MQ通知数据库最终扣减 --- ### 五、**监控与兜底** - **数据校对系统**:定期对比缓存与数据库差异 - **补偿机制**:自动修复异常数据(如超卖后的退款) - **报警触发**:Prometheus监控关键指标(如库存波动异常) --- ### 六、**技术选型建议** | 场景特征 | 推荐方案 | |------------------------|------------------------------| | 超高并发(10万+QPS) | Redis+MQ+限流 | | 强事务要求(金融场景) | 数据库行锁+TCC分布式事务 | | 读多写少(资讯类) | 多级缓存+最终一致性 | --- **相关延伸问题**: 1. [如何设计可靠的分布式事务补偿机制?](https://example.com) 2. [Redis与数据库双写不一致的终极解决方案是什么?](https://example.com) 3. [如何通过熔断降级保护数据库不被压垮?](https://example.com)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值