需求: 我们先举个某系统验证的列子:(A渠道系统,业务B系统,外部厂商C系统)(1)B业务系统调用A渠道系统,验证传入的手机.身份证.姓名三要素是否一致.(2)A渠道系统再调用外部厂商C系统.(3)A渠道系统将结果返回给B业务系统. 这3个过程中,(2)过程,调用外部厂商是需要计费的.当B业务系统并发量很高时,有100笔相同的三要素校验,由于是相同的三要素,A渠道只要调用一次厂商即可知道结果.为了防止在某一请求还没响应结束的同时,其他请求也去调用外部系统,这个时候就需要加锁处理 分布式锁的特点

@Slf4j @Component public class RedisLock { public static final int LOCK_EXPIRE = 5000; @Autowired private StringRedisTemplate redisTemplate; /** * 分布式锁 * * @param key key值 * @return 是否获取到 */ public boolean lock(String key) { String lock = key; try {

如何用消息系统避免分布式事务? - 少年阿宾 - BlogJavahttp://www.blogjava.net/stevenjohn/archive/2018/01/04/433004.html [请求去重]java基于分布式锁解决重复请求问题 - qq_41793222的博客 - CSDN博客https://blog.csdn.net/qq_41793222/article/details/83063370 利用Redisson实现分布式锁,并防止重复提交 - 前往JAVA架构的路上 - C

防止重复提交,主要是使用锁的形式来处理,如果是单机部署,可以使用本地缓存锁(Guava)即可,如果是分布式部署,则需要使用分布式锁(可以使用zk分布式锁或者redis分布式锁),本文的分布式锁以redis分布式锁为例. 一.本地锁(Guava) 1.导入依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</arti

前言 在平时的开发中我们都需要处理重复提交的问题,避免业务出错或者产生脏数据,虽然可以通过前端控制但这并不是可以完全避免,最好的方式还是前后端均进行控制,这样的话就可以更有效,尽可能全面的去减少错误的发生. 一.比如我们注册的时候需要发送验证码 如果用户频繁点击或者恶意攻击的话就会造成不断的请求对服务器产生很大的压力,为了避免这种情况我们需要做处理,传统的模式中是在数据库中记录手机号.验证码已经发送时间,再次请求的时候呢去数据库查询是否有该手机号记录,并校验是否超过间隔时间,如果超过则重新发送并

一 问题背景 我们做的是医疗信息化系统,在系统中一条患者信息对医院中当前科室中的所有诊断医生是可见的,当有一个诊断医生点击按钮处理该数据时,数据的状态发生了变化,其他的医生就不可以再处理此患者的数据了.我们开始的做法是,在医生点击按钮时先去后台数据库获取当前数据状态,根据状态判断数据是否可以操作,如果可以操作,则修改数据状态,进行业务逻辑处理,否则提示数据已被其他人处理,不能处理. 二 问题分析 按照上边的业务逻辑,我们画个图分析,如下图 在上图中,如果用户A和B同时向数据库发起请求获取数据状态

使用redis防止重复提交   其实主要思路是他的https://blog.csdn.net/u013378306/article/details/52944780 主要目前我的情况是,前后端分离的,前端没有session ,所以使用redis来存放数据. 自定义注解 package com.cdp.api.onboarding.interceptor; import java.lang.annotation.ElementType; import java.lang.annotation.Re

前几天,公司数据库出现了两条相同的数据,而且时间相同(毫秒也相同).排查原因,发现是网络波动造成了重复提交. 由于网络波动而重复提交的例子也比较多: 网络上,防重复提交的方法也很多,使用redis锁,代码层面使用lock. 但是,我没有发现一个符合我心意的解决方案.因为网上的解决方案,第一次提交返回成功,第二次提交返回失败.由于两次返回信息不一致,一次成功一次失败,我们不确定客户端是以哪个返回信息为准,虽然我们希望客户端以第一次返回成功的信息为准,但客户端也可能以第二次失败信息运行,这是一个不确

Java技术栈 www.javastack.cn 优秀的Java技术公众号 在传统的web项目中,防止重复提交,通常做法是:后端生成一个唯一的提交令牌(uuid),并存储在服务端.页面提交请求携带这个提交令牌,后端验证并在第一次验证后删除该令牌,保证提交请求的唯一性. 上述的思路其实没有问题的,但是需要前后端都稍加改动,如果在业务开发完在加这个的话,改动量未免有些大了,本节的实现方案无需前端配合,纯后端处理. 思路 1.自定义注解 @NoRepeatSubmit 标记所有Controller中的

有没有遇到过这种情况:网页响应很慢,提交一次表单后发现没反应,然后你就疯狂点击提交按钮(12306就经常被这样怒怼),如果做过防重复提交还好,否则那是什么级别的灾难就不好说了... 本文主要是应用 自定义注解. spring AOP.· Guava Cache 生成一种本地锁,来达到的防重复提交效果,由于是基于内存的缓存,所以这种实现方式并不适用于分布式服务 Guava是什么? guava包是google嫌弃JAVA自带的类库不好用,自行研发的一套工具包,对JDK工具做了很好的拓展.例如:并发[

大型互联网项目中,很多流量都达到亿级.同一时间很多的人在使用,而每个用户提交表单的时候都可能会出现重复点击的情况,此时如果不做好控制,那么系统将会产生很多的数据重复的问题.怎样去设计一个高可用的防重复提交方案呢?博主将在此为大家详细分享当前自己负责的一个亿级流量项目中如何实现防重复提交. 首先,博主在介绍之前,先介绍下这个亿级项目的故事.博主在16年入驻公司后,进入了该项目组,此时项目面对大流量访问的情况可谓非常糟.客户天天跟公司搞事情,不信任团队.具体问题争论点如下: 1.用户在提交数据后,很

前言   项目中经常会出现重复提交的问题,而接口幂等性也一直以来是做任何项目都要关注的疑难点,网上可以查到非常多的方案,我归纳了几点如下:   1).数据库层面,对责任字段设置唯一索引,这是最直接有效的方式,不好的地方就是一旦触发就会在服务端抛数据库相关异常:   2).代码层面,增加业务逻辑判断,先查询一遍若没有才插入,这也是最容易想到的方式,反正写上就对了,不好的地方就是分布式场景下依然避免不了问题:   3).前端层面,对于触发事件的操作比如按钮等,最好点击过后都设置几秒的置灰时间,能很大

当前很多网站是前后分离的,前端(android,iso,h5)通过restful API 调用 后端服务器,这就存在一个问题,对于创建操作,比如购买某个商品,如果由于某种原因,手抖,控件bug,网络错误,可能导致一次操作实际上购买了多次同一个产品.所以,我们要考虑防止重复提交.这个重复提交我们只限定于创建操作,对于修改和删除操作,原则上是幂等的,不用担心,查询操作更不用担心重复操作. 方案一,前端在提交时候生成一个基于时间的sequence,将这个参数传到后端,后端根据uriPath+userI

重复提交的几种情况1.利用JavaScript防止表单重复提交 按钮禁用2.利用Session令牌防止表单重复提交 具体的做法:在服务器端生成一个唯一的随机标识号,专业术语称为Token(令牌),同时在当前用户的Session域中保存这个Token.然后将Token发送到客户端的Form表单中,在Form表单中使用隐藏域来存储这个Token,表单提交的时候连同这个Token一起提交到服务器端,然后在服务器端判断客户端提交上来的Token与服务器端生成的Token是否一致,如果不一致,那就是重复提

背景: 最近参与开发的小程序,涉及到即时消息(IM)发送的功能: 聊天界面如下,通过键盘上的[发送]按钮,触发消息发送功能 问题发现: 功能开发完毕,进入测试流程:测试工程师反馈说: 在Android手机上,在极短的时间内频繁点击键盘上的[发送]按钮,消息会重复发送:IOS上该问题不太明显 本以为是普通的防重复提交问题,于是自然想到通过设定flag/js加锁的方式解决该问题,于是开始优化代码: 项目基本代码: wxml: <input type="text" value=&quo

这是why技术的第38篇原创文章 又到了一周一次的分享时间啦,老规矩,还是先荒腔走板的聊聊生活. 有上面的图是读大学的时候,一次自行车骑行途中队友抓拍的我的照片.拍照的地方,名字叫做牛背山,一个名字很 low,实际很美的地方. 那条上山的路很难骑,超级烂路和极度变态的陡坡.真是一种折磨,是对意志力的完全考验. 在我们几近崩溃,弹尽粮绝,离山顶还有近两个多小时的时候,一个卡车司机主动要求把我们免费带到山顶.我们拒绝了. 因为同行的星哥他说了一句话:“骑行牛背山这件事情,我这辈子只会做这一次.现在的

Redis 6.0在5.2号这个美好的日子里悄无声息的发布了,这次发布在IT圈犹如一颗惊雷一般,因为这是redis最大的一次改版,首次加入了多线程. 作者Antirez在RC1版本发布时在他的博客写下: the most “enterprise” Redis version to date // 最”企业级”的 the largest release of Redis ever as far as I can tell // 最大的 the one where the biggest amoun

什么是表单重复提交 表单的重复提交: 若刷新表单页面, 再提交表单不算重复提交. 在不刷新表单页面的前提下: 多次点击提交按钮 已经提交成功, 按 "回退" 之后, 再点击 "提交按钮". 在控制器响应页面的形式为转发情况下,若已经提交成功, 然后点击 "刷新(F5)" 重复提交的缺点: 加重了服务器的负担 可能导致错误操作. token(令牌) 用户在访问页面时,我们要生成一个随机的token值 将该值放入到session域中,同时放在表单隐藏

1.并发访问限制问题 对于一些需要限制同一个用户并发访问的场景,如果用户并发请求多次,而服务器处理没有加锁限制,用户则可以多次请求成功. 例如换领优惠券,如果用户同一时间并发提交换领码,在没有加锁限制的情况下,用户则可以使用同一个换领码同时兑换到多张优惠券. 伪代码如下: if A(可以换领)         B(执行换领)              C(更新为已换领)             D(结束) 如果用户并发提交换领码,都能通过可以换领(A)的判断,因为必须有一个执行换领(B)后,才会

原理:在新建页面中Session保存token随机码,当保存时验证,通过后删除,当再次点击保存时由于服务器端的Session中已经不存在了,所有无法验证通过. 注,如果是集群的方式,则需要将token放入到缓存中即可. 注解Token代码:java源码  Java代码 复制代码 收藏代码 .@Target(ElementType.METHOD) .@Retention (RetentionPolicy.RUNTIME) .public @interface Token { . . boolean

1.并发访问限制问题 对于一些需要限制同一个用户并发访问的场景,如果用户并发请求多次,而服务器处理没有加锁限制,用户则可以多次请求成功. 例如换领优惠券,如果用户同一时间并发提交换领码,在没有加锁限制的情况下,用户则可以使用同一个换领码同时兑换到多张优惠券. 伪代码如下: if A(可以换领) B(执行换领) C(更新为已换领) D(结束) 如果用户并发提交换领码,都能通过可以换领(A)的判断,因为必须有一个执行换领(B)后,才会更新为已换领(C).因此如果用户在有一个更新为已换领之前,有多少次