《redis in action》发布和订阅-技术圈

《redis in action》发布和订阅

共 1105字，需浏览 3分钟

· 2021-05-10

之前我们说redis中的发布订阅有点问题，问题就是会存在消息丢失的问题。当时我们说还有几个参数。而且redis的发布订阅的时候，信道的断路的问题也是消息丢失的原因之一。那么如何诸如QQ这种发布订阅的问题如何用redis去解决。这里咋大概的想一下这个问题。

首先第一步是如何实现一个端到端的发布订阅，也就是说像我们的消息队列这种的发布订阅。这个就比较容易了，直接使用List数据结构即可完成。我们让消费者从队列中获取数据即可。说白了就是我们的前边说的消息队列，如果用来描述QQ中的用户对用户的聊天，那么用该队列即可，因为list具有顺序，那么消息也就自带了时间特色。

第二种发布和订阅就是多个客户端都要去接受消息了，这种模式就类似QQ中的群聊。考虑到我们的消息不能重复存储，原因是我们的用户数量很大，那么消息只能唯一存储，但是用户与消息的关系就只能通过映射去维护。如果是我的话，我可能会用时间戳来序列化存储消息，而且消息发送的时候肯定是需要加分布式锁的。但是消息发送到群中去，每个人读到的消息肯定不是实时的，有可能A已经读完了所有消息，B还有几条没读。这时候A和B显示的未读消息数应该是不一样的。所以说我们存储群消息和群中的人员的关系的时候肯定要保留用户所读取到的消息的位置。当未读消息位置没有达到现有消息的位置的时候，应该要进行提示。这块必然走得是HTTP1.1或者其他websocket技术。我们再来梳理一下发送消息的步骤。

第一我们要创建群聊，确定那些人是我们要发送消息的对象。拿到这些信息之后，我们针对这些人创建群聊消息id和群聊成员id之间消息的读取位置id信息。因为我们的消息保存要有顺序，那么我们可以采用zset进行存储。其score可以针对一个redis变量进行累计得出，这样我们的消息就是有序列的。

在群聊成员获取消息的时候，必然是一次性获取所有群聊的数据。所以在上边说的群聊和成员的关系维护上，我们必然要按照一定的规则去做。所以在获取所有群聊数据的时候，我们也是按这个规则去寻找所有与本人相关的群聊，然后循环去获取群聊的消息。当然这块要是考虑未读消息的话，就是通过websocket去获取未读消息和当前消息的位置差来做。

当有群聊成员退出群聊的时候，那就需要删除消息和成员未读消息的映射关系。当有新成员加入的时候，那就需要新增消息与成员未读消息的映射关系。