114 接口中幂等性的保证

这篇具有很好参考价值的文章主要介绍了114 接口中幂等性的保证。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

同样是 面试问题 

如何确保接口的 幂等性 

幂等是一个 较为抽象的概念, 多次重复访问, 不会导致业务逻辑的异常 

114 接口中幂等性的保证,05 问题,java,web,deopt

这里从增删改查, 几个方面列一下 

一般来说, 我们核心需要关注的就是 新增 和 更新

对于 增加元素, 首先针对唯一约束进行校验, 然后再处理新增的相关业务, 严格一点需要 加锁, 分布式并发控制 

对于 删除元素, 就是检查元素存不存在, 存在 则删除, 不存在 返回相关状态吗, 或者直接成功都 OK

元素的新增

基于持久化的数据库的机制

比如 mysql 这边目标表, 增加唯一索引, 或者 主键

比如, 我们这里 限定在 用户表 中 用户名 不能重复, 这个只有特定的业务场景中可以这么处理 

CREATE TABLE `auth_user` (
  `id` int(11) NOT NULL,
  `name` varchar(256) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `name` (`name`) USING BTREE COMMENT 'name'
) ENGINE=InnoDB DEFAULT CHARSET=utf8

然后 服务器这边 就不用做 过多的控制, 核心业务部分直接 ”insert into” 都可以 

由 mysql 这边本身的机制 来确保 用户名 的不能重复, 防止 用户多次提交 造成的业务问题

分布式并发过滤控制 + 数据库的悲观锁

我们这里展现一下 完整的处理流程, 主要是包含了 外层的并发过滤控制, 数据库校验控制, 数据库加锁+插入 控制

这里分布式并发控制这里模拟实现, 是 userRunningStore 部分

1. 并发过滤控制这边处理如下, 基于 spring 的 注解 + aop

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

}

并发过滤控制的处理如下

@Component
@Aspect
public class ConcurrentLatchAop {

    @Pointcut("@annotation(ConcurrentLatch)")
    public void concurrentLatchAop() {

    }

    Set<String> userRunningStore = new LinkedHashSet<>();

    @Around("concurrentLatchAop()")
    public Object doProcess(ProceedingJoinPoint point) throws Throwable {
        Object[] args = point.getArgs();
        AuthUser user = (AuthUser) args[0];

        String name = user.getName();
        // lock
        if (userRunningStore.contains(name)) {
            throw new RuntimeException(String.format("有其他用户在新增用户 %s, 请刷新后重试", name));
        }
        userRunningStore.add(name);
        // unlock

        Object result = point.proceed();
        return result;
    }

}

数据库校验控制, 数据库加锁+插入控制 如下 

@PutMapping("/user")
@ConcurrentLatch
public AuthUser add(AuthUser user) {
    // physic verify
    if (user.getAge() > 0 && user.getAge() < 111) {
        throw new RuntimeException("用户的 age 必须在合法的区间");
    }
    // logistic verify
    Map<String, Object> existsUser = JdbcTemplateUtils.queryOne(jdbcTemplate, String.format(" select * from auth_user where name = '%s'; ", user.getName()));
    if (existsUser != null) {
        throw new RuntimeException("该用户已经存在, 用户名称不能重复");
    }

    // do other biz

    // lock then insert
    existsUser = JdbcTemplateUtils.queryOne(jdbcTemplate, String.format(" select * from auth_user where name = '%s' for update; ", user.getName()));
    if (existsUser != null) {
        throw new RuntimeException("该用户已经存在, 用户名称不能重复");
    }
    jdbcTemplate.execute(String.format("INSERT INTO `auth_user`(`name`, `age`) VALUES ('%s', %s);", user.getName(), user.getAge()));
    return user;
}

token分布式并发控制 + 数据库的悲观锁

这个就主要是 整体的交互机制调整, 增加了一层 token 的获取 和 验证

token 的分派这边如下, 做限流, 生成 token 的相关处理 

public static Map<String, AtomicInteger> interf2Counter = new LinkedHashMap<>();
public static Set<String> tokenStore = new LinkedHashSet<>();

// pre install all interfs
static {
    interf2Counter.put("IdempotentController.add", new AtomicInteger());
}

@GetMapping("/requestToken")
public String requestToken(String interf) {
    AtomicInteger counter = interf2Counter.get(interf);
    int incred = counter.getAndIncrement();
    // rate limit
    if (incred > 20) {
        counter.getAndDecrement();
        throw new RuntimeException(" 服务器繁忙, 请稍后重试 ");
    }

    String token = UUID.randomUUID().toString();
    String compositeToken = interf + token;
    tokenStore.add(compositeToken);
    return token;
}

并发控制这边处理如下 

/**
 * ConcurrentLatchAop
 *
 * @author Jerry.X.He
 * @version 1.0
 * @date 2023/9/21 10:17
 */
@Component
@Aspect
public class ConcurrentLatchAop {

    @Pointcut("@annotation(ConcurrentLatch)")
    public void concurrentLatchAop() {

    }

    @Around("concurrentLatchAop()")
    public Object doProcess(ProceedingJoinPoint point) throws Throwable {
        Object[] args = point.getArgs();
        String interf = "get interf from request";
        String token = "get token from request";

        // lock
        if (!IdempotentController.tokenStore.contains(token)) {
            throw new RuntimeException("服务器异常, 请刷新后重试");
        }
        IdempotentController.tokenStore.remove(token);
        // unlock

        Object result = point.proceed();
        AtomicInteger counter = IdempotentController.interf2Counter.get(interf);
        counter.getAndDecrement();
        return result;
    }

}

元素的更新

以上 三种处理方式 在元素的更新中同样可以使用

元素的更新 数据库的更新控制这边可以使用 基于数据库的乐观锁 

数据库的乐观锁更新

并发控制这边 和上面类似, 我们这里着重关注 数据库的更新这边 

数据库的更新这边, 主要是增加一个版本号的字段, 然后 更新的时候 在原有的 id 条件之外, 再增加一个 version 控制的字段 

根据 mysql 这边更新, 会增加行排他锁, 具体的处理如下 

/**
 * IdempotentController
 *
 * @author Jerry.X.He
 * @version 1.0
 * @date 2023/9/21 9:58
 */
@RestController
@RequestMapping("/idempotent")
public class IdempotentController {

    @Resource
    private JdbcTemplate jdbcTemplate;

    @PostMapping("/user")
    @ConcurrentLatch
    public AuthUser update(AuthUser user) {
        // physic verify
        if (user.getAge() > 0 && user.getAge() < 111) {
            throw new RuntimeException("用户的 age 必须在合法的区间");
        }
        // logistic verify
        Map<String, Object> existsUser = JdbcTemplateUtils.queryOne(jdbcTemplate, String.format(" select * from auth_user where name = '%s'; ", user.getName()));
        if (existsUser == null) {
            throw new RuntimeException("该用户不存在, 请确认输入");
        }

        // do other biz

        // lock then insert
        String id = String.valueOf(existsUser.get("id"));
        String version = String.valueOf(existsUser.get("version"));
        int updatedCount = jdbcTemplate.update(String.format("update auth_user set name = '%s', age = %s where id = %s and version = %s;", user.getName(), user.getAge(), id, version));
        if (updatedCount == 0) {
            throw new RuntimeException("该用户信息已经发生改变, 请刷新后重试");
        }
        return user;
    }

}

文章来源地址https://www.toymoban.com/news/detail-855988.html

到了这里,关于114 接口中幂等性的保证的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • kafka中幂等性producer和事务性producer

    在Kafka中,“幂等性生产者”的概念是指一种特性,它确保消息在生产者的发送操作被重试时仅发送一次。幂等性是一种重要的特性,因为在分布式系统中,网络问题或其他故障可能导致生产者发送的消息在传输过程中失败,从而需要重新发送。如果生产者没有幂等性保证,

    2024年02月14日
    浏览(42)
  • 谷粒商城笔记+踩坑(20)——订单确认页。feign、异步请求头丢失问题+令牌保证幂等性

    导航: 谷粒商城笔记+踩坑汇总篇 目录 1、订单确认页 1.1、vo类抽取 1.2、获取订单详情页数据,完整代码 1.2.1、Controller编写跳转订单确认页方法 1.2.2、Service获取订单详情页数据 1.3、【会员模块】获取会员所有收货地址 1.3.1、controller 1.3.2、service  1.4、订单服务远程调用用户

    2023年04月09日
    浏览(77)
  • Java接口幂等性,如何重试?

    当我们写好一个项目时,有没有深深的思考过,如何处理接口幂等性问题呢?今天我们以屈原这句著名诗句“路漫漫其修远兮,吾将上下而求索”的精神来探索一下这个问题。 幂等性:简单来说就是一个操作多次执行的结果和一次执行产生的结果一致。 答:在计算机应用中

    2024年02月10日
    浏览(52)
  • 【Spring Cloud系列】- 分布式系统中实现幂等性的几种方式

    在开发订单系统时,我们常遇见支付问题,既用户购买商品后支付,支付扣款成功,但是返回结果的时候网络异常,此时钱已经扣了,用户再次点击按钮,此时会进行第二次扣款,返回结果成功,用户查询余额发现多扣钱了,流水记录也变成了两条。在以前的单应用系统中,

    2024年02月10日
    浏览(43)
  • RabbitMQ如何保证幂等性

    一、简介 幂等性是分布式中比较重要的一个概念,是指在多作业操作时候避免造成重复影响,其实就是保证同一个消息不被消费者重复消费两次,但是可能存在网络波动等问题,生产者无法接受消费者发送的ack信息,因此这条消息将会被重复发送给其他消费者进行消费,实际

    2024年02月15日
    浏览(41)
  • 如何保证用户重试操作的幂等性

    服务不稳定是一类常态,面对此类场景恰当的应对策略应该是什么?退一步说,即使我们能够确保第一方服务的稳定性,我们又应该如何面对网络延迟以及掌控以外的不确定性?这都是本篇文章会谈到的内容 本文是团队内部分享的文字版,敏感信息已经抹去或者重写。我们通

    2024年02月06日
    浏览(42)
  • 如何保证分布式情况下的幂等性

    关于这个分布式服务的幂等性,这是在使用分布式服务的时候会经常遇到的问题,比如,重复提交的问题。而幂等性,就是为了解决问题存在的一个概念了。 什么是幂等 幂等(idempotent、idempotence)是⼀个数学与计算机学概念,常⻅于抽象代数中。 在编程中⼀个幂等操作的特

    2024年02月07日
    浏览(49)
  • 【微信小程序】Java实现微信支付(小程序支付JSAPI-V3)java-sdk工具包(包含支付出现的多次回调的问题解析,接口幂等性)

          对于一个没有写过支付的小白,打开微信支付官方文档时彻底懵逼 ,因为 微信支付文档太过详细, 导致我无从下手,所以写此文章,帮助第一次写支付的小伙伴梳理一下。 一、流程分为三个接口:(这是前言,先看一遍,保持印象,方便理解代码) 1、第一个接口:

    2024年01月16日
    浏览(74)
  • RabbitMQ防止消息重复消费、保证异步消息的幂等性

    一、rabbitmq出现消息重复的场景 1、消费成功,没有进行ack,这时 Broker 会重新发送 2、不确认(unack)或 reject 之后,重新排队,Broker 会重新发送 3、消费成功,ack时宕机,没有ack成功,消息由unack变为ready,Broker又重新发送 4、总的来说就是 Broker 发送消息后,消费端收到消息

    2024年02月13日
    浏览(41)
  • kafka-保证数据不重复-生产者开启幂等性和事务的作用?

    适用于消息在写入到服务器日志后,由于网络故障,生产者没有及时收到服务端的 ACK 消息,生产者误以为消息没有持久化到服务端,导致生产者重复发送该消息,造成了消息的重复现象,而幂等性就是为了解决该问题。 通过3个值的唯一性去重: PID:生产者ID 分区号 seq:单

    2024年02月14日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包