并发问题解决方案

案例原型:对同一商品的库存修改工作

<1>不能通过先查再去修改的方案,通过原生sql进行操作

<2>使用触发器

<3>使用hibernate悲观锁,在查询商品的时候即加锁

<4>使用hibernate乐观锁:在实体类添加version进行版本控制,如果事务操作失败,可提示用户,由用户去决定解决方案;

也可以捕获异常,进行重试机制.具体根据实际的业务需求

案例原型:生成交易单时,交易单号的生成,(查询最大值加1)

<1>同上

<2>同上

<3>使用hibernate悲观锁:

新增一个表temp,存取当前订单号的最大值,每次新增交易单的时候,去temp表去查询,temp表的这条数据进行加锁,不允许任何其他事物

再操作temp.插入交易单后,再去修改temp表中的最大值.为了保证长事物由于锁对性能的影响,尽量在事务方法的末尾去temp表查询和

修改操作

总结:对读操作比较高的,建议使用乐观锁;

对写操作和数据安全比较高的,建议使用悲观锁

时间: 2024-09-30 09:50:24

并发问题解决方案的相关文章

大数据和高并发的解决方案汇总

大数据和高并发的解决方案汇总 1.3海量数据解决方案 1.使用缓存: 使用方式:1,使用程序直接保存到内存中.主要使用Map,尤其ConcurrentHashMap. 2,使用缓存框架.常用的框架:Ehcache,Memcache,Redis等. 最关键的问题是:什么时候创建缓存,以及其失效机制. 对于空数据的缓冲:最好用一个特定的类型值来保存,以区别空数据和未缓存的两种状态. 2.数据库优化: 1,表结构优化. 2,SQL语句优化,语法优化和处理逻辑优化.可记录各语句执行时间,有针对性的分析.

Atitit.并发测试解决方案(2) -----获取随机数据库记录 随机抽取数据 随机排序 原理and实现

Atitit.并发测试解决方案(2) -----获取随机数据库记录 随机抽取数据 随机排序 1. 应用场景 1 2. 随机抽取数据原理 1 3. 常用的实现方法:::数据库随机函数 1 4. Mssql 的实现 NEWID() 跟rand()  1 5. newid()与rand()的区别 2 6. NEWID() 2 7. 参考 2 1. 应用场景 并发测试 2. 随机抽取数据原理 原理是 循环所有的ID/记录,附加随机函数字段,然后排序as 这个字段.. 3. 常用的实现方法:::数据库随机

PHP中大数据和高并发的解决方案汇总

大数据和高并发的解决方案汇总 1.3海量数据解决方案 1.使用缓存: 使用方式:1,使用程序直接保存到内存中.主要使用Map,尤其ConcurrentHashMap. 2,使用缓存框架.常用的框架:Ehcache,Memcache,Redis等. 最关键的问题是:什么时候创建缓存,以及其失效机制. 对于空数据的缓冲:最好用一个特定的类型值来保存,以区别空数据和未缓存的两种状态. 2.数据库优化: 1,表结构优化. 2,SQL语句优化,语法优化和处理逻辑优化.可记录各语句执行时间,有针对性的分析.

转载:【高并发简单解决方案 | 靠谱崔小拽 】redis队列缓存 + mysql 批量入库 + php离线整合

需求背景:有个调用统计日志存储和统计需求,要求存储到mysql中:存储数据高峰能达到日均千万,瓶颈在于直接入库并发太高,可能会把mysql干垮. 问题分析 思考:应用网站架构的衍化过程中,应用最新的框架和工具技术固然是最优选择:但是,如果能在现有的框架的基础上提出简单可依赖的解决方案,未尝不是一种提升自我的尝试. 解决: 问题一:要求日志最好入库:但是,直接入库mysql确实扛不住,批量入库没有问题,done.[批量入库和直接入库性能差异参考文章] 问题二:批量入库就需要有高并发的消息队列,决定

海量数据和高并发的解决方案

海量数据的解决方案 缓存和页面静态化 缓存可以使用map(ConcurrentHashMap)直接保存在内存中,或者使用缓存框架Ehcache,Memcache,Redis等.缓存最重要的是缓存的创建时间和失效机制.缓存应该把空值定义一个类型,防止查到空的缓存后频繁查找数据库查找值,缓存适用于实时性要求不高且不频繁变化的数据 页面静态化,将程序最后生成的页面保存起来,可以使用模板技术freemaker,velocity生成静态页面,也可以使用缓存服务器squid和nginx等 数据库优化 表结构

高并发简单解决方案————redis队列缓存+mysql 批量入库

问题分析 思考:应用网站架构的衍化过程中,应用最新的框架和工具技术固然是最优选择:但是,如果能在现有的框架的基础上提出简单可依赖的解决方案,未尝不是一种提升自我的尝试. 解决: 问题一:要求日志最好入库:但是,直接入库mysql确实扛不住,批量入库没有问题,done.[批量入库和直接入库性能差异] 问题二:批量入库就需要有高并发的消息队列,决定采用redis list 仿真实现,而且方便回滚. 问题三:日志量毕竟大,保存最近30条足矣,决定用php写个离线统计和清理脚本. done,下面是小拽的

redis下并发问题解决方案

最近做的功能需求中,使用了redis作为数据库,上线之后个别玩家出现了莫名其妙的错误,该插入的数据没有插入,莫名其妙丢失了.最后通过分析用户的错误数据才想明白原来是并发问题导致的.第一次接触并发是在看操作系统原理的时候,之后再看数据库原理的时候也看到过并发,对与并发的原理还是比较清楚的,只是一直没遇到过.这次在用reids的过程中算是踩坑了. 现在的计算机大都是多核的cpu,意味着可以并行执行多个进程.如果这多个运行的进程对同一份数据进行读写操作,那么就有可能出现两个或者多个进程读到的都是老的数

【高并发简单解决方案】redis队列缓存 + mysql 批量入库 + php离线整合

原文地址 :https://segmentfault.com/a/1190000004136250需求背景:有个调用统计日志存储和统计需求,要求存储到mysql中:存储数据高峰能达到日均千万,瓶颈在于直接入库并发太高,可能会把mysql干垮. 问题分析 思考:应用网站架构的衍化过程中,应用最新的框架和工具技术固然是最优选择:但是,如果能在现有的框架的基础上提出简单可依赖的解决方案,未尝不是一种提升自我的尝试. 解决: 问题一:要求日志最好入库:但是,直接入库mysql确实扛不住,批量入库没有问题

高并发请求解决方案

使用场景:某平台用户搜索(search)-选择商品-下单: 本公司角色:二级代理商(在香港外包公司取得数据=美国总部一致对外公布的商品信息+香港一级代理商佣金) 业务处理流程:平台(多个)用户请求-公司请求-外包(美国+一级代理商)结果-公司处理-平台 业务流程中主要是针对用户搜索(search)带来的高并发处理进行一个记录. 解决方案: LVS+Mencache(独立一台服务器 配置32g内存,liunx) LVS分发到四台“服务器”(主要是服务器没有购买下来,用普通的4G内存台式电脑替换):

quartz集群分布式(并发)部署解决方案-Spring

项目中使用分布式并发部署定时任务,多台跨JVM,按照常理逻辑每个JVM的定时任务会各自运行,这样就会存在问题,多台分布式JVM机器的应用服务同时干活,一个是加重服务负担,另外一个是存在严重的逻辑问题,比如需要回滚的数据,就回滚了多次,刚好quartz提供很好的解决方案. 集群分布式并发环境中使用QUARTZ定时任务调度,会在各个节点会上报任务,存到数据库中,执行时会从数据库中取出触发器来执行,如果触发器的名称和执行时间相同,则只有一个节点去执行此任务. 如果此节点执行失败,则此任务则会被分派到另