CN107592351B - 一种基于Redis的多用户发布订阅方法及系统 - Google Patents

Abstract

本发明公开了一种基于Redis的多用户发布订阅方法及系统，其中该方法包括：接收发布者通过第一频道发布的消息；获取订阅所述第一频道的订阅者的用户状态；如果订阅者离线，将所述消息存储到离线订阅者的未发送消息中；当检测到离线订阅者在线时，从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。本发明重新设计了Redis的发布订阅机制，针对发布订阅涉及到的用户、频道、消息以及用户、频道、消息之间的关联关系采用Redis的相关数据类型来实现存储设计，极大提高了发布订阅过程中的可靠性、持久性和相关信息的读取效率，使得发布订阅机制可以有效应对高并发高访问的情况。

Description

一种基于Redis的多用户发布订阅方法及系统

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种基于Redis的多用户发布订阅方法及系统。

背景技术

随着互联网技术的飞速发展，规模庞大的访问与高并发使得传统的关系数据库难以应对出现的各种问题，而非关系型数据库由于自身的特点能够很好地应对网站大规模数据访问带来的挑战。

目前，一般使用基于RabbitMQ(Message Queue，消息队列)的消息发布订阅模式(pub/sub)，该模式需要经过消息路由与负载均衡算法，进行消息转发，再加上需要可靠性验证，造成在高访问高并发需求下处理速度经常很慢。

Redis是非关系型数据库，属于键值对数据库存储系统。基于Redis的消息发布订阅模式使用通道进行消息发送和接收，没有可靠性机制，可靠性仅依赖于网络服务质量；Redis发布订阅时不存储消息，仅作为信息传输通道，消息既发既丢，消息发送失败或者遇到宕机等灾难，数据难以恢复，未能提供消息的持久化、耐久性等各种企业级的特性。

因此，一种可以应对高并发高访问需求，且消息持久的发布订阅系统有待提出。

发明内容

本发明提供一种基于Redis的多用户发布订阅方法及系统，以提高发布订阅过程的可靠性、持久性和相关信息的读取效率。

第一方面，本发明实施例提供一种基于Redis的多用户发布订阅方法，包括：

接收发布者通过第一频道发布的消息；

获取订阅所述第一频道的订阅者的用户状态；

如果订阅者离线，将所述消息存储到离线订阅者的未发送消息中；

当检测到离线订阅者在线时，从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。

进一步的，在接收发布者通过第一频道发布的消息之前，所述方法还包括：

接收用户输入的账号信息；

登录成功后，获取所述账号信息对应的身份标识；

根据所述身份标识确定所述用户的身份。

进一步的，在根据所述身份标识确定所述用户的身份之后，所述方法还包括：

接收用户输入的订阅信息；

根据所述订阅信息更新所述用户与频道的订阅关系。

进一步的，获取订阅所述第一频道的订阅者的用户状态，包括：

根据用户与频道的订阅关系获取订阅所述第一频道的至少一个订阅者；

根据用户状态信息分别确定所述至少一个订阅者的用户状态，其中所述用户状态包括在线或离线。

进一步的，在根据用户状态信息分别确定所述至少一个订阅者的用户状态之前，所述方法还包括：

采用轮询方式检测各用户的用户状态；

根据检测结果更新所述用户状态信息。

进一步的，在将所述消息存储到离线订阅者的未发送消息中之后，所述方法还包括：

检测所述消息在所述未发送消息中的存储时长是否达到预设时间；

如果是，删除所述消息。

进一步的，在接收发布者通过第一频道发布的消息之后，所述方法还包括：

将所述发布者发布的消息存储到已发布消息中。

第二方面，本发明实施例还提供了一种基于Redis的多用户发布订阅系统，该系统包括：

消息接收模块，用于接收发布者通过第一频道发布的消息；

用户状态获取模块，用于获取订阅所述第一频道的订阅者的用户状态；

消息存储模块，用于在订阅者离线的情况下，将所述消息存储到离线订阅者的未发送消息中；

消息发送模块，用于当检测到离线订阅者在线时，从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。

第三方面，本发明实施例还提供了一种服务器，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明任意实施例所述的基于Redis的多用户发布订阅方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所述的基于Redis的多用户发布订阅方法。

本发明实施例的技术方案，通过重新设计Redis的发布订阅机制，针对发布订阅涉及到的用户、频道、消息以及用户、频道、消息之间的关联关系采用Redis的相关数据类型来实现存储设计，解决了在高访问高并发需求下RabbitMQ的消息订阅发布模式处理速度慢，以及Redis本身的发布订阅消息既发既丢导致系统失败、灾难恢复异常的问题，极大提高了发布订阅过程中的可靠性、持久性和相关信息的读取效率，使得发布订阅机制可以有效应对高并发高访问的情况。

附图说明

图1是本发明实施例一提供的一种基于Redis的多用户发布订阅方法的流程示意图。

图2是本发明实施例二提供的一种基于Redis的多用户发布订阅方法的流程示意图。

图3是本发明实施例三提供的一种基于Redis的多用户发布订阅方法的流程示意图。

图4是本发明实施例四提供的一种基于Redis的多用户发布订阅系统的结构示意图。

图5是本发明实施例四提供的一种基于Redis的多用户发布订阅系统的另一结构示意图。

图6是本发明实施例四提供的一种基于Redis的多用户发布订阅系统中用户状态获取模块的结构示意图。

图7为本发明实施例五提供的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

在介绍各实施例之前，首先对本发明实施例中涉及的概念进行说明。对于多用户发布订阅场景，用户可以是发布者身份和/或订阅者身份，通过频道发布和/或订阅消息。作为发布者的用户，可以向多个频道发布消息；作为订阅者的用户，可以订阅多个频道，接收来自这些频道的消息。在具体应用中，用户可以在用户终端上以网页、客户端或者应用软件等形式使用发布订阅系统，用户终端作为发布消息和/或订阅消息的媒介，与发布订阅服务器进行通信，其中用户终端可以是手机、计算机、平板电脑、智能可穿戴设备等。

实施例一

图1是本发明实施例一提供的一种基于Redis的多用户发布订阅方法的流程示意图，本实施例可适用于多用户发布订阅的情况。该方法可以由基于Redis的多用户发布订阅系统来执行，该系统可以通过软件和/或硬件的形式实现，例如该系统可以设置在服务器中。如图1所示，本实施例的方法具体包括：步骤101至步骤104。

步骤101，接收发布者通过第一频道发布的消息。

其中，第一频道指的是发布者能够发布消息的频道。

步骤102，获取订阅所述第一频道的订阅者的用户状态。

其中，订阅第一频道的订阅者的数量可以是多个，用户状态可以是在线或离线。本步骤可以在接收到发布消息之后就检测订阅者的当前用户状态，也可以在接收到发布消息之后，从定时更新的用户状态信息中获取订阅者的用户状态。

步骤103，如果订阅者离线，将所述消息存储到离线订阅者的未发送消息中。

其中，订阅者离线可以是订阅者暂时离开或退出登录，未发送消息可以列表、文件、队列、键值等形式存储。如果订阅者在线，则直接将消息发送给在线订阅者。

步骤104，当检测到离线订阅者在线时，从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。

其中，离线订阅者在线可以是离线订阅者重新在线或者重新登录。具体的，当检测到离线订阅者在线时，检测该离线订阅者是否存在未发送消息，如果是，则读取未发送消息中存储的消息，发送给该离线订阅者。

本实施例中，通过重新设计Redis的发布订阅机制，系统发送消息之前先获取订阅者的用户状态，订阅者状态为离线时为该用户存储消息，待订阅者上线时向其发送存储的消息。基于Redis的发布订阅机制采用网络直连的方式和linux底层epoll阻塞方式的处理机制，无需经过消息路由，使得Redis的消息处理速度比RabbitMQ要快，解决了在高访问高并发需求下RabbitMQ的消息订阅发布模式处理速度慢的问题；利用离线存储能够实现消息重发，解决了Redis本身的发布订阅消息既发既丢导致系统失败、灾难恢复异常的问题，极大提高了发布订阅过程中消息处理的可靠性、持久性和相关信息的读取效率，使得发布订阅机制可以有效应对高并发高访问的情况。

在上述技术方案的基础上，在步骤101接收发布者通过第一频道发布的消息之前，上述方法还可以包括：接收用户输入的账号信息；登录成功后，获取所述账号信息对应的身份标识；根据所述身份标识确定所述用户的身份。

其中，账号信息可以包括账号、名字和密码，是唯一标识用户的信息。用户的身份可以是发布者和/或订阅者，利用身份标识表示不同的身份，例如，0表示发布者，1表示订阅者。对于用户既是发布者又是订阅者的情况，可以提供入口供用户切换身份，以便执行发布消息或者接收消息的操作。具体的，用户输入账号信息时，系统会判断该用户是否存在，若存在，则登录发布订阅系统；若不存在，则提示用户进行注册，注册之后再登录系统。

进一步的，若用户身份为订阅者，上述方法还可以包括：接收用户输入的订阅信息；根据所述订阅信息更新所述用户与频道的订阅关系。

其中，用户可以根据自己的兴趣爱好选择喜欢的频道，即订阅或取消订阅相关频道。订阅信息是指用户取消订阅某一个或某几个频道，和/或，订阅某一个或某几个频道。系统中会存储用户与频道的订阅关系，用户的订阅信息发生变化，则及时更新用户与频道的订阅关系，保证信息的正常推送与正确推送。

此外，在步骤101接收发布者通过第一频道发布的消息之后，可以将发布者发布的消息存储到该发布者对应的已发布消息中，作为备份，以在需要之时进行重发。

实施例二

图2是本发明实施例二提供的一种基于Redis的多用户发布订阅方法的流程示意图，本实施例在上述实施例的基础上，对步骤102获取订阅者用户状态的具体过程进行了说明，并在步骤103“将所述消息存储到离线订阅者的未发送消息中”之后进一步增加了检测存储时间的操作。如图2所示，本实施例的方法具体包括：步骤201至步骤210。

步骤201，接收发布者通过第一频道发布的消息。

步骤202，根据用户与频道的订阅关系获取订阅第一频道的至少一个订阅者。

步骤203，根据用户状态信息分别确定所述至少一个订阅者的用户状态，其中所述用户状态包括在线或离线。

其中，用户状态信息包括各用户及其当前状态，例如，用户A在线，用户B离线，用户C在线。用户状态信息可以在用户登录或退出登录时更新，也可以通过轮询方式定时检测更新，本实施例中以轮询方式为例进行说明，参见步骤204。

步骤204，采用轮询方式检测各用户的用户状态，根据检测结果更新所述用户状态信息。

具体的，轮询可以是系统在后台按照预设间隔向用户终端发送检测消息，若用户终端有回复，表示用户在线，否则用户不在线。当用户不在线时，将该用户的用户状态设置为离线，当用户重新上线或者登录时，将该用户的用户状态设置为在线，根据轮询的检测结果及时更新用户状态信息，进而保证在用户离线状态下，及时存储该用户订阅的消息，避免消息丢失或漏发，当用户处于在线状态，及时将该用户订阅的消息推送给用户，避免因用户状态错误导致的存储空间浪费。

步骤205，如果订阅者在线，直接将所述消息发送给在线订阅者。

步骤206，如果订阅者离线，将所述消息存储到离线订阅者的未发送消息中。

步骤207，检测所述消息在所述未发送消息中的存储时长是否达到预设时间，如果是，进入步骤208；如果否，进入步骤209。

其中预设时间根据实际情况进行设置，例如可以为7天。具体的，在未发送消息中，会记录消息的存储时间，根据消息的存储时间检测存储时长是否达到预设时间。

步骤208，删除消息。

步骤209，不做任何处理。

步骤210，当检测到离线订阅者在线时，从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。

本实施例中，通过重新设计Redis的发布订阅机制，系统发送消息之前先获取订阅者的用户状态，订阅者状态为离线时为该用户存储消息，待订阅者上线时向其发送存储的消息。基于Redis的发布订阅机制采用网络直连的方式和linux底层epoll阻塞方式的处理机制，无需经过消息路由，使得Redis的消息处理速度比RabbitMQ要快，解决了在高访问高并发需求下RabbitMQ的消息订阅发布模式处理速度慢的问题；利用离线存储能够实现消息重发，解决了Redis本身的发布订阅消息既发既丢导致系统失败、灾难恢复异常的问题，极大提高了发布订阅过程中消息处理的可靠性、持久性和相关信息的读取效率，使得发布订阅机制可以有效应对高并发高访问的情况。另外，本实施例在后台采用轮询方式检测各用户的用户状态且消息存储时长设定固定时间，能够稳定高效地完成发布订阅过程。

在实际应用中,可以键值对的方式存储发布订阅的相关信息,如表1所示。

表1 Redis数据库中存储各信息的数据类型表

其中，Redis数据库中存储的信息主要涉及：用户(User)、频道(Channel)、消息(Message)、用户与频道的关系、用户与消息的关系。表中key的格式设计为“A:${id}:B”，其中${id}代表的是“A”的id，这个key表示的是“A”与“B”的关系，value值是指这个key存放的具体内容，key和value一一对应。示例性的，user:${id}:channel这个key，${id}代表的是不同“user”的id，这个key表示的“user”与“channel”的关系，然后value值存放的是该用户订阅的频道id，这样根据key值得到的value值就是一个用户订阅了的频道集合。String表示字符串数据类型，Hash表示哈希数据类型，Set表示集合数据类型。

user:${id}:id、user:${id}:username、user:${id}:status是与User相关的信息。channel:${id}:channelid、channel:${id}:channelname是与Channel相关的信息。message:${id}:messageid、message:${id}:message是与Message相关的信息。offline:usermessage表示用户与消息的关系，即用户及其离线状态下存储的未发送消息。user:${id}:channel表示用户与频道的关系，即用户订阅了哪些频道。user:${id}:channel:status表示用户状态信息，包括用户是否在线以及用户是否已经读取频道发布的消息。

实施例三

上述各实施例的基础上，本实施例提供一个优选实例，从用户登录的角度对基于Redis的多用户发布订阅方法进行说明。在图3中，虚线表示发布订阅流程与表1中所存信息的交互。如图3所示，包括如下步骤：

步骤301，用户登录系统时，在登录界面输入账号信息，系统接收用户输入的账号信息；

步骤302，判断Redis数据库的User信息中是否存在该用户的id，具体的，判断user:${id}:id这个key中是否存在该用户的id，如果不存在，进入步骤303，如果存在，进入步骤304；

步骤303，提示用户进行注册，注册之后返回步骤301进行登录，并将用户注册的账号信息存储到Redis数据库的User信息中，具体的，将用户id作为value值存储到key值user:${id}:id中，将用户的名字作为value值存储到key值user:${id}:username中，将用户的身份作为value值存储到key值user:${id}:status中；

步骤304，登录成功后，从Redis数据库中获取该账号信息对应的身份标识，根据身份标识确定用户的身份，Redis数据库中使用user:${id}:status这个key值表示用户的身份，value值为0代表发布者，value值为1代表订阅者；如果为发布者，进入步骤305，如果为订阅者，进入步骤307读取未发送消息或者进入步骤309更新订阅关系；

步骤305，用户可以通过频道ChannelA发布消息，并将发布的消息存储在Redis数据库的Message信息中，具体的，将消息id作为value值存储到key值message:${id}:messageid中，将消息的内容作为value值存储到key值message:${id}:message中，进入步骤306；

步骤306，通过Redis数据库的key值user:${id}:channel:status检测到ChannelA的某订阅者离线时，针对离线的订阅者存储该条未发送消息(offline:usermessage)，完成发布的流程。该离线的订阅者上线时，执行步骤307和308，完成离线消息的发送；

步骤307，从Redis数据库的key值user:${id}:channel中查看该用户订阅的频道；

步骤308，从Redis数据库的key值user:${id}:channel:status查看用户是否已经读取所订阅的频道发布的消息，如果存在未读取的，从Redis数据库的key值offline:usermessage查询该用户的未发送消息列表，如果有消息队列，需发送消息给用户，消息队列中的消息存储时长为预设时间，优选为7天，7天后，系统会删除到期的消息；进入步骤310；

步骤309，接收用户输入的订阅信息，订阅新的频道或取消订阅相关频道，根据Redis数据库的Message信息更新用户与频道的订阅关系user:${id}:channel，进入步骤310；

步骤310，结束。

本实施例中，通过重新设计Redis的发布订阅机制，针对发布订阅涉及到的用户、频道、消息以及用户、频道、消息之间的关联关系采用Redis的相关数据类型来实现存储设计。这种机制解决了在高访问高并发需求下RabbitMQ的消息订阅发布模式处理速度慢，以及Redis本身的发布订阅消息既发既丢导致系统失败、灾难恢复异常的问题，极大提高了发布订阅过程中的可靠性、持久性和相关信息的读取效率，使得发布订阅机制可以有效应对高并发高访问的情况。

需要说明的是，本发明任意实施例所述的基于Redis的多用户发布订阅方法，从Redis自带的pub/sub功能进行代码的设计实现，利用Redis的Java客户端Jedis，通过Java语言方式，重写Jedis jar包中的类的相关方法来支持多用户机制，使参与消息传递的发送方与接收方进行代码解耦，并设计了匹配的消息存储机制，实现Redis的发布订阅的相关功能。充分利用了Redis自带的服务器以及pub/sub功能，该通信模型使用广泛，采用事件作为基本的通信机制，稳定高效灵活同时提供了松散的低耦合。

实施例四

图4是本发明实施例四提供的一种基于Redis的多用户发布订阅系统的结构示意图。本实施例所提供的基于Redis的多用户发布订阅系统可以通过软件和/或硬件的形式实现，例如该系统可以设置在服务器中。如图4所示，该系统包括：

消息接收模块401，用于接收发布者通过第一频道发布的消息；

用户状态获取模块402，用于获取订阅所述第一频道的订阅者的用户状态；

消息存储模块403，用于在订阅者离线的情况下，将所述消息存储到离线订阅者的未发送消息中；

消息发送模块404，用于当检测到离线订阅者在线时，从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。

本实施例通过上述模块解决了在高访问高并发需求下RabbitMQ的消息订阅发布模式处理速度慢，以及Redis本身的发布订阅消息既发既丢导致系统失败、灾难恢复异常的问题，极大提高了发布订阅过程中的可靠性、持久性和相关信息的读取效率，使得发布订阅机制可以有效应对高并发高访问的情况。

进一步的，如图5所示，该系统还可以包括：账号信息接收模块405，用于接收用户输入的账号信息；身份标识获取模块406，用于在登录成功后，获取所述账号信息对应的身份标识；身份确定模块407，用于根据所述身份标识确定所述用户的身份。

通过上述账号信息接收模块405、身份标识获取模块406和身份确定模块407，能够实现用户登录发布订阅系统，确定用户身份，以便执行相应的发布消息或接收消息的操作。

进一步的，上述系统还可以包括：订阅信息接收模块408，用于当用户为订阅者时，接收用户输入的订阅信息；更新模块409，用于根据所述订阅信息更新所述用户与频道的订阅关系。

通过上述订阅信息接收模块408和更新模块409，能够及时更新用户与频道的订阅关系，从而实现消息的正确推送。

优选的，上述系统还可以包括：发布消息存储模块410，用于当用户为发布者时，将所述发布者发布的消息存储到已发布消息中，作为备份，以在需要之时进行重发。

优选的，上述系统还可以包括：时间检测模块411，用于检测所述消息在所述未发送消息中的存储时长是否达到预设时间；消息删除模块412，用于在达到预设时间的情况下，删除所述消息。未发送消息存储预设时间则删除，能够保证存储空间的有效利用，避免浪费。

进一步的，如图6所示，用户状态获取模块402可以包括：订阅者获取单元413，用于根据用户与频道的订阅关系获取订阅所述第一频道的至少一个订阅者；用户状态确定单元414，用于根据用户状态信息分别确定所述至少一个订阅者的用户状态，其中所述用户状态包括在线或离线；轮询单元415，用于采用轮询方式检测各用户的用户状态；用户状态更新单元416，用于根据检测结果更新所述用户状态信息。

根据轮询的检测结果及时更新用户状态信息，进而保证在用户离线状态下，及时存储该用户订阅的消息，避免消息丢失或漏发，在用户在线状态下，及时将该用户订阅的消息推送给用户，避免因用户状态错误导致的存储空间浪费。

本实施例提供的一种基于Redis的多用户发布订阅系统可执行本发明任意实施例所提供的基于Redis的多用户发布订阅方法，具备执行方法相应的功能模块和有益效果。

实施例五

图7是本发明实施例五提供的一种服务器的结构示意图，如图7所示，该服务器包括：处理器701、存储器702和通信装置703；服务器中处理器701的数量可以是一个或多个，图7中以一个处理器701为例；服务器中的处理器701、存储器702和通信装置703可以通过总线或其他方式连接，图7中以通过总线连接为例。

存储器702作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的基于Redis的多用户发布订阅方法对应的程序指令/模块(例如，基于Redis的多用户发布订阅系统中的消息接收模块401、用户状态获取模块402、消息存储模块403和消息发送模块404)。处理器701通过运行存储在存储器702中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的基于Redis的多用户发布订阅方法。

存储器702可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器702可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器702可进一步包括相对于处理器701远程设置的存储器，这些远程存储器可以通过网络连接至服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

通信装置703可用于接收用户终端发来的消息，以及向用户终端发送消息。

实施例六

本实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所述的基于Redis的多用户发布订阅方法。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (6)

1.一种基于Redis的多用户发布订阅方法，其特征在于，包括：

接收用户输入的账号信息；

登录成功后，获取所述账号信息对应的身份标识；

根据所述身份标识确定所述用户的身份，所述用户的身份为发布者，和/或，订阅者；

若所述用户的身份为所述订阅者，则接收用户输入的订阅信息，其中，订阅信息是指用户取消订阅某一个或某几个频道，和/或，订阅某一个或某几个频道；

根据所述订阅信息更新所述用户与频道的订阅关系；

接收发布者通过第一频道发布的消息；

根据用户与频道的订阅关系获取订阅所述第一频道的至少一个订阅者；

采用轮询方式检测各用户的用户状态，其中，轮询是系统在后台按照预设间隔向用户终端发送检测消息；

根据检测结果更新所述用户状态信息；

根据用户状态信息分别确定所述至少一个订阅者的用户状态，其中所述用户状态包括在线或离线；

如果订阅者离线，将所述消息存储到离线订阅者的未发送消息中，其中，订阅者离线是订阅者暂时离开或者退出登录；

当检测到离线订阅者在线时，检测所述离线订阅者是否存在未发送消息，若存在，则从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者。

2.根据权利要求1中任一项所述的一种基于Redis的多用户发布订阅方法，其特征在于，在将所述消息存储到离线订阅者的未发送消息中之后，所述方法还包括：

检测所述消息在所述未发送消息中的存储时长是否达到预设时间；

如果是，删除所述消息。

3.根据权利要求1至2中任一项所述的一种基于Redis的多用户发布订阅方法，其特征在于，在接收发布者通过第一频道发布的消息之后，所述方法还包括：

将所述发布者发布的消息存储到已发布消息中。

4.一种基于Redis的多用户发布订阅系统，其特征在于，包括：

账号信息接收模块，用于接收用户输入的账号信息；

身份标识获取模块，用于在登录成功后，获取所述账号信息对应的身份标识；

身份确定模块，用于根据所述身份标识确定所述用户的身份，所述用户的身份为发布者，和/或，订阅者；

消息接收模块，用于接收发布者通过第一频道发布的消息；

用户状态获取模块，包括：订阅者获取单元，用于根据用户与频道的订阅关系获取订阅所述第一频道的至少一个订阅者；用户状态确定单元，用于根据用户状态信息分别确定所述至少一个订阅者的用户状态，其中所述用户状态包括在线或离线；轮询单元，用于采用轮询方式检测各用户的用户状态，其中，轮询是系统在后台按照预设间隔向用户终端发送检测消息；用户状态更新单元，用于根据检测结果更新所述用户状态信息。；

消息存储模块，用于在订阅者离线的情况下，将所述消息存储到离线订阅者的未发送消息中，其中，订阅者离线是订阅者暂时离开或者退出登录；

消息发送模块，用于当检测到离线订阅者在线时，检测所述离线订阅者是否存在未发送消息，若存在，则从所述离线订阅者的未发送消息中读取消息，发送给所述离线订阅者；

订阅信息接收模块，用于若所述用户的身份为所述订阅者，则接收用户输入的订阅信息，其中，订阅信息是指用户取消订阅某一个或某几个频道，和/或，订阅某一个或某几个频道；

更新模块，用于根据所述订阅信息更新所述用户与频道的订阅关系。

5.一种服务器，其特征在于，所述服务器包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-3中任一所述的基于Redis的多用户发布订阅方法。

6.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-3中任一所述的基于Redis的多用户发布订阅方法。

Images