一种循环推送提醒消息的方法和装置
技术领域
本发明涉及计算机技术领域，尤其涉及一种循环推送提醒消息的方法和装置。
背景技术
目前随着业务的发展，很多业务场景对时效的要求在不断提高，比如订单接单、订单出库等。这些业务场景在单据下发到作业端系统时，需要推送提醒消息到相应的作业端，以提醒操作人员尽快进行处理。由于作业现场环境差异较大，提醒消息需要进行多次循环提醒，直到操作人员对业务进行处理，保证业务在规定时间内进行。
现有的作业端循环推送提醒消息的方式主要为：在前端浏览器JavaScript代码中定时发送ajax请求轮询服务端的方式进行消息提醒，其中，轮询是指客户端定时向服务器发送ajax请求，服务器接到请求后马上返回响应信息并关闭连接。服务端在接到请求后到数据库查询该请求对应业务的相关数据，并根据查询的数据向前端返回信息，前端接到服务端响应后进行判断是否需要提醒。其中，服务端返回是数据是一个“有”或者“没有”的一个标记，例如true、false，然后前端收到服务端的响应后，如果是true则进行提醒、false则不提醒，具体的提醒方式由前端处理。
上述现有技术，存在以下技术问题：多次轮询服务端会导致服务端以及数据库的压力增加，当并发量增加时此问题尤为突出；消息提醒的时间间隔定义到前端JavaScript代码中，如果有多个业务需要提醒并且提醒的周期不一致的话需要在前端定义多个定时器发送ajax请求，造成资源的浪费，并且不便于开发维护；由于不用的业务提醒需要查询不同的数据，现有方案需要为每个业务定义一个查询服务，开发维护非常不方便。
发明内容
有鉴于此，本发明实施例提供一种循环推送提醒消息的方法和装置，能够直接根据解析的循环推送请求的参数信息，确定对应的路由信息并根据该路由信息将参数信息中的待提醒消息推送至前端，后端服务不需要定义查询服务。可对任何业务和连接的前端推送提醒消息，不需要在前端定义多个计时器，也不需要专门定义接口给前端进行轮询以及不需要前端判断哪些需要提醒、如何提醒等。解决了现有技术中多次轮询服务端导致服务端、数据库压力增加的问题，并且便于开发维护。
为实现上述目的，根据本发明实施例的一个方面，提供了一种循环推送提醒消息的方法。
本发明实施例的循环推送提醒消息的方法包括：接收循环推送请求，解析所述循环推送请求确定其参数信息，所述参数信息中至少包括循环周期、路由标识以及待提醒消息；根据所述循环周期和路由标识，定时在第一数据库中查找对应的路由信息；所述第一数据库用于在前端与分布式服务集群中的服务节点建立连接时，存储其路由信息；根据所述路由信息调用所述分布式服务集群中的服务节点，使得该服务节点将所述待提醒消息推送至对应的前端。
可选地，根据所述循环周期和路由标识，定时在第一数据库中查找对应的路由信息的步骤包括：将接收的循环推送请求的待提醒消息发送至消息队列；消费所述消息队列中的待提醒消息，并根据当前消费的待提醒消息的循环周期生成延迟推送任务；基于所述延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息。
可选地，基于所述延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息的步骤包括：通过时间轮保存所述延迟推送任务，使得所述时间轮定时处理保存的延迟推送任务；对于当前处理的延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息；和/或，所述消息队列为Kafka。
可选地，在根据当前消费的循环推送请求的循环周期生成延迟推送任务之前，还包括：根据接收的循环推送请求对应的待提醒消息的消息标识，将待提醒消息保存至第二数据库；其中，参数信息中还包括待提醒消息的消息标识；对于当前消费的待提醒消息，根据其消息标识确定所述第二数据库中存在对应的待提醒消息。
可选地，还包括：接收关闭推送请求，解析所述关闭推送请求确定其对应的循环推送请求的消息标识；根据所述消息标识在所述第二数据库中查找对应的循环推送请求的待提醒消息；将查找的对应的循环推送请求的待提醒消息进行删除。
可选地，所述分布式服务集群为Websocket服务集群；和/或，所述第一数据库为Redis数据库。
为实现上述目的，根据本发明实施例的另一个方面，提供了一种循环推送提醒消息的装置。
本发明实施例的循环推送提醒消息的装置包括：
请求接收模块，用于接收循环推送请求，解析所述循环推送请求确定其参数信息，所述参数信息中至少包括循环周期、路由标识以及待提醒消息；
路由确定模块，用于根据所述循环周期和路由标识，定时在第一数据库中查找对应的路由信息；所述第一数据库用于在前端与分布式服务集群中的服务节点建立连接时，存储其路由信息；
消息推送模块，用于根据所述路由信息调用所述分布式服务集群中的服务节点，使得该服务节点将所述待提醒消息推送至对应的前端。
可选地，所述路由确定模块还用于，将接收的循环推送请求的待提醒消息发送至消息队列；消费所述消息队列中的待提醒消息，并根据当前消费的待提醒消息的循环周期生成延迟推送任务；以及，基于所述延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息。
可选地，所述路由确定模块还用于，通过时间轮保存所述延迟推送任务，使得所述时间轮定时处理保存的延迟推送任务；对于当前处理的延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息；和/或，所述消息队列为Kafka。
可选地，所述路由确定模块还用于，根据接收的循环推送请求对应的待提醒消息的消息标识，将待提醒消息保存至第二数据库；其中，参数信息中还包括待提醒消息的消息标识；对于当前消费的待提醒消息，根据其消息标识确定所述第二数据库中存在对应的待提醒消息。
可选地，还包括请求关闭模块，用于接收关闭推送请求，解析所述关闭推送请求确定其对应的循环推送请求的消息标识；根据所述消息标识在所述第二数据库中查找对应的循环推送请求的待提醒消息；将查找的对应的循环推送请求的待提醒消息进行删除。
可选地，所述分布式服务集群为Websocket服务集群；和/或，所述第一数据库为Redis数据库。
为实现上述目的，根据本发明实施例的再一个方面，提供了一种电子设备。
本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一项的循环推送提醒消息的方法。
为实现上述目的，根据本发明实施例的再一个方面，提供了一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现上述任一项的循环推送提醒消息的方法。
上述发明中的一个实施例具有如下优点或有益效果：可直接根据解析的循环推送请求的参数信息，确定对应的路由信息并根据该路由信息将参数信息中的待提醒消息推送至前端，所以后端服务不需要定义查询服务。以及，在前端与分布式服务集群中的服务节点建立连接时，已将其路由信息存储在数据库，所以对于处理的循环推送请求，根据其参数信息中的路由标识即可在数据库中查找到其对应的路由信息，进一步根据该路由信息调用对应的服务节点，以将待提醒消息推送至对应的前端。并且，该待提醒消息是确定需要提醒的消息，不需要前端判断哪些需要提醒、如何提醒等。本发明实施例将推送的计时方式改为由服务端确定，因此可对任何业务和连接的前端发送提醒消息，不需要在前端定义多个计时器，也不需要专门定义接口给前端进行轮询。
上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1是根据本发明实施例的循环推送提醒消息的方法的主要流程的示意图；
图2是根据本发明实施例的循环推送提醒消息的方法实现系统的架构示意图；
图3是根据本发明实施例的前端与分布式服务集群中的服务节点建立连接时序的示意图；
图4是根据本发明实施例的前端与分布式服务集群中的服务节点断开连接时序的示意图；
图5是根据本发明实施例的循环推送提醒消息时序的示意图；
图6是根据本发明实施例的循环推送提醒消息的装置的主要模块的示意图；
图7是本发明实施例可以应用于其中的示例性系统架构图；
图8是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
图1是根据本发明实施例的循环推送提醒消息的方法的主要流程的示意图，如图1所示，本发明实施例的循环推送提醒消息的方法主要包括：
步骤S101：接收循环推送请求，解析循环推送请求确定其参数信息，参数信息中至少包括循环周期、路由标识以及待提醒消息。接收到消息推送者发送的循环推送请求后，通过对其解析可得到其参数信息，参数信息中的循环周期是推送提醒消息的周期，该参数信息中还可包括周期时间单位，但也采用默认的周期时间单位，例如分钟、30秒等。参数信息中的路由标识用于唯一标识第一数据库中存储的路由信息，例如前端的唯一ID(UUID)，用于消息推送的时候进行路由判断的路由字段route等，也可是UUID和route的组合。参数信息中的待提醒消息是指需要循环向前端推送的消息。消息推送者在发送的循环推送请求的参数信息中包括待提醒消息(消息体)，可直接将待提醒消息保存到Redis中，例如在向前端推送消息时回传入的消息实体。该待提醒消息是确定需要提醒的消息，不需要前端接收到推送的消息后判断哪些需要提醒、如何提醒等。
步骤S102：根据循环周期和路由标识，定时在第一数据库中查找对应的路由信息。第一数据库用于在前端与分布式服务集群中的服务节点建立连接时，存储其路由信息。当用户连接到分布式服务集群中的服务节点时，保存连接信息(包括路由信息)，当用户退出浏览器和服务节点断开连接时注销连接信息。连接信息保存到Redis数据库中，使用Set集合结构，每个UUID+route对应一个集合，保存当前UUID和路由字段连接的分布式服务集群中的服务节点的节点信息，该节点信息包括连接的服务节点的节点IP和端口。其中，
Rediskey为：WEB_SOCKET_SESSION_CACHE_[UUID][ROUTE]，
RedisSet中每个value为：[节点IP]:[端口],如:192.168.1.1:80
具体的，将接收的循环推送请求的待提醒消息发送至消息队列。消费消息队列中的待提醒消息，并根据当前消费的待提醒消息的循环周期生成延迟推送任务。基于延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息。
基于延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息的步骤包括：通过时间轮保存延迟推送任务，使得时间轮定时处理保存的延迟推送任务。对于当前处理的延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息。
消息队列为Kafka。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。具有高性能、持久化、多副本备份、横向扩展能力。生产者往队列里写消息，消费者从队列里取消息进行业务逻辑，起到解耦、削峰、异步处理的作用。也进一步解决了现有技术中对于并发量增加的情况时，难以应对系统压力的问题。以及，对于Kafka中存在大量的延迟操作，可基于时间轮自定义一个用于实现延迟功能的定时器(SystemTimer)。Kafka中的时间轮(TimingWheel)是一个存储定时任务的环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表(TimerTaskList)。
在根据当前消费的循环推送请求的循环周期生成延迟推送任务之前，根据接收的循环推送请求的消息标识，将循环推送请求保存至第二数据库。其中，参数信息中还包括消息标识。对于当前消费的待提醒消息，根据其消息标识确定第二数据库中存在对应的待提醒消息。在本发明实施例中，第一数据库和第二数据库可以为同一个数据库，也可为不同的数据。进一步，第一数据库或第二数据库为Redis数据库。以及，根据其消息标识确定第二数据库中存在对应的循环推送请求，说明该提醒消息对应的业务还没有完成，仍需要按照循环周期继续推送提醒消息。如果该提醒消息对应的业务已经完成，则可人工或者根据关闭推送请求自动将第二数据库中存储的循环推送请求删除。
例如，对于订单A入库的业务进行循环推送提醒消息，其循环周期是5，待提醒消息为“订单A入库”，默认周期时间单位为小时，则从当前时刻起5个小时内，每隔一小时向用户作业端推送“订单A入库”。但是如果在第3个小时内，已完成订单A的入库，则可将该待提醒消息从第二数据库删除。在完成该业务时间点后的下次提醒时，则会判断出第二数据库中不存在对应该业务的循环推送请求，则不继续进行无效提醒。
本发明实施例中，根据关闭推送请求自动将第二数据库中存储的循环推送请求删除步骤包括：接收关闭推送请求，解析关闭推送请求确定其对应的循环推送请求的消息标识。根据消息标识在第二数据库中查找对应的循环推送请求，并且将查找的对应的循环推送请求的待提醒消息进行删除。通过上述过程，避免出现无效提醒的情况。
步骤S103：根据路由信息调用分布式服务集群中的服务节点，使得该服务节点将待提醒消息推送至对应的前端。
分布式服务集群为Websocket服务集群。WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。以及，websocket是浏览器与服务端建立全双工的通信方式，解决http请求-响应带来过多的资源消耗，并且对对实时性要求较高的行业领域提供了全新的实现方式。
本发明实施例，可直接根据解析的循环推送请求的参数信息，确定对应的路由信息并根据该路由信息将参数信息中的待提醒消息推送至前端，所以后端服务不需要定义查询服务。以及，在前端与分布式服务集群中的服务节点建立连接时，已将其路由信息存储在数据库，所以对于处理的循环推送请求，根据其参数信息中的路由标识即可在数据库中查找到其对应的路由信息，进一步根据该路由信息调用对应的服务节点，以将待提醒消息推送至对应的前端。并且，该待提醒消息是确定需要提醒的消息，不需要前端判断哪些需要提醒、如何提醒等。本发明实施例将推送的计时方式改为由服务端确定，因此可对任何业务和连接的前端推送提醒消息，不需要在前端定义多个计时器，也不需要专门定义接口给前端进行轮询。解决了现有技术中多次轮询服务端导致服务端、数据库压力增加的问题，并且便于开发维护。
图2是根据本发明实施例的循环推送提醒消息的方法实现系统的架构示意图；图3是根据本发明实施例的前端与分布式服务集群中的服务节点建立连接时序的示意图；图4是根据本发明实施例的前端与分布式服务集群中的服务节点断开连接时序的示意图；图5是根据本发明实施例的循环推送提醒消息时序的示意图。
本发明实施例可将消息推送服务单独部署，避免对生产环境的影响，方便扩展。如图2所示，本发明实施例的循环推送提醒消息的方法实现系统主要包括：Websocket集群服务、WebSocketSession注册服务、消息推送路由服务和循环消息推送服务。其中，Websocket集群服务用于和浏览器端进行websocket通信。WebSocketSession注册服务用于注册当前连接到websocket集群中的session信息，包括UUID，路由字段，连接信息等。消息路由服务用于将消息提醒通过路由字段发送到相应的浏览器。循环消息推送服务，在接收后端消息推送的请求的情况下，保存消息，调用消息推送路由服务查找websocket的连接信息等。
以及，WebSocket集群服务的实现是基于WebSocket集群的，其中包含多个提供服务的节点，如图2中示出的节点一和节点二，每个节点都包含WebSocket服务(WS服务)HTTP服务以及保持连接到当前节点的WebSocketSession的组件。其中，WebSocket服务主要用于和作业端浏览器进行通信。HTTP服务用于提供消息推送路由服务调用提醒消息到当前节点的服务。在本发明实施例中，使用Nginx对多个节点进行负载均衡，浏览器连接WebSocket集群服务中的节点时，通过域名连接到Nginx服务，再由Nginx负载到对应的节点。WebSocket集群连接URL(统一资源定位符)如下：ws://域名/ws/{uuid}/{route}。UUID：当前连接客户端的唯一ID；route：路由字段，用于消息推送的时候进行路由判断。
WebSocketSession注册服务，主要用于保存浏览器与WebSocket集群服务中节点的连接信息，该连接信息包括连接到的WebSocket集群中具体节点的服务器的IP和端口，用于后续消息路由到具体的服务器。当有用户连接到集群时，保存连接信息。当用户退出浏览器和集群连接断开时，注销连接信息。如图3和图4所示，前端浏览器连接到WebSocket集群中的服务节点时，该服务节点调用WebSocket Session注册服务将连接信息保存到Redis数据库中。浏览器和WebSocket集群中的服务节点断开连接时，该服务节点调用WebSocketSession注册服务将连接信息从Redis中删除。
在本发明实施例中，将连接信息保存到Redis中，可使用Set集合结构，每个UUID+route对应一个集合，保存通过当前UUID和路由字段连接到集群中的节点信息。
Rediskey为：WEB_SOCKET_SESSION_CACHE_[UUID][ROUTE]
RedisSet中每个value为：[节点IP]:[端口],如:192.168.1.1:80
消息推送路由服务，主要用于连接WebSocket集群服务和循环消息推送服务。在消息推送路由服务调用路由推送消息时，通过WebSocketSession注册服务提供的查询注册地址的服务，查询对应的所有的注册的WebSocket节点地址，然后遍历节点地址集合，调用节点提供的HTTP服务推送提醒到对应的节点，节点接收到推送请求后调用当前节点保存的WebSocketSession推送消息到浏览器。
循环消息推送服务主要包括：对外接口、Kafka消息发送组件、保存消息信息、消费Kafka消息、时间轮、延时消息处理器六个部分。其中，对外接口提供两种协议的RPC接口和HTTP接口，每个接口可接收循环推送请求和关闭循环推送请求。由于提供了多种对外接口的支持，可方便多种接口直接电泳。循环推送请求的入参如下表所示：
Kafka消息发送组件用于发送循环推送请求到Kafka，Kafka用于消息推送请求和推送组件解耦，Kafka topic为：wsp-cycle-message。Kafka是一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据。保存消息信息，可将消息保存到Redis中，使用Hash结构，每个UUID+route对应一个map。
Rediskey为：CYCLE_MESSAGE_[UUID][ROUTE]
Redismap中key为：messageId，value为：消息推送入参的JSON字符串。
消费Kafka消息用于消费Kafka中的消息。时间轮用于保存延时推送的消息，循环消息推送服务启动时需要启动时间轮服务。延时消息处理器用于调用路由推送消息到相应节点。Redis还可保存Session信息以及待推送提醒消息。
如图5所示，消息推送者调用对外接口，发送循环推送请求。通过该对外接口，调用循环消息推送服务，使得循环消息推送服务推送消息至Kafka。对于高吞吐量场景，可能会不断的有消息推送者调用对外接口发送循环推送请求，因此循环消息推送服务可不断的将接收到提醒消息推送至Kafka。以及，循环消息推送服务将接收到的循环推送请求保存至Redis。循环消息推送服务接收到循环推送请求后，可根据其路由标识、消息标识将该待提醒消息保存至Redis。
消费Kafka消息的过程中，首先根据其消息标识在Redis中查询消息，判断Redis中是否存在其对应的待提醒消息，如果不存在，说明对应业务已经往常，不需要再进行无效提醒。如果存在，则将延迟消息推送任务添加至时间轮。
时间轮触发延迟消息推送服务器，该迟消息推送服务器调用消息推送路由服务。然后，消息推送路由服务根据路由标识查找路由信息，并且根据该路由信息查询要推送的浏览器注册的服务节点。进一步，调用WebSocket集群节点提供的HTTP接口将消息推送到对应的节点，最后Websocket集群节点会将消息推送到相应的浏览器。以及，消息推送路由服务将此次完成的提醒消息推送至Kafka。
基于本发明实施例，使用WebSocket协议连接后不需要进行ajax轮询的方式定时查询后端服务。并且，将推送的计时方式改为由服务端来计时，不需要在前端定义多个计时器。以及，业务代码不需要专门定义接口给前端进行轮询，只需要在希望推送消息的地方调用推送服务提供的接口即可。通过websocket、时间轮环形结构实现循环推送提醒消息。并且，通过消息队列(kafka)、路由和Redis结合的方式实现在分布式环境中定向推送提醒消息。
图6是根据本发明实施例循环推送提醒消息的装置的主要模块的示意图，如图6所示，本发明实施例的循环推送提醒消息的装置600包括请求接收模块601、路由确定模块602和消息推送模块603。
请求接收模块601用于，收循环推送请求，解析循环推送请求确定其参数信息，参数信息中至少包括循环周期、路由标识以及待提醒消息。
路由确定模块602用于，根据循环周期和路由标识，定时在第一数据库中查找对应的路由信息。第一数据库用于在前端与分布式服务集群中的服务节点建立连接时，存储其路由信息。路由确定模块还用于，将接收的循环推送请求的待提醒消息发送至消息队列；消费消息队列中的待提醒消息，并根据当前消费的待提醒消息的循环周期生成延迟推送任务。以及，基于延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息。
路由确定模块还用于，通过时间轮保存延迟推送任务，使得时间轮定时处理保存的延迟推送任务；对于当前处理的延迟推送任务，根据路由标识定时在第一数据库中查找对应的路由信息。消息队列可以为Kafka。
路由确定模块在根据当前消费的循环推送请求的循环周期生成延迟推送任务之前，还用于根据接收的循环推送请求的消息标识，将循环推送请求保存至第二数据库。其中，参数信息中还包括消息标识。并且，对于当前消费的待提醒消息，根据其消息标识确定第二数据库中存在对应的待提醒消息。
本发明实施例的循环推送提醒消息的装置还包括请求关闭模块，请求关闭模块用于接收关闭推送请求，解析关闭推送请求确定其对应的循环推送请求的消息标识。以及，根据消息标识在第二数据库中查找对应的循环推送请求；将查找的对应的循环推送请求的待提醒消息进行删除。
消息推送模块603用于，根据路由信息调用分布式服务集群中的服务节点，使得该服务节点将待提醒消息推送至对应的前端。
分布式服务集群为Websocket服务集群。第一数据库为Redis数据库。在本发明实施例中第一数据库与第二数据库可以为同一个数据库，并且都可为Redis数据库。
本发明实施例，路由确定模块可直接根据请求接收模块解析的循环推送请求的参数信息，确定对应的路由信息，消息推送模块根据该路由信息将参数信息中的待提醒消息推送至前端，所以后端服务不需要定义查询服务。以及，在前端与分布式服务集群中的服务节点建立连接时，已将其路由信息存储在数据库，所以对于处理的循环推送请求，路由确定模块根据其参数信息中的路由标识即可在数据库中查找到其对应的路由信息。进一步，消息推送模块根据该路由信息调用对应的服务节点，以将待提醒消息推送至对应的前端。并且，该待提醒消息是确定需要提醒的消息，不需要前端判断哪些需要提醒、如何提醒等。本发明实施例将推送的计时方式改为由服务端确定，因此可对任何业务和连接的前端推送提醒消息，不需要在前端定义多个计时器，也不需要专门定义接口给前端进行轮询。解决了现有技术中多次轮询服务端导致服务端、数据库压力增加的问题，并且便于开发维护。
图7示出了可以应用本发明实施例的循环推送提醒消息的方法或循环推送提醒消息的装置的示例性系统架构700。
如图7所示，系统架构700可以包括终端设备701、702、703，网络704和服务器705。网络704用以在终端设备701、702、703和服务器705之间提供通信链路的介质。网络704可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备701、702、703通过网络704与服务器705交互，以接收或发送消息等。终端设备701、702、703上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备701、702、703可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器705可以是提供各种服务的服务器，例如对用户利用终端设备701、702、703所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果反馈给终端设备。
需要说明的是，本发明实施例所提供的循环推送提醒消息的方法一般由服务器705执行，相应地，循环推送提醒消息的装置一般设置于服务器705中。
应该理解，图7中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
下面参考图8，其示出了适于用来实现本发明实施例的终端设备的计算机系统800的结构示意图。图8示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。
以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本发明的系统中限定的上述功能。
需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括请求接收模块、路由确定模块和消息推送模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，请求接收模块还可以被描述为“接收循环推送请求，解析所述循环推送请求确定其参数信息的模块”。
作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：接收循环推送请求，解析循环推送请求确定其参数信息，参数信息中至少包括循环周期、路由标识以及待提醒消息；根据循环周期和路由标识，定时在第一数据库中查找对应的路由信息；第一数据库用于在前端与分布式服务集群中的服务节点建立连接时，存储其路由信息；根据路由信息调用分布式服务集群中的服务节点，使得该服务节点将待提醒消息推送至对应的前端。
本发明实施例，可直接根据解析的循环推送请求的参数信息，确定对应的路由信息并根据该路由信息将参数信息中的待提醒消息推送至前端，所以后端服务不需要定义查询服务。以及，在前端与分布式服务集群中的服务节点建立连接时，已将其路由信息存储在数据库，所以对于处理的循环推送请求，根据其参数信息中的路由标识即可在数据库中查找到其对应的路由信息，进一步根据该路由信息调用对应的服务节点，以将待提醒消息推送至对应的前端。并且，该待提醒消息是确定需要提醒的消息，不需要前端判断哪些需要提醒、如何提醒等。本发明实施例将推送的计时方式改为由服务端确定，因此可对任何业务和连接的前端推送提醒消息，不需要在前端定义多个计时器，也不需要专门定义接口给前端进行轮询以及不需要前端判断哪些需要提醒、如何提醒等。解决了现有技术中多次轮询服务端导致服务端、数据库压力增加的问题，并且便于开发维护。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。
