Redisson实战：高并发点评系统架构设计与优化

1. 项目概述基于Redisson的黑马点评系统重构三年前接手一个老旧点评系统时我遇到了令人头疼的并发问题——秒杀场景下库存超卖、分布式节点间数据不一致。当时用原生Redis命令硬编码实现的分布式锁在节点宕机时出现了死锁。直到发现Redisson这个Java界的Redis神器才真正解决了分布式环境下的并发控制难题。这个黑马点评项目重构案例完整呈现了如何从零搭建基于Redisson的高并发点评系统。不同于简单的API调用教程我会重点分享在真实生产环境中如何通过Redisson的分布式锁、限流器、布隆过滤器等组件解决实际业务场景中的典型问题。适合已经掌握SpringBoot基础想要深入分布式系统开发的Java工程师。2. 技术选型与架构设计2.1 为什么选择Redisson而非Lettuce在初期技术调研时我们对比了Jedis、Lettuce和Redisson三个主流Redis客户端。虽然Lettuce作为Spring Boot默认集成方案性能出色但其底层基于Netty的异步特性在分布式锁等场景需要开发者自行实现重试、续约等机制。而Redisson提供的RLock对象直接内置了自动续期机制默认30秒租期每10秒续期可重入锁支持公平锁/非公平锁选择锁等待时间设置// 典型Redisson分布式锁使用示例 RLock lock redissonClient.getLock(shop:lock: shopId); try { // 尝试获取锁等待时间10秒锁持有时间30秒 boolean isLock lock.tryLock(10, 30, TimeUnit.SECONDS); if (isLock) { // 业务逻辑处理 } } finally { lock.unlock(); }2.2 业务场景与技术组件映射针对黑马点评的典型场景我们设计了如下技术方案业务场景Redisson组件解决的核心问题秒杀抢购RLock RRateLimiter库存超卖、流量洪峰附近商家搜索RGeo地理位置计算性能热门店铺排行榜RScoredSortedSet实时排名更新恶意刷单检测RBloomFilter用户行为去重缓存数据一致RTopic LocalCachedMap多节点缓存同步3. 核心功能实现细节3.1 分布式锁优化秒杀流程在最初的实现中使用Redis的SETNX命令实现分布式锁存在两个致命缺陷锁过期时间设置不合理导致业务未完成锁已释放节点崩溃后无法自动释放锁通过Redisson的RLock对象我们重构了秒杀逻辑public Result seckillVoucher(Long voucherId) { // 获取分布式锁针对每个优惠券ID加锁 RLock lock redissonClient.getLock(lock:voucher: voucherId); try { // 获取锁非阻塞式 if (!lock.tryLock(0, 10, TimeUnit.SECONDS)) { return Result.fail(操作太频繁); } // 查询库存 Integer stock voucherService.query().eq(id, voucherId).one().getStock(); if (stock 1) { return Result.fail(库存不足); } // 扣减库存 boolean success voucherService.update() .setSql(stock stock - 1) .eq(id, voucherId) .gt(stock, 0) // CAS乐观锁 .update(); if (!success) { return Result.fail(库存不足); } // 创建订单略 return Result.ok(orderId); } finally { lock.unlock(); } }关键技巧结合Redisson分布式锁与数据库乐观锁形成双重保障。即使Redis集群出现故障数据库层的乐观锁仍能保证最终一致性。3.2 布隆过滤器防刷设计针对羊毛党使用脚本刷单的问题我们采用Redisson的RBloomFilter实现低成本去重// 初始化布隆过滤器预计元素100万误判率1% RBloomFilterString bloomFilter redissonClient.getBloomFilter(user:operation:filter); bloomFilter.tryInit(1000000L, 0.01); // 校验用户操作 public boolean checkUserOperation(Long userId, String operationType) { String key userId : operationType; if (bloomFilter.contains(key)) { return false; } bloomFilter.add(key); return true; }实测数据显示在100万用户量的场景下内存占用仅约1.2MB误判率稳定在0.8%-1.2%之间QPS可达15万以上3.3 分布式限流器实现针对热点店铺的查询接口使用RRateLimiter实现令牌桶限流// 每个店铺独立的限流器 RRateLimiter rateLimiter redissonClient.getRateLimiter(shop:limit: shopId); // 每秒10个令牌桶容量20 rateLimiter.trySetRate(RateType.OVERALL, 10, 20, RateIntervalUnit.SECONDS); public Result queryShopInfo(Long shopId) { if (rateLimiter.tryAcquire(1)) { // 正常查询逻辑 return Result.ok(shopService.getById(shopId)); } return Result.fail(访问过于频繁请稍后再试); }4. 性能优化实战记录4.1 本地缓存优化方案发现店铺信息查询的Redis热点Key问题后采用Redisson的LocalCachedMap降低Redis压力# application.yml配置 redisson: local-cache: eviction-policy: LFU cache-size: 1000 time-to-live: 1800000 max-idle-time: 900000// 初始化本地缓存Map LocalCachedMapString, Shop cachedMap redissonClient.getLocalCachedMap( shops, LocalCachedMapOptions.defaults() .evictionPolicy(EvictionPolicy.LFU) .cacheSize(1000) ); // 查询优先走本地缓存 public Shop getShop(Long id) { String key shop: id; Shop shop cachedMap.get(key); if (shop null) { shop shopService.getById(id); cachedMap.put(key, shop); } return shop; }优化后效果Redis查询量下降70%平均响应时间从45ms降至12ms本地缓存命中率稳定在85%左右4.2 异步持久化设计针对高并发写入场景采用Redisson的RBlockingQueue实现异步落库// 初始化队列 RBlockingQueueOrder orderQueue redissonClient.getBlockingQueue(order:queue); // 生产者下单服务 public Result createOrder(Order order) { // 1. 快速校验 // 2. 写入Redis队列 orderQueue.offer(order); // 3. 立即返回 return Result.ok(下单请求已接收); } // 消费者独立服务 Scheduled(fixedRate 1000) public void processOrderQueue() { ListOrder batch new ArrayList(100); for (int i 0; i 100; i) { Order order orderQueue.poll(); if (order ! null) { batch.add(order); } else { break; } } if (!batch.isEmpty()) { orderService.saveBatch(batch); } }5. 踩坑与问题排查实录5.1 锁续期异常排查线上曾出现分布式锁提前释放的问题经排查发现是Redisson看门狗线程被阻塞。解决方案调整Netty线程池参数redisson: threads: 16 netty-threads: 32避免在锁代码块中执行长时间IO操作监控锁持有时间5.2 缓存穿透防御当使用Redisson的RMapCache做缓存时遇到缓存穿透问题。最终采用多级防护空值缓存RMapCacheString, Object cache redissonClient.getMapCache(data); if (dbResult null) { cache.put(key, NULL, 5, TimeUnit.MINUTES); }布隆过滤器前置校验互斥锁重建缓存5.3 集群切换问题Redis集群主从切换时Redisson可能出现短暂不可用。通过以下配置增强鲁棒性redisson: cluster-scan-interval: 3000 # 集群节点扫描间隔 retry-attempts: 5 # 命令重试次数 retry-interval: 1000 # 重试间隔6. 环境配置与部署建议6.1 生产级Redisson配置redisson: single-server-config: address: redis://127.0.0.1:6379 connection-minimum-idle-size: 8 connection-pool-size: 64 idle-connection-timeout: 10000 connect-timeout: 5000 timeout: 3000 retry-attempts: 3 retry-interval: 1000 subscriptions-per-connection: 5 ssl-enable-endpoint-identification: false6.2 监控指标采集通过Redisson的JMX监控关键指标连接池使用率命令延迟百分位锁等待队列长度限流器拒绝请求数推荐告警阈值连接池使用率 80% 持续5分钟P99延迟 500ms锁等待线程 1007. 扩展思考消息队列改造近期正在将部分异步场景迁移到Redisson的RTopic实现发布/订阅模式// 订单创建事件发布 RTopic orderTopic redissonClient.getTopic(order:create); orderTopic.publish(new OrderCreateEvent(orderId)); // 在库存服务订阅 orderTopic.addListener(OrderCreateEvent.class, (channel, msg) - { inventoryService.deduct(msg.getOrderId()); });这种方案特别适合中小型系统快速实现事件驱动架构避免了引入Kafka等重型中间件的运维成本。实测在万级QPS场景下平均延迟可以控制在20ms以内。