当前位置：首页 > news >正文

Redis实现未读消息计数

news 2025/11/11 15:11:54

合伙人系统中产品分配未读计数的实现与 Redis 选型分析

一、业务场景说明

二、未读计数的实现方案

1. 核心触发逻辑

2. 核心工具类：AppletRedisUtil

工具类核心特点

三、选型：为什么用 Redis 而非 MySQL？

1. 性能碾压：高频场景响应速度差 3 个量级

2. 操作更轻量：避免 MySQL 复杂开销

3. 天然并发安全：解决 MySQL 更新冲突

4. 缓存特性适配：减少数据库压力

5. 灵活扩展：支持更多交互场景

四、注意事项：Redis 数据安全兜底方案

合伙人系统中产品分配未读计数的实现与 Redis 选型分析

一、业务场景说明

在合伙人系统的产品分配流程中，存在两种分配模式，核心差异在于是否需要审核：

直接分配：一级（城市合伙人）向二级（销售合伙人）分配产品，无需审核，直接生效；
间接分配：二级（销售合伙人）向三级（流量合伙人）分配产品，必须经过对应一级（城市合伙人）审核，审核通过后分配才生效。

为提升城市合伙人的操作效率，小程序需在 “分配产品页面” 为城市合伙人显示待审核数，实时提醒其待处理的间接分配申请，而未读计数的存储与管理是实现该功能的核心。

二、未读计数的实现方案

1. 核心触发逻辑

在 “间接分配审核接口” 的最后，通过一行代码触发未读计数更新，直接调用工具类完成城市合伙人未读数量的累加：

// 添加未读数（默认新增1条待审核提醒）
appletRedisUtil.addUnreadCount(cityPartner.getId());

2. 核心工具类：AppletRedisUtil

工具类基于 Redis 实现未读计数的 “新增、查询、重置” 全流程管理，代码与逻辑解析如下：

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 {@Resourceprivate 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. 查询未读数量：空值兜底，确保返回非nullpublic 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);}
}

工具类核心特点

数据准确性：通过 “总申请数校验” 避免未读数溢出，空值兜底避免空指针；
操作规范性：统一 Redis key 格式（常量前缀 + 用户 ID），避免 key 混乱；
功能完整性：覆盖 “新增、查询、重置” 三大核心场景，支持默认 / 自定义新增条数；
依赖合理性：通过 Spring 上下文获取 Service，解决工具类无法直接注入的问题。

三、选型：为什么用 Redis 而非 MySQL？

未读计数的核心诉求是 “快、并发安全、简单”，Redis 完美匹配这些需求，而 MySQL 更擅长 “复杂查询、事务一致性、永久存储”，具体优势对比如下：

1. 性能碾压：高频场景响应速度差 3 个量级

特性	Redis（内存数据库）	MySQL（磁盘数据库）
响应时间	微秒级（1μs = 10⁻⁶秒）	毫秒级（1ms = 10⁻³ 秒）
每秒读写能力	数万～数十万次	千级次
高频场景表现	无卡顿，轻松扛住并发（如同时 100 个申请提交）	易出现 “查询卡顿”“写入排队”，拖慢数据库