分类：项目 - 椿椿世界

抽奖项目的加锁流程

项目

加锁是为了解决高并发下的库存竞争问题，确保不会出现超卖情况。整个是在校验完活动信息之后去，再实现库存扣减整个setnx获取分布式锁的流程：获取抽奖活动库存的KEY 使用Redis的incr命令原子性地扣减库存

抽奖策略中的几种算法

项目

概率分配单体概率奖品抽空后，其他奖品概率保持不变，抽到空的就是没中奖了，哈希表存储概率分布随机数索引获取结果整体概率当某个奖品抽空后，剩余奖品概率按原比例重新分配。A(20%)抽空后，B(30%)和C(50%)变为B(37.5%)和C(62.5%) 排除不可抽奖的奖品（即库存为0的奖品）

滑动分布式锁处理秒杀

项目

主要是去解决高并发抽奖场景下的库存扣减问题，核心思路是：用Redis分布式锁替代数据库行锁，通过细粒度锁设计提升并发能力。原先用数据库用数据库行锁扣库存（就是SQL里加SELECT ... FOR UPDATE）

XXL-JOB任务扫描活动状态

项目

在这个抽奖系统主要干了两件需要任扫描的事，第一个是把"已审核通过"的活动变成"进行中"状态，第二个是把"已结束"的活动关闭。主要是通过 XXL-JOB这个分布式任务框架，比Spring自带的@Scheduled更强大。然后配置的是每10秒跑一次，扫描数据库里的活动。最后需要通过分页查询（每次查1

MQ解耦抽奖发货流程

项目

首先我们在user_strategy_export表加了mq_state字段，用来记录消息发送状态。整个流程是这样的：当用户抽中奖品后，系统会先在数据库生成中奖记录，此时mq_state是待发送状态（0）。然后通过KafkaProducer发送发货消息，如果发送成功就把状态改成1，失败就改成2。这里

建立规则引擎实现人群的决策量化

项目

当时我们做抽奖系统的时候，确实遇到了人群分类的问题。最开始的做法特别粗暴，直接写了一堆if-else： if(user.getAge() > 18 && user.getGender().equals("男")){ // 给男性成年人分配A策略 } else if(user.getVipLe