平时做技术实践时,很多问题不是概念不会,而是细节没串起来。拿“Redis实现方法未读消息计数的示例代码”来说,它看着像小点,放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序,把思路、关键写法和容易踩坑的地方讲清楚,便于大家直接对照操作。
从实现思路看,在合伙人系统的产品分配流程里,存在两种分配模式,核心差异在于是否需审核:
实际处理时,为提升城市合伙人的操作效率,小程序需在 “分配产品页面” 为城市合伙人显示待审核数,实时提醒其待处理的间接分配申请,而未读计数的存储与管理是实现该功能的核心。
实际处理时,在 “间接分配审核接口” 的最后,借助一行代码触发未读计数更新,直接调用工具类完成城市合伙人未读数量的累加:
// 添加未读数(默认新增1条待审核提醒)
appletRedisUtil.addUnreadCount(cityPartner.getId());
落到代码里,工具类基于 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 {
@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);
}
}
未读计数的核心诉求是 “快、并发安全、轻松”结合项目来看,,Redis 完美匹配这些需求,而 MySQL 更擅长 “复杂查询、事务一致性、永久存储”,具体优势对比如下所示:
特性 | Redis(内存数据库) | MySQL(磁盘数据库) |
响应时间 | 微秒级(1μs = 10⁻⁶秒) | 毫秒级(1ms = 10⁻³ 秒) |
每秒读写能力 | 数万~数十万次 | 千级次 |
高频场景表现 | 无卡顿,轻松扛住并发(如同时 100 个申请提交) | 易出现 “查询卡顿”“写入排队”,拖慢数据库 |
当多个请求同时修改同一城市合伙人的未读计数时(如同时 2 条申请提交):
Redis 的特性可轻松满足未来扩展需求,MySQL 难以实现:
落到代码里,虽然 Redis 是内存数据库,但工具类已做足数据安全保障,避免数据丢失:
到此这篇关于Redis实现未读消息计数的示例的文章就介绍到这了,更多相关Redis 未读消息计数内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家!