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%） RBloomFilter<String> 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 LocalCachedMap<String, 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实现异步落库：
// 初始化队列 RBlockingQueue<Order> 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() { List<Order> 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做缓存时，遇到缓存穿透问题。最终采用多级防护：
- 空值缓存
RMapCache<String, 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
- 锁等待线程 >100
7. 扩展思考：消息队列改造
近期正在将部分异步场景迁移到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以内。
