《redis in action》發(fā)布和訂閱

之前我們說(shuō)redis中的發(fā)布訂閱有點(diǎn)問題，問題就是會(huì)存在消息丟失的問題。當(dāng)時(shí)我們說(shuō)還有幾個(gè)參數(shù)。而且redis的發(fā)布訂閱的時(shí)候，信道的斷路的問題也是消息丟失的原因之一。那么如何諸如QQ這種發(fā)布訂閱的問題如何用redis去解決。這里咋大概的想一下這個(gè)問題。

首先第一步是如何實(shí)現(xiàn)一個(gè)端到端的發(fā)布訂閱，也就是說(shuō)像我們的消息隊(duì)列這種的發(fā)布訂閱。這個(gè)就比較容易了，直接使用List數(shù)據(jù)結(jié)構(gòu)即可完成。我們讓消費(fèi)者從隊(duì)列中獲取數(shù)據(jù)即可。說(shuō)白了就是我們的前邊說(shuō)的消息隊(duì)列，如果用來(lái)描述QQ中的用戶對(duì)用戶的聊天，那么用該隊(duì)列即可，因?yàn)閘ist具有順序，那么消息也就自帶了時(shí)間特色。

第二種發(fā)布和訂閱就是多個(gè)客戶端都要去接受消息了，這種模式就類似QQ中的群聊。考慮到我們的消息不能重復(fù)存儲(chǔ)，原因是我們的用戶數(shù)量很大，那么消息只能唯一存儲(chǔ)，但是用戶與消息的關(guān)系就只能通過映射去維護(hù)。如果是我的話，我可能會(huì)用時(shí)間戳來(lái)序列化存儲(chǔ)消息，而且消息發(fā)送的時(shí)候肯定是需要加分布式鎖的。但是消息發(fā)送到群中去，每個(gè)人讀到的消息肯定不是實(shí)時(shí)的，有可能A已經(jīng)讀完了所有消息，B還有幾條沒讀。這時(shí)候A和B顯示的未讀消息數(shù)應(yīng)該是不一樣的。所以說(shuō)我們存儲(chǔ)群消息和群中的人員的關(guān)系的時(shí)候肯定要保留用戶所讀取到的消息的位置。當(dāng)未讀消息位置沒有達(dá)到現(xiàn)有消息的位置的時(shí)候，應(yīng)該要進(jìn)行提示。這塊必然走得是HTTP1.1或者其他websocket技術(shù)。我們?cè)賮?lái)梳理一下發(fā)送消息的步驟。

第一我們要?jiǎng)?chuàng)建群聊，確定那些人是我們要發(fā)送消息的對(duì)象。拿到這些信息之后，我們針對(duì)這些人創(chuàng)建群聊消息id和群聊成員id之間消息的讀取位置id信息。因?yàn)槲覀兊南⒈４嬉许樞颍敲次覀兛梢圆捎脄set進(jìn)行存儲(chǔ)。其score可以針對(duì)一個(gè)redis變量進(jìn)行累計(jì)得出，這樣我們的消息就是有序列的。

在群聊成員獲取消息的時(shí)候，必然是一次性獲取所有群聊的數(shù)據(jù)。所以在上邊說(shuō)的群聊和成員的關(guān)系維護(hù)上，我們必然要按照一定的規(guī)則去做。所以在獲取所有群聊數(shù)據(jù)的時(shí)候，我們也是按這個(gè)規(guī)則去尋找所有與本人相關(guān)的群聊，然后循環(huán)去獲取群聊的消息。當(dāng)然這塊要是考慮未讀消息的話，就是通過websocket去獲取未讀消息和當(dāng)前消息的位置差來(lái)做。

當(dāng)有群聊成員退出群聊的時(shí)候，那就需要?jiǎng)h除消息和成員未讀消息的映射關(guān)系。當(dāng)有新成員加入的時(shí)候，那就需要新增消息與成員未讀消息的映射關(guān)系。