解决方案:如何防止数据重复插入?
目录
- 1.为啥要解决数据重复插入?
- 2.解决方案实战
- 3.可落地小总结
一、为啥要解决数据重复插入?
问题起源,微信小程序抽风 wx.request() 重复请求服务器提交数据。后端服务也很简单,伪代码如下:
class SignLogService {
public void saveSignLog(SignLogDO log) {
// 简单插入做记录
SignLogDAO.insert(log);
}
}
发现数据库会存在重复数据行,提交时间一模一样。但业务需求是不能有多余的 log 出现,这明显是个问题。
问题是,重复请求导致的数据重复插入。这问题造成的后果很明显:
1.数据冗余,可能不单单多一条
2.有些业务需求不能有多余数据,造成服务问题
问题如图所示:
解决方式:如何将 同请求 A,不执行插入,而是读取前一个请求插入的数据并返回。解决后流程应该如下:
二、解决方案实战
1.单库单表解决方案
1.唯一索引 + 唯一字段
2.幂等
上面说的那种业务场景:sign_log 表会有 user_id、sign_id、sign_time 等。那么每次签到,每个人每天只有一条签到记录。
数据库层采取唯一索引的形式,保证数据记录唯一性。即 UNIQUE 约束,UNIQUE 约束唯一标识数据库表中的每条记录。另外,user_id,sign_id,sign_time 三个组合适唯一字段。创表的伪代码如下:
CREATE TABLE sign_log
(
id int NOT NULL,
user_id int NOT NULL,
sign_id int,
sign_time int,
CONSTRAINT unique_sign_log UNIQUE (user_id,sign_id,sign_time)
)
重点是 CONSTRAINT unique_sign_log UNIQUE (user_id,sign_id,sign_time)
。有个小问题,数据量大的时候,每条记录都会有对应的唯一索引,比较耗资源。那么这样就行了吗?
答案是不行,服务不够健壮。第一个请求插入成功,第二个请求直接报错,Java 服务会抛出 DuplicateKeyException
。
简单的幂等写法操作即可,伪代码如下:
class SignLogService {
public SingLogDO saveSignLog(SignLogDO log) {
// 幂等处理
SignLogDO insertLog = null;
try {
insertLog = signLogDAO.insert(log);
} catch (DuplicateKeyException e) {
insertLog = selectByUniqueKeys(userId,signId,signTime);
}
return insertLog;
}
}
的确,流量不是很大,也不算很高并发。重复写问题,这样处理即可。那大流量、高并发场景咋搞
2.分库分表解决方案
流量大了后,单库单表会演变成分库分表。那么基于单表的唯一索引形式,在碰到分表就无法保证呢,插入的地方可能是两个分表 A1 和 A2。
解决思路:将数据的唯一性条件放到其他存储,并进行锁控制
还是上面的例子,每天,每次签到,每个人只有一条签到记录。那么使用分布式锁 Redis 的解决方案。大致伪代码如下:
a.加锁
// 加锁
jedis.set(lockKey, requestId, "NX", "PX", expireTime);
- lockKey 最简单的是 user_id + sign_id + sign_time
- expireTime 设置为一天
b.解锁
// 解锁
jedis.eval(script, lockKey,requestId);
c.幂等代码加强
class SignLogService {
public SingLogDO saveSignLog(SignLogDO log) {
// 幂等校验
SignLogDO existLog = selectByUniqueKeys(userId,signId,signTime);
if(Objects.nonNull(existLog)) {
return existLog;
}
// 加锁
jedis.set
SignLogDO insertLog = signLogDAO.insert(log);
// 解锁
jedis.eval
return insertLog;
}
}
这个方案还是不是很成熟,大家参考下即可。
三、可落地小总结
解决方案实战中,了解具体术。归纳如下:
- 1.幂等:保证多次同意请求后结果一致
- 2.并发控制:单表唯一索引、分布式多表分布式锁
- 3.降级兜底方案:分布式锁锁失效 – 考虑乐观锁兜底

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Redis 在项目中合理使用经验总结
背景1.Redis是一个开源的内存数据结构存储系统。2.可以作为数据库、缓存和消息中间件使用。3.支持多种类型的数据结构。4.Redis 内置了 复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(transactions) 和不同级别的 磁盘持久化(persistence)。5.通过 Redis 哨兵(Sentinel)和 Redis 集群(Cluster)的自动分区,提供高可用性(high availability)。 基本数据类型字符串(strings) 1、string 的过期时间在重新设置值之后会被清除 127.0.0.1:6379> set hello 3OK127.0.0.1:6379> get hello"3"127.0.0.1:6379> ttl hello(integer) -1127.0.0.1:6379> expire hello 3000(integer) 1127.0.0.1:6379> set hello 4OK127.0.0.1:6379> tt...
- 下一篇
Spring Cloud OAuth 实现微服务内部Token传递的源码解析
背景分析 1.客户端携带认证中心发放的token,请求资源服务器A(Spring Security OAuth 发放Token 源码解析) 2.客户端携带令牌直接访问资源服务器,资源服务器通过对token 的校验 (Spring Cloud OAuth2 资源服务器CheckToken 源码解析 ) 判断用户的合法性,并保存到上下文中 3.A服务接口接收到请求,需要通过Feign或者其他RPC框架调用B服务来组装返回数据 本文主要来探讨第三部 A --> B ,token 自定维护的源码实现如何实现token 传递配置OAuth2FeignRequestInterceptor 即可此类是Feign 的拦截器实现 @Bean@ConditionalOnProperty("security.oauth2.client.client-id")public RequestInterceptor oauth2FeignRequestInterceptor(OAuth2ClientContext oAuth2ClientContext, OAuth2ProtectedResourceDeta...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2全家桶,快速入门学习开发网站教程