java分布式面试接口如何保证幂等及概念理解

目录
  • 引言
  • 1、幂等的概念
    • 问题分析:
    • 事后问题分析:
    • 关于这个接口的幂等设计
  • 深入分析:
  • 2、工作中常见的幂等设计场景
  • 3、幂等接口常见设计方案
  • 总结

引言

稳定性设计第一篇:这一小节开始讲设计系统稳定性保证的相关设计,谁都不想自己负责的系统三天两头就出故障,也不想周六日跟女票葡萄美酒夜光杯的时候一个电话call去VPN办公,那么你就想办法让你的系统尽量稳定,我们的目标是让系统“无人值守”。

阿里新零售和阿里妈妈,美团,过去我面试这些公司都被问过接口幂等相关问题,接口幂等设计在分布式系统开发中非常常见且很重要,后来我自己做面试官也慢慢意识到幂等的重要性。

一些初学者对幂等这个概念完全不理解,更不知道如何设计,这在工作中很容易给自己惹麻烦,所以一定要会!一定要会!一定要会!

1、幂等的概念

面试官:

幂等的概念你了解吗,你设计的系统里有哪些接口使用到了幂等设计?

问题分析:

幂等的概念首先你肯定理解了,简单通俗易懂,就是无论你是 Http 接口还是 RPC 接口,入参不变的情况下,无论请求多少次,结果都是一样的,请求结果不会因为请求次数不同而改变,没有任务副作用。

答:我参加工作的第一年,在某在线购票(电影票)App的一家公司做后台系统开发,当时我负责积分系统,工作中接到这样一个线上活动需求。业务场景描述:用户每天使用 App 点击签到按钮参加活动,领取相应的积分,每个用户每天只能参加一次签到领积分活动,签到按钮在点击一次后会自设置灰色变为不可点击的状态,这个领积分的接口由我负责开发,提供 API 给客户端同事,上线后出现这样一个bug,当时没有完善的业务监控系统,功能上线后第二天问出于好奇系统里积分最高的人有多少积分,就在后台跑了一个sql,这一好奇,惊奇的发现有的用户积分高达几万分,因为积分除了签到领取外,大多都是消费累计积分,一块钱才能累积一分,我表示怀疑,什么能人看电影能看几万块钱?

带着这个疑问,我查询了他的积分累积记录,发现大部分积分都是靠签到领积分获得的,按照活动规则,一个人一天只能参加一次签到,不可能有这么多积分,而这个用户一天签到几百次,后来经过和前端一同检查bug发现问题所在,原因是签到按钮虽然变灰,但是请求的 url 没有在前端页面隐藏,用户通过技术手段绕过 button 变灰的前端限制重复刷新了接口,重复获得积分。

事后问题分析:

这个bug最大问题还在我这里,因为我的接口没有做幂等设计,正确的逻辑应该是根据系统当前日期做幂等,幂等后无论用户发起多少次请求,最后的结果都是一样的,积分只累加一次。好在这个bug没有被黑产发现,只有几个用户发现损失可控。

因为我缺少设计经验,不懂幂等设计,领导也没提醒我,所以出现这种bug,经历更多和钱相关的系统开发后,我明白一个道理,任何系统设计,都要考虑业务的安全性,内部系统可以为了节省人力,适当简化设计,做到防君子不防小人,假设你的同事都是君子,对C端用户的系统,不光要防君子,还要防小人,风险防范不能全指望风控系统,有时bug可能会来自系统内部,比如用户并没有恶意盗刷之意,只是网络不好,用户等了两秒钟还没加载完就多点了几次签到按钮,我的接口没有做幂等设计,只要收到请求就会多给用户加积分,这个时候能怪用户吗?很显然是开发者的责任。

关于这个接口的幂等设计

我是这样解决的:

积分接口后台根据用户手机号 + userId + 系统当前日期拼接后生成唯一流水号,根据流水号后保存,如果用户重复发起请求,先根据唯一流水号校验在后台做校验,如果流水号存在直接返回上一次请求结果,考虑到并发的情况下,状态判断使用了锁处理。

开发业务监控系统,采用定时任务每天生成系统里 Top100 积分增长最多名单,运营或者术人员每天观察有没有异常。

经过这次bug反思,学习到两点:

理解幂等设计的重要性,凡是和钱相关的功能请谨慎。

监控系统的重要性,这里的监控说的是业务类监控,如果那天我没有好奇系统里谁的积分最高,这个bug会什么时候发现?

面试官: 嚯,有点意思,你还真的是写了个大bug,弄懂了吸取教训就好,可别进了我的项目组后拿我们的系统写这bug。

深入分析:

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,“setTrue()”函数就是一个幂等函数,无论多次执行,其结果都是一样的。更复杂的操作幂等保证是利用唯一交易号(流水号)实现。

—— 百度百科

如果你了解 Restful 风格接口,相信你对 GET / POST / DELETE 几个动词不陌生,在一次面试锤子科技的过程中,面试官问我是否了解 Rest 接口,我balabala回答了这几常用的动词,面试官又问我:那你除了知道 GET 是从服务器获取资源,还有别的理解吗?当时我没答上来,出了公司以后才想起,GET 动作的设计应该是幂等的。同理 DELETE 也是幂等的,如果你设计的接口 GET / DELETE 不是幂等的,那么你可能要重新思考一下了。

2、工作中常见的幂等设计场景

如果你做的功能和钱相关,或者是能还钱的,那么你就要小心了,每一个接口都要先考虑下是否需要幂等设计,下面是两种常见的需求场景。

发券/积分接口,通常通过 orderId userId 做幂等校验。

支付/退款接口,我们不希望用户发起多次支付都收到用户的钱,用户会投诉,还要把钱退还给用户,对系统还是客服人员来说都是无用功,支付系统非常复杂,想做好支付系统,还有很多东西需要学习,要考虑网络延迟,服务异常,订单中心回掉超时等各种不稳定的因素,通常采用前端控制,逻辑层状态的控制,数据层唯一索引的控制,以及分布式锁的控制,在幂等篇不过过多讨论。

3、幂等接口常见设计方案

客户端按钮提交限制,每次提交一个请求时,按钮置为不可用。

后台系统逻辑层处理,生成保存唯一ID(流水号),每次请求先校验流水号是否已经存在,存在则表示重复操作,直接返回上一次操作结果。

token校验机制,客户端请求前先申请token,同一个token只处理一次,无token或者相同token不做处理。

分布式锁,如引入 Redis 分布式锁,防止其他请求重复操作。

请求队列,引入 MQ 排队的方式让请求有序处理,关于异步操作的应用会在后面的章节讲解。

每一种方案都有自己的优缺点,比如客服端按钮提交限制,实现简单,但是不能从根本上解决问题,后台生成唯一ID,判断存在状态必须要保证原子操作,可以采用多种方案组合的方式解决幂等问题,我们的目标是,用最容易维护的方法解决问题。

总结

在过去的工作经历中,我招进来一个工作三年的同事,场景是开发一个退款接口,review代码的时候,我发现退款的功能是做完了,钱确实能退,但是并没有做幂等设计,我俩讨论了下,我说:如果同一个订单被请求了两次退款,那这钱是不是要退两次,这很危险呀?当时这个同事并没有意识到这一点,因为没有相关经验,连概念都不知道,作为一个三年经验的实在不应该,和钱相关的功能一定要慎重,做幂等设计就是为了系统能防君子,也要防小人。

以上就是java分布式面试接口如何保证幂等及概念的详细内容,更多关于java分布式面试接口幂等保证的资料请关注我们其它相关文章!

(0)

相关推荐

  • SpringBoot实现接口幂等性的4种方案

    一.什么是幂等性 幂等是一个数学与计算机学概念,在数学中某一元运算为幂等时,其作用在任一元素两次后会和其作用一次的结果相同. 在计算机中编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同.幂等函数或幂等方法是指可以使用相同参数重复执行,并能获得相同结果的函数.这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变. 二.什么是接口幂等性 在HTTP/1.1中,对幂等性进行了定义.它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外),

  • 浅谈java接口的幂等性及解决方案

    目录 一.什么情况下需要幂等 二.幂等性解决方案 2.1 token机制(令牌) 2.2 各种锁机制 2.3 各种唯一约束 2.4 防重表 2.5 全局请求唯一id 总结 一.什么情况下需要幂等 用户多次点击按钮 用户页面回退再次提交 微服务相互调用,由于网络问题,导致请求失败,feign触发重试机制 二.幂等性解决方案 2.1 token机制(令牌) 在加载页面详情时候,服务器会顺便生成一个token一起返回给前端,服务端同时也在Redis中保存这个token数据,前端并不展示这个token,

  • Java接口幂等性设计原理解析

    在微服务架构下,我们在完成一个订单流程时经常遇到下面的场景: 一个订单创建接口,第一次调用超时了,然后调用方重试了一次 在订单创建时,我们需要去扣减库存,这时接口发生了超时,调用方重试了一次 当这笔订单开始支付,在支付请求发出之后,在服务端发生了扣钱操作,接口响应超时了,调用方重试了一次 一个订单状态更新接口,调用方连续发送了两个消息,一个是已创建,一个是已付款.但是你先接收到已付款,然后又接收到了已创建 在支付完成订单之后,需要发送一条短信,当一台机器接收到短信发送的消息之后,处理较慢.消息中

  • Spring Boot接口幂等插件用法示例解析

    幂等概述 幂等性原本是数学上的概念,即使公式:f(x)=f(f(x)) 能够成立的数学性质.用在编程领域,则意为对同一个系统,使用同样的条件,一次请求和重复的多次请求对系统资源的影响是一致的. 幂等性是分布式系统设计中十分重要的概念,具有这一性质的接口在设计时总是秉持这样的一种理念:调用接口发生异常并且重复尝试时,总是会造成系统所无法承受的损失,所以必须阻止这种现象的发生. 实现幂等的方式很多,目前基于请求令牌机制适用范围较广.其核心思想是为每一次操作生成一个唯一性的凭证,也就是 token.一

  • java分布式面试接口如何保证幂等及概念理解

    目录 引言 1.幂等的概念 问题分析: 事后问题分析: 关于这个接口的幂等设计 深入分析: 2.工作中常见的幂等设计场景 3.幂等接口常见设计方案 总结 引言 稳定性设计第一篇:这一小节开始讲设计系统稳定性保证的相关设计,谁都不想自己负责的系统三天两头就出故障,也不想周六日跟女票葡萄美酒夜光杯的时候一个电话call去VPN办公,那么你就想办法让你的系统尽量稳定,我们的目标是让系统“无人值守”. 阿里新零售和阿里妈妈,美团,过去我面试这些公司都被问过接口幂等相关问题,接口幂等设计在分布式系统开发中

  • java分布式面试降级组件Hystrix的功能特性

    目录 引言 1.面试官:能简单介绍下Hystrix有哪些功能吗? 1.1.fail-fast(快速失败) 1.2.Fallback优雅降级机制 1.3.线程/信号量隔离机制 线程隔离: 信号量隔离: 2.面试官:刚刚说到线程隔离,那实际使用中是否打开超时线程中断开关? 3.面试官:那你是如何估计线程池大小的? 深入分析 Hystrix历史 Hystrix的主要功能特性 HystrixDemo 哪些情况下会触发fallback? 附录:Hystrix策略配置 Sentinel与Hystrixres

  • java分布式面试系统限流最佳实践

    目录 引言 1.面试官: 哪些场景系统使用了限流?为什么要使用限流? 2.面试官: 那你了解哪些常用限流算法? 1.计数器方法: 2.漏斗算法: 3.令牌桶算法: 3.面试官: 那具体这值该如何评估,说到现在我还是不知道限流到底要怎么设置,可以给我一点经验方法吗? 深入分析 使用线程池实现: 借助Guava实现: 总结 引言 前面讲了系统中的降级熔断设计和对 Hystrix 组件的功能了解,关于限流降级还有一个比较重要的知识点就是限流算法. 如果你面试的是电商相关公司,这一块就显得更加重要了,秒

  • java分布式面试CAP分别代表含义分析

    目录 引言 1.面试官,说到CAP定理,那能详细说说CAP分别代表什么吗? 2.面试官:听起来很简单,这只是概念,但是具体是什么意思呢? 举例深入分析 总结 引言 上一节讲面试中被问到分布式系统概念相关的,讲完了分布式系统的概念,优点缺点和 RPC 后,我以为这个问题就到此结束了,没想到成功给自己挖了个坑(微笑脸),关于 CAP,以前只是听说过,并没有详细点整理过,这一次问好好整理了下. CAP 问题已经成了计算机科学中一个研究领域,之前说到分布式系统有哪些优势时讲到三个提升: 1. 系统可用性

  • 分布式面试消息队列解决消息重复保证消息顺序

    目录 引言 1.面试官: 那你有考虑过消息重复问题怎么解决吗? 2.面试官: 在多集群消息架构中,如果消费端要求接收到的消息是有序的,怎么解决消息顺序消费问题? 3.面试官: 那如何做到topic不分区,能举例说明一下吗? 总结 引言 我在<项目中为什么要使用消息队列>中列举了两个使用消息队列的例子. (1)收银系统,确认收款成功,通过MQ通知给物流系统发货. (2)消费积分,用户每消费一笔给用户增加一定积分,京东豆,信用卡积分,2020年如果还没倒闭的电商平台中,可以100%的确定订单系统和

  • Java中Map接口使用以及有关集合的面试知识点汇总

    目录 Map接口 存储特点 常用实现类 创建方法 常用方法 遍历方法 不同实现类的使用 集合面试知识点补充 结语 Map接口 存储特点 以键(key)值(value)对的形式存储 键无序.无下标.元素不可重复 值无序.无下标.元素可以重复 常用实现类 HashMapJDK1.2 底层哈希表实现 线程不安全,效率高 LinkedHashMapJDK1.2 是HashMap的子类,底层哈希表实现 线程不安全,效率高 TreeMapJDK1.2 是SortedMap的实现类,底层红黑树实现 线程不安全

  • 分布式面试分布式锁实现及应用场景

    目录 引言 1.面试官: 你有遇到需要使用分布式锁的场景吗? 事件A: 事件B: 2.面试官: Redis分布式锁实现方法 1.基于Redis的分布式锁 3.面试官: 那解锁操作呢? 使用del命令解锁 3.面试官: 基于ZooKeeper的分布式锁实现原理 额外补充 方法一: 方法二: 总结 引言 锁是开发过程中十分常见的工具,你一定不陌生,悲观锁,乐观锁,排它锁,公平锁,非公平锁等等,很多概念,如果你对java里的锁还不了解,可以参考这一篇:不可不说的Java“锁”事,这一篇写的很全面了,但

  • 详解Java分布式IP限流和防止恶意IP攻击方案

    前言 限流是分布式系统设计中经常提到的概念,在某些要求不严格的场景下,使用Guava RateLimiter就可以满足.但是Guava RateLimiter只能应用于单进程,多进程间协同控制便无能为力.本文介绍一种简单的处理方式,用于分布式环境下接口调用频次管控. 如何防止恶意IP攻击某些暴露的接口呢(比如某些场景下短信验证码服务)?本文介绍一种本地缓存和分布式缓存集成方式判断远程IP是否为恶意调用接口的IP. 分布式IP限流 思路是使用redis incr命令,完成一段时间内接口请求次数的统

  • 详解Java分布式缓存系统中必须解决的四大问题

    目录 缓存穿透 缓存击穿 缓存雪崩 缓存一致性 分布式缓存系统是三高架构中不可或缺的部分,极大地提高了整个项目的并发量.响应速度,但它也带来了新的需要解决的问题,分别是: 缓存穿透.缓存击穿.缓存雪崩和缓存一致性问题. 缓存穿透 第一个比较大的问题就是缓存穿透.这个概念比较好理解,和命中率有关.如果命中率很低,那么压力就会集中在数据库持久层. 假如能找到相关数据,我们就可以把它缓存起来.但问题是,本次请求,在缓存和持久层都没有命中,这种情况就叫缓存的穿透. 举个例子,如上图,在一个登录系统中,有

  • Java分布式服务框架Dubbo介绍

    目录 1.什么是Dubbo? 2.Dubbo核心组件是? 3.Dubbo的工作原理是? 4.介绍一下Dubbo框架分层? 5.Dubbo支持哪些协议? 1.dubbo默认协议: 2.rmi协议: 3.hessian协议: 4.http协议: 5.webservice协议: 6.thrift协议: 7.redis协议: 8.memcached协议: 6.Dubbo核心配置有哪些? 7.Dubbo有哪几种集群容错方案.哪几种负载均衡策略? 8.Dubbo用到哪些设计模式,简要介绍? 9.Dubbo有

随机推荐