本發(fā)明涉及信息處理，具體為一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)及方法。

背景技術(shù)：

1、在即時(shí)通訊軟件和其他消息傳遞服務(wù)中，準(zhǔn)確快速地統(tǒng)計(jì)用戶(hù)的未讀消息數(shù)量是用戶(hù)體驗(yàn)的關(guān)鍵因素之一。

2、傳統(tǒng)的實(shí)現(xiàn)方式通常為每條消息創(chuàng)建一條數(shù)據(jù)庫(kù)記錄，并通過(guò)全表掃描的方式確定特定用戶(hù)的未讀消息數(shù)量。這種方式不僅效率低下，而且占用大量的存儲(chǔ)空間。具體存在的問(wèn)題如下：

3、全表掃描：查詢(xún)特定用戶(hù)未讀消息時(shí)需要遍歷整個(gè)數(shù)據(jù)庫(kù)，導(dǎo)致響應(yīng)時(shí)間長(zhǎng)。

4、數(shù)據(jù)冗余：所有消息(包括已讀和未讀)都被記錄下來(lái)，造成磁盤(pán)空間浪費(fèi)。

5、因此我們需要提出一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)及方法，能夠顯著提高數(shù)據(jù)處理效率并減少所需的存儲(chǔ)空間。

技術(shù)實(shí)現(xiàn)思路

1、本發(fā)明的目的在于提供一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)及方法，只記錄了已讀消息，相比傳統(tǒng)方法大幅減少了數(shù)據(jù)存儲(chǔ)需求，通過(guò)使用redis緩存直接獲取未讀消息計(jì)數(shù)，避免了全表掃描，大大提高了查詢(xún)效率，以解決上述背景技術(shù)中提出的問(wèn)題。

2、為實(shí)現(xiàn)上述目的，本發(fā)明提供如下技術(shù)方案：一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)，包括：

3、消息明細(xì)表：僅保存已讀消息的相關(guān)信息；

4、redis緩存：用于實(shí)時(shí)更新每位用戶(hù)的未讀消息計(jì)數(shù)；每個(gè)用戶(hù)都有一個(gè)獨(dú)立的鍵值對(duì)，其中鍵為用戶(hù)id，值為當(dāng)前未讀消息的數(shù)量；

5、消息明細(xì)表中的字段包括：

6、id：消息的唯一標(biāo)識(shí)符；

7、user-id：接收消息的用戶(hù)id；

8、message_content：消息內(nèi)容；

9、read_time：消息被標(biāo)記為已讀的時(shí)間；

10、redis緩存中的鍵用于唯一標(biāo)識(shí)一個(gè)用戶(hù)的未讀消息計(jì)數(shù)，redis緩存中的值隨著新消息的到達(dá)和消息的閱讀而實(shí)時(shí)更新。

11、優(yōu)選的，字段中id的類(lèi)型為整型或字符串，用于區(qū)分不同的消息記錄；字段中user-id的類(lèi)型為整型或字符串，用于標(biāo)識(shí)消息的接收者；字段中message_content的類(lèi)型為文本、鏈接或圖片；字段中read_time的類(lèi)型為時(shí)間戳，用于分析用戶(hù)閱讀消息的習(xí)慣或進(jìn)行消息推送策略的優(yōu)化。

12、優(yōu)選的，每個(gè)用戶(hù)的鍵是唯一的，確保每個(gè)用戶(hù)的未讀消息計(jì)數(shù)是獨(dú)立存儲(chǔ)的；當(dāng)有新消息到達(dá)時(shí)，用戶(hù)的未讀消息計(jì)數(shù)增加，當(dāng)用戶(hù)閱讀一條消息時(shí)，用戶(hù)的未讀消息計(jì)數(shù)減少。

13、本發(fā)明還提供了一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，基于以上敘述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)，包括以下步驟：

14、s1、新消息到達(dá)：當(dāng)有新消息發(fā)送給用戶(hù)時(shí)，在redis緩存中，用戶(hù)的未讀消息計(jì)數(shù)器增加相應(yīng)的數(shù)值；

15、s2、消息閱讀：用戶(hù)閱讀新消息后，將新消息標(biāo)記為已讀，并將新消息詳情添加到消息明細(xì)表中；同時(shí)，在redis緩存中減小對(duì)應(yīng)的未讀消息計(jì)數(shù)；

16、s3、查詢(xún)未讀消息數(shù)量：通過(guò)redis緩存中獲取的讀消息計(jì)數(shù)值和消息明細(xì)表中查詢(xún)到的已讀消息數(shù)量計(jì)算未讀消息數(shù)量。

17、優(yōu)選的，在步驟s1中，新消息到達(dá)的流程如下：

18、s11、當(dāng)有一條新消息發(fā)送給用戶(hù)時(shí)，首先確定接收消息的用戶(hù)id；

19、s12、在redis緩存中，找到用戶(hù)對(duì)應(yīng)的未讀消息計(jì)數(shù)器，并將未讀消息計(jì)數(shù)器的數(shù)值增加1；

20、s13、將新消息存儲(chǔ)到消息存儲(chǔ)系統(tǒng)中，由于新消息還未被閱讀，此時(shí)不立即更新消息明細(xì)表。

21、優(yōu)選的，在步驟s2中，消息閱讀的流程如下：

22、s21、用戶(hù)閱讀新消息后，系統(tǒng)首先將新消息標(biāo)記為已讀；

23、s22、將新消息的詳情插入到消息明細(xì)表中，并記錄閱讀時(shí)間；

24、s23、在redis緩存中，找到用戶(hù)對(duì)應(yīng)的未讀消息計(jì)數(shù)器，并將未讀消息計(jì)數(shù)器的數(shù)值減去1。

25、優(yōu)選的，在步驟s3中，查詢(xún)未讀消息數(shù)量的流程如下：

26、s31、查詢(xún)特定用戶(hù)的未讀消息總數(shù)時(shí)，首先從redis緩存中獲取用戶(hù)當(dāng)前的未讀消息計(jì)數(shù)值；

27、s32、然后根據(jù)用戶(hù)id從消息明細(xì)表中查詢(xún)用戶(hù)的已讀消息數(shù)量；

28、s33、計(jì)算redis緩存中的未讀消息計(jì)數(shù)值與已讀消息數(shù)量之差，即為最終的未讀消息數(shù)量。

29、優(yōu)選的，從redis緩存中獲取未讀消息計(jì)數(shù)值時(shí)，系統(tǒng)會(huì)根據(jù)用戶(hù)id構(gòu)建一個(gè)redis鍵，然后使用redis緩存的get命令獲取redis鍵的數(shù)值，此數(shù)值即為redis緩存中用戶(hù)當(dāng)前的未讀消息計(jì)數(shù)值。

30、優(yōu)選的，從消息明細(xì)表中查詢(xún)已讀消息數(shù)量時(shí)，系統(tǒng)根據(jù)用戶(hù)id從消息明細(xì)表中查詢(xún)用戶(hù)的所有已讀消息記錄，然后使用sql查詢(xún)的聚合函數(shù)計(jì)算已讀消息的數(shù)量。

31、優(yōu)選的，在步驟s33中，若redis緩存中的未讀消息數(shù)值為空，將未讀消息視為0，若從消息明細(xì)表中查詢(xún)到的已讀消息數(shù)量為0，直接返回redis緩存中的未讀消息計(jì)數(shù)值。

32、與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果是：

33、1、本發(fā)明只記錄了已讀消息，極大地節(jié)省存儲(chǔ)空間，相比傳統(tǒng)方法大幅減少了數(shù)據(jù)存儲(chǔ)需求，適用于那些消息量大、但閱讀率相對(duì)較低的應(yīng)用場(chǎng)景；

34、2、本發(fā)明redis緩存提供高速的讀寫(xiě)操作，能夠在微秒級(jí)的時(shí)間內(nèi)完成數(shù)據(jù)的讀寫(xiě)，用于實(shí)時(shí)更新和查詢(xún)未讀消息計(jì)數(shù)，通過(guò)使用redis緩存直接獲取未讀消息計(jì)數(shù)，避免了全表掃描，大大提高了查詢(xún)效率。

35、3、本發(fā)明只涉及已讀消息，消息明細(xì)表表的維護(hù)成本相對(duì)低，不需要頻繁地清理未讀消息或處理過(guò)期的消息記錄。

技術(shù)特征：

1.一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)，其特征在于，包括：

2.根據(jù)權(quán)利要求1所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)，其特征在于：字段中id的類(lèi)型為整型或字符串，用于區(qū)分不同的消息記錄；字段中user-id的類(lèi)型為整型或字符串，用于標(biāo)識(shí)消息的接收者；字段中message_content的類(lèi)型為文本、鏈接或圖片；字段中read_time的類(lèi)型為時(shí)間戳，用于分析用戶(hù)閱讀消息的習(xí)慣或進(jìn)行消息推送策略的優(yōu)化。

3.根據(jù)權(quán)利要求1所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)，其特征在于：每個(gè)用戶(hù)的鍵是唯一的，確保每個(gè)用戶(hù)的未讀消息計(jì)數(shù)是獨(dú)立存儲(chǔ)的；當(dāng)有新消息到達(dá)時(shí)，用戶(hù)的未讀消息計(jì)數(shù)增加，當(dāng)用戶(hù)閱讀一條消息時(shí)，用戶(hù)的未讀消息計(jì)數(shù)減少。

4.一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，基于權(quán)利1-3任意一項(xiàng)所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)，其特征在于，包括以下步驟：

5.根據(jù)權(quán)利要求1所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，其特征在于：在步驟s1中，新消息到達(dá)的流程如下：

6.根據(jù)權(quán)利要求1所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，其特征在于：在步驟s2中，消息閱讀的流程如下：

7.根據(jù)權(quán)利要求1所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，其特征在于：在步驟s3中，查詢(xún)未讀消息數(shù)量的流程如下：

8.根據(jù)權(quán)利要求7所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，其特征在于：從redis緩存中獲取未讀消息計(jì)數(shù)值時(shí)，系統(tǒng)會(huì)根據(jù)用戶(hù)id構(gòu)建一個(gè)redis鍵，然后使用redis緩存的get命令獲取redis鍵的數(shù)值，此數(shù)值即為redis緩存中用戶(hù)當(dāng)前的未讀消息計(jì)數(shù)值。

9.根據(jù)權(quán)利要求7所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，其特征在于：從消息明細(xì)表中查詢(xún)已讀消息數(shù)量時(shí)，系統(tǒng)根據(jù)用戶(hù)id從消息明細(xì)表中查詢(xún)用戶(hù)的所有已讀消息記錄，然后使用sql查詢(xún)的聚合函數(shù)計(jì)算已讀消息的數(shù)量。

10.根據(jù)權(quán)利要求7所述的一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)方法，其特征在于：在步驟s33中，若redis緩存中的未讀消息數(shù)值為空，將未讀消息視為0，若從消息明細(xì)表中查詢(xún)到的已讀消息數(shù)量為0，直接返回redis緩存中的未讀消息計(jì)數(shù)值。

技術(shù)總結(jié)
本發(fā)明涉及信息處理技術(shù)領(lǐng)域，公開(kāi)了一種基于已讀消息記錄和緩存技術(shù)優(yōu)化的未讀消息計(jì)數(shù)系統(tǒng)及方法，包括：消息明細(xì)表：僅保存已讀消息的相關(guān)信息；Redis緩存：用于實(shí)時(shí)更新每位用戶(hù)的未讀消息計(jì)數(shù)；每個(gè)用戶(hù)都有一個(gè)獨(dú)立的鍵值對(duì)，其中鍵為用戶(hù)ID，值為當(dāng)前未讀消息的數(shù)量；還包括新消息到達(dá)、消息閱讀、查詢(xún)未讀消息數(shù)量的計(jì)數(shù)流程；只記錄了已讀消息，極大地節(jié)省存儲(chǔ)空間，大幅減少了數(shù)據(jù)存儲(chǔ)需求，適用于那些消息量大、但閱讀率相對(duì)較低的應(yīng)用場(chǎng)景；Redis緩存提供高速的讀寫(xiě)操作，能夠在微秒級(jí)的時(shí)間內(nèi)完成數(shù)據(jù)的讀寫(xiě)，用于實(shí)時(shí)更新和查詢(xún)未讀消息計(jì)數(shù)，通過(guò)使用Redis緩存直接獲取未讀消息計(jì)數(shù)，避免了全表掃描，大大提高了查詢(xún)效率。

技術(shù)研發(fā)人員：沈棟,陶建林,宋志浩,朱海瑞,劉陽(yáng),劉暢,楊坤,黃志行,趙瑞威,宋麗,張君蕊,陸輝,杜若畫(huà),姜洪亮
受保護(hù)的技術(shù)使用者：上海農(nóng)村商業(yè)銀行股份有限公司
技術(shù)研發(fā)日：
技術(shù)公布日：2025/5/15