Redis实现未读消息计数的示例代码

秋阳老王 發表於 2025-12-25 09:12:57

<div id="navCategory"><h5 class="catalogue">目录</h5><ul class="first_class_ul"><li><a href="#_label0">一、业务场景说明</a></li><li><a href="#_label1">二、未读计数的实现方案</a></li><ul class="second_class_ul"><li><a href="#_lab2_1_0">1. 核心触发逻辑</a></li><li><a href="#_lab2_1_1">2. 核心工具类：AppletRedisUtil</a></li><li><a href="#_lab2_1_2">工具类核心特点</a></li></ul><li><a href="#_label2">三、选型：为什么用 Redis 而非 MySQL？</a></li><ul class="second_class_ul"><li><a href="#_lab2_2_3">1. 性能碾压：高频场景响应速度差 3 个量级</a></li><li><a href="#_lab2_2_4">2. 操作更轻量：避免 MySQL 复杂开销</a></li><li><a href="#_lab2_2_5">3. 天然并发安全：解决 MySQL 更新冲突</a></li><li><a href="#_lab2_2_6">4. 缓存特性适配：减少数据库压力</a></li><li><a href="#_lab2_2_7">5. 灵活扩展：支持更多交互场景</a></li></ul><li><a href="#_label3">四、注意事项：Redis 数据安全兜底方案</a></li><ul class="second_class_ul"></ul></ul></div><p class="maodian"><a name="_label0"></a></p><h2>一、业务场景说明</h2>
<p>在合伙人系统的产品分配流程中，存在两种分配模式，核心差异在于是否需要审核：</p>
<ul><li>直接分配：一级（城市合伙人）向二级（销售合伙人）分配产品，无需审核，直接生效；</li><li>间接分配：二级（销售合伙人）向三级（流量合伙人）分配产品，必须经过对应一级（城市合伙人）审核，审核通过后分配才生效。</li></ul>
<p>为提升城市合伙人的操作效率，小程序需在 “分配产品页面” 为城市合伙人显示待审核数，实时提醒其待处理的间接分配申请，而未读计数的存储与管理是实现该功能的核心。</p>
<p class="maodian"><a name="_label1"></a></p><h2>二、未读计数的实现方案</h2>
<p class="maodian"><a name="_lab2_1_0"></a></p><h3>1. 核心触发逻辑</h3>
<p>在 “间接分配审核接口” 的最后，通过一行代码触发未读计数更新，直接调用工具类完成城市合伙人未读数量的累加：</p>
<div class="jb51code"><pre class="brush:java;">// 添加未读数（默认新增1条待审核提醒）
appletRedisUtil.addUnreadCount(cityPartner.getId());</pre></div>
<p class="maodian"><a name="_lab2_1_1"></a></p><h3>2. 核心工具类：AppletRedisUtil</h3>
<p>工具类基于 Redis 实现未读计数的 “新增、查询、重置” 全流程管理，代码与逻辑解析如下：</p>
<div class="jb51code"><pre class="brush:java;">import jakarta.annotation.Resource;
import org.springblade.business.constant.RedisKeyConstant;
import org.springblade.business.pojo.entity.ProductApplyRecord;
import org.springblade.business.service.ProductApplyRecordService;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
import java.util.Objects;

@Component // 注入Spring容器，全局可用
public class AppletRedisUtil {

@Resource
private RedisTemplate<String, Long> redisTemplate; // 操作Redis的核心组件

// 1. 重载方法：默认给城市合伙人新增1条未读消息
public void addUnreadCount(Long miniUserId) {
   addUnreadCount(miniUserId, 1L);
}

// 2. 核心方法：支持自定义新增未读条数，含数据准确性校验
public void addUnreadCount(Long miniUserId, Long value) {
   // 2.1 工具类无法直接注入Service，通过Spring上下文获取
   ProductApplyRecordService productApplyRecordService = SpringContextUtil.getBean(ProductApplyRecordService.class);

   // 2.2 查该城市合伙人的总申请数（未读上限，避免未读数超过实际总数）
   Long totalCount = productApplyRecordService.lambdaQuery()
         .eq(ProductApplyRecord::getCityPartnerId, miniUserId)
         .count();

   // 2.3 查当前Redis中的未读数量（空值兜底返回0，避免空指针）
   Long currentUnread = getUnreadCount(miniUserId);

   // 2.4 修正未读数量：若累加后超总申请数，取总申请数（防止数据异常）
   value = (currentUnread + value) > totalCount ? totalCount : (currentUnread + value);

   // 2.5 更新Redis：用“常量前缀+用户ID”作为key，原子自增未读数量
   redisTemplate.opsForValue().increment(RedisKeyConstant.PRODUCT_APPLY_UNREAD_NUM + miniUserId, value);
}

// 3. 查询未读数量：空值兜底，确保返回非null
public Long getUnreadCount(Long miniUserId) {
   String key = RedisKeyConstant.PRODUCT_APPLY_UNREAD_NUM + miniUserId;
   Long unread = redisTemplate.opsForValue().get(key);
   return Objects.isNull(unread) ? 0L : unread;
}

// 4. 重置未读数量：先置0再删key，确保状态彻底清空
public void resetUnreadCount(Long miniUserId) {
   String key = RedisKeyConstant.PRODUCT_APPLY_UNREAD_NUM + miniUserId;
   redisTemplate.opsForValue().set(key, 0L);
   redisTemplate.delete(key);
}
}</pre></div>
<p class="maodian"><a name="_lab2_1_2"></a></p><h3>工具类核心特点</h3>
<ul><li>数据准确性：通过 “总申请数校验” 避免未读数溢出，空值兜底避免空指针；</li><li>操作规范性：统一 Redis key 格式（常量前缀 + 用户 ID），避免 key 混乱；</li><li>功能完整性：覆盖 “新增、查询、重置” 三大核心场景，支持默认 / 自定义新增条数；</li><li>依赖合理性：通过 Spring 上下文获取 Service，解决工具类无法直接注入的问题。</li></ul>
<p class="maodian"><a name="_label2"></a></p><h2>三、选型：为什么用 Redis 而非 MySQL？</h2>
<p>未读计数的核心诉求是 <strong>“快、并发安全、简单”</strong>，Redis 完美匹配这些需求，而 MySQL 更擅长 “复杂查询、事务一致性、永久存储”，具体优势对比如下：</p>
<p class="maodian"><a name="_lab2_2_3"></a></p><h3>1. 性能碾压：高频场景响应速度差 3 个量级</h3>
<table id="i0kMy"><tbody><tr><td><p>特性</p></td><td><p>Redis（内存数据库）</p></td><td><p>MySQL（磁盘数据库）</p></td></tr><tr><td><p>响应时间</p></td><td><p>微秒级（1μs = 10⁻⁶秒）</p></td><td><p>毫秒级（1ms = 10⁻³ 秒）</p></td></tr><tr><td><p>每秒读写能力</p></td><td><p>数万～数十万次</p></td><td><p>千级次</p></td></tr><tr><td><p>高频场景表现</p></td><td><p>无卡顿，轻松扛住并发（如同时 100 个申请提交）</p></td><td><p>易出现 “查询卡顿”“写入排队”，拖慢数据库</p></td></tr></tbody></table>
<p class="maodian"><a name="_lab2_2_4"></a></p><h3>2. 操作更轻量：避免 MySQL 复杂开销</h3>
<ul><li>Redis：用 increment 原子命令，1 行代码完成 “未读数 + 1”，无需锁 / 事务；</li><li>MySQL：需执行 UPDATE xxx SET unread_count = unread_count + 1 WHERE ...，还需处理事务隔离级别、行锁竞争，代码繁琐且开销大。</li></ul>
<p class="maodian"><a name="_lab2_2_5"></a></p><h3>3. 天然并发安全：解决 MySQL 更新冲突</h3>
<p>当多个请求同时修改同一城市合伙人的未读计数时（如同时 2 条申请提交）：</p>
<ul><li>Redis：INCR 是单线程原子操作，即使 100 个请求同时 + 1，结果也绝对正确（0→100）；</li><li>MySQL：易出现 “并发更新丢失”（如两个请求同时读 5，都 + 1 后写 6，实际应是 7），需额外加 “乐观锁 / 悲观锁”，增加复杂度。</li></ul>
<p class="maodian"><a name="_lab2_2_6"></a></p><h3>4. 缓存特性适配：减少数据库压力</h3>
<ul><li>Redis：未读计数是 “缓存”，所有读写走 Redis，MySQL 仅存原始申请记录，极大降低 MySQL 访问压力；</li><li>MySQL：若直接存储未读数，高频读写会占用数据库资源，影响核心业务（如申请记录查询）。</li></ul>
<p class="maodian"><a name="_lab2_2_7"></a></p><h3>5. 灵活扩展：支持更多交互场景</h3>
<p>Redis 的特性可轻松满足未来扩展需求，MySQL 难以实现：</p>
<ul><li>过期自动清理：给未读计数 key 设 expire，实现 “30 天未读自动失效”，无需定时任务；</li><li>批量操作：用 MSET/MGET 批量更新 / 查询多个城市合伙人的未读数，效率极高；</li><li>丰富计数器操作：支持 INCRBY（自定义加量）、DECR（减量）、GETSET（获取并重置），覆盖全场景。</li></ul>
<p class="maodian"><a name="_label3"></a></p><h2>四、注意事项：Redis 数据安全兜底方案</h2>
<p>虽然 Redis 是内存数据库，但工具类已做足数据安全保障，避免数据丢失：</p>
<ol><li>数据源兜底：未读计数的 “源头” 是 MySQL（申请记录存在 MySQL），Redis 仅为缓存；</li><li>异常修正：若 Redis 数据丢失，getUnreadCount 会返回 0，而 addUnreadCount 会重新查询 MySQL 总申请数，自动修正未读计数，不会失真。</li></ol>

頁: [1]

琼殿技术论坛's Archiver

Redis实现未读消息计数的示例代码