Java并发场景及解决方案

工作中,会遇到很多需要控制并发访问的场景,由于大部分项目是分布式的,常用的ReentrantLock、synchronized代码块就会失效。以下案例皆为实战总结

案例一:签到送积分

需求:同一个活动,同一个用户一天仅可参与一次签到

自己踩过的坑:这个需求是毕业之后所做的第一个需求,当时根本没有控制并发的概念,所以结果可想而知。

当时实现思路是:查询数据库该用户在该活动下的上次签到时间,如果今天已经签到,返回已签状态。那么问题来了,如果接口被频繁调用,用户今天未签到,那么多个线程就有可能查出来同一个签到时间,所以很容易就会出现签到重复的情况。

解决方案:应用数据库联合唯一索引,在数据库层面,将用户id、活动id、日期做唯一索引,这样就很容易达到预期需求。

案例二:参与活动抽幸运号,每100个用户为一期

需求:用户参与活动,得到一个幸运号,幸运号为1-100,幸运号的生成按照顺序依次增加,每100个人为一期活动,有一个期号

分析:首先需要保证用户的幸运号在一期中一定是唯一的,不能有重复现象,另外,需要保证必须为100个一期,不能增加至101等。

解决方案:应用数据库的自增主键,这样很容易实现用户幸运号的唯一,那么是有一个问题,幸运号会一直增加,这个其实不用担心,展示给用户的时候取余就可以了。另外,要保证每100个幸运号为一期,并且有相同的期号,可以在参与的时候给一个默认期号,跑一个定时,当参与记录有100个默认期号的时候进行期号更新,更新最大期号。

案例三:优惠券领取

需求:领取优惠券时,优惠券有限制“每天总领取张数”,“用户总共可领取该优惠券的张数”,必须很好的控制这个数量,保证优惠券发放准确。

分析:优惠券领取之前,肯定得判断优惠券是否已达到总领取张数,该用户是否已达到自身最大可领取张数。如用数据库记录的话,查出来数量的时候有可能其他线程已经进行了更新,容易发超。

解决方案:redis的自增incr是原子性操作,增加之后返回自增之后的值,那么可以将优惠券领取作为key,领取张数作为值,同理,将用户领取作为key,领取张数作为值,每次领取之前进行各自的自增操作,然后进行临界值判断,若超出,则提醒用户,并进行自减操作。

另,因为我们公司的优惠券券号是提前生成好的,所以也会以队列的形式存放在redis里。利用lpop等操作保证券码被唯一使用。

以上是自己在工作中使用到的控制并发采用的方法,总结了一下,主要是以下几点:

1.分布式服务,资源数据存放位置唯一,可在该方面寻求解决方法

数据库的唯一索引、强检验、id自增、乐观锁,redis的原子操作等

2.分布式服务,可通过方案设计将并发访问变成串行访问,很好的避免并发

你可能感兴趣的:(高并发,高可用)