一、業(yè)務(wù)場(chǎng)景說(shuō)明

在合伙人系統(tǒng)的產(chǎn)品分配流程中，存在兩種分配模式，核心差異在于是否需要審核：

• 直接分配：一級(jí)（城市合伙人）向二級(jí)（銷(xiāo)售合伙人）分配產(chǎn)品，無(wú)需審核，直接生效；
• 間接分配：二級(jí)（銷(xiāo)售合伙人）向三級(jí)（流量合伙人）分配產(chǎn)品，必須經(jīng)過(guò)對(duì)應(yīng)一級(jí)（城市合伙人）審核，審核通過(guò)后分配才生效。

為提升城市合伙人的操作效率，小程序需在 “分配產(chǎn)品頁(yè)面” 為城市合伙人顯示待審核數(shù)，實(shí)時(shí)提醒其待處理的間接分配申請(qǐng)，而未讀計(jì)數(shù)的存儲(chǔ)與管理是實(shí)現(xiàn)該功能的核心。

二、未讀計(jì)數(shù)的實(shí)現(xiàn)方案

1. 核心觸發(fā)邏輯

在 “間接分配審核接口” 的最后，通過(guò)一行代碼觸發(fā)未讀計(jì)數(shù)更新，直接調(diào)用工具類(lèi)完成城市合伙人未讀數(shù)量的累加：

// 添加未讀數(shù)（默認(rèn)新增1條待審核提醒）
appletRedisUtil.addUnreadCount(cityPartner.getId());

2. 核心工具類(lèi)：AppletRedisUtil

工具類(lèi)基于 Redis 實(shí)現(xiàn)未讀計(jì)數(shù)的 “新增、查詢(xún)、重置” 全流程管理，代碼與邏輯解析如下：

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. 重載方法：默認(rèn)給城市合伙人新增1條未讀消息
    public void addUnreadCount(Long miniUserId) {
        addUnreadCount(miniUserId, 1L);
    }
 
    // 2. 核心方法：支持自定義新增未讀條數(shù)，含數(shù)據(jù)準(zhǔn)確性校驗(yàn)
    public void addUnreadCount(Long miniUserId, Long value) {
        // 2.1 工具類(lèi)無(wú)法直接注入Service，通過(guò)Spring上下文獲取
        ProductApplyRecordService productApplyRecordService = SpringContextUtil.getBean(ProductApplyRecordService.class);
        
        // 2.2 查該城市合伙人的總申請(qǐng)數(shù)（未讀上限，避免未讀數(shù)超過(guò)實(shí)際總數(shù)）
        Long totalCount = productApplyRecordService.lambdaQuery()
            .eq(ProductApplyRecord::getCityPartnerId, miniUserId)
            .count();
        
        // 2.3 查當(dāng)前Redis中的未讀數(shù)量（空值兜底返回0，避免空指針）
        Long currentUnread = getUnreadCount(miniUserId);
        
        // 2.4 修正未讀數(shù)量：若累加后超總申請(qǐng)數(shù)，取總申請(qǐng)數(shù)（防止數(shù)據(jù)異常）
        value = (currentUnread + value) > totalCount ? totalCount : (currentUnread + value);
        
        // 2.5 更新Redis：用“常量前綴+用戶(hù)ID”作為key，原子自增未讀數(shù)量
        redisTemplate.opsForValue().increment(RedisKeyConstant.PRODUCT_APPLY_UNREAD_NUM + miniUserId, value);
    }
 
    // 3. 查詢(xún)未讀數(shù)量：空值兜底，確保返回非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. 重置未讀數(shù)量：先置0再刪key，確保狀態(tài)徹底清空
    public void resetUnreadCount(Long miniUserId) {
        String key = RedisKeyConstant.PRODUCT_APPLY_UNREAD_NUM + miniUserId;
        redisTemplate.opsForValue().set(key, 0L);
        redisTemplate.delete(key);
    }
}

工具類(lèi)核心特點(diǎn)

• 數(shù)據(jù)準(zhǔn)確性：通過(guò) “總申請(qǐng)數(shù)校驗(yàn)” 避免未讀數(shù)溢出，空值兜底避免空指針；
• 操作規(guī)范性：統(tǒng)一 Redis key 格式（常量前綴 + 用戶(hù) ID），避免 key 混亂；
• 功能完整性：覆蓋 “新增、查詢(xún)、重置” 三大核心場(chǎng)景，支持默認(rèn) / 自定義新增條數(shù)；
• 依賴(lài)合理性：通過(guò) Spring 上下文獲取 Service，解決工具類(lèi)無(wú)法直接注入的問(wèn)題。

三、選型：為什么用 Redis 而非 MySQL？

未讀計(jì)數(shù)的核心訴求是 “快、并發(fā)安全、簡(jiǎn)單”，Redis 完美匹配這些需求，而 MySQL 更擅長(zhǎng) “復(fù)雜查詢(xún)、事務(wù)一致性、永久存儲(chǔ)”，具體優(yōu)勢(shì)對(duì)比如下：

1. 性能碾壓：高頻場(chǎng)景響應(yīng)速度差 3 個(gè)量級(jí)

2. 操作更輕量：避免 MySQL 復(fù)雜開(kāi)銷(xiāo)

• Redis：用 increment 原子命令，1 行代碼完成 “未讀數(shù) + 1”，無(wú)需鎖 / 事務(wù)；
• MySQL：需執(zhí)行 UPDATE xxx SET unread_count = unread_count + 1 WHERE ...，還需處理事務(wù)隔離級(jí)別、行鎖競(jìng)爭(zhēng)，代碼繁瑣且開(kāi)銷(xiāo)大。

3. 天然并發(fā)安全：解決 MySQL 更新沖突

當(dāng)多個(gè)請(qǐng)求同時(shí)修改同一城市合伙人的未讀計(jì)數(shù)時(shí)（如同時(shí) 2 條申請(qǐng)?zhí)峤唬?/p>

• Redis：INCR 是單線程原子操作，即使 100 個(gè)請(qǐng)求同時(shí) + 1，結(jié)果也絕對(duì)正確（0→100）；
• MySQL：易出現(xiàn) “并發(fā)更新丟失”（如兩個(gè)請(qǐng)求同時(shí)讀 5，都 + 1 后寫(xiě) 6，實(shí)際應(yīng)是 7），需額外加 “樂(lè)觀鎖 / 悲觀鎖”，增加復(fù)雜度。

4. 緩存特性適配：減少數(shù)據(jù)庫(kù)壓力

• Redis：未讀計(jì)數(shù)是 “緩存”，所有讀寫(xiě)走 Redis，MySQL 僅存原始申請(qǐng)記錄，極大降低 MySQL 訪問(wèn)壓力；
• MySQL：若直接存儲(chǔ)未讀數(shù)，高頻讀寫(xiě)會(huì)占用數(shù)據(jù)庫(kù)資源，影響核心業(yè)務(wù)（如申請(qǐng)記錄查詢(xún)）。

5. 靈活擴(kuò)展：支持更多交互場(chǎng)景

Redis 的特性可輕松滿足未來(lái)擴(kuò)展需求，MySQL 難以實(shí)現(xiàn)：

• 過(guò)期自動(dòng)清理：給未讀計(jì)數(shù) key 設(shè) expire，實(shí)現(xiàn) “30 天未讀自動(dòng)失效”，無(wú)需定時(shí)任務(wù)；
• 批量操作：用 MSET/MGET 批量更新 / 查詢(xún)多個(gè)城市合伙人的未讀數(shù)，效率極高；
• 豐富計(jì)數(shù)器操作：支持 INCRBY（自定義加量）、DECR（減量）、GETSET（獲取并重置），覆蓋全場(chǎng)景。

四、注意事項(xiàng)：Redis 數(shù)據(jù)安全兜底方案

雖然 Redis 是內(nèi)存數(shù)據(jù)庫(kù)，但工具類(lèi)已做足數(shù)據(jù)安全保障，避免數(shù)據(jù)丟失：

1. 數(shù)據(jù)源兜底：未讀計(jì)數(shù)的 “源頭” 是 MySQL（申請(qǐng)記錄存在 MySQL），Redis 僅為緩存；
2. 異常修正：若 Redis 數(shù)據(jù)丟失，getUnreadCount 會(huì)返回 0，而 addUnreadCount 會(huì)重新查詢(xún) MySQL 總申請(qǐng)數(shù)，自動(dòng)修正未讀計(jì)數(shù)，不會(huì)失真。

到此這篇關(guān)于Redis實(shí)現(xiàn)未讀消息計(jì)數(shù)的示例代碼的文章就介紹到這了,更多相關(guān)Redis 未讀消息計(jì)數(shù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論