Service message sending method and device, medium, equipment and program product

Abstract

The embodiment of the invention relates to a service message sending method and device, a medium, equipment and a program product. The method comprises the following steps: acquiring a plurality of to-be-sent service messages generated by a service end; the planned sending time of each service message is determined, and the planned sending time of each service message is not completely the same; storing each service message in a preset non-relational database or a preset relational database according to a first time difference between the planned sending time and the current time, and monitoring whether the stored service messages reach the corresponding planned sending time or not; and adding the service message reaching the planned sending time into a preset message queue, and sending the service message in the preset message queue by the service end. According to the technical scheme, the service messages are distributed in batches, and the operation performance of the service end is guaranteed.

Description

Technical Field

[0001] The present disclosure relates to the technical field of data processing, and in particular, to a method, apparatus, medium, device, and program product for sending service messages. Background Art

[0002] To meet the needs of business promotion, it has become increasingly common for the business side to generate and send service messages. For example, in order to promote housing listings, the housing listing business side will send housing listing service information to authorized clients.

[0003] In related technologies, the business client generates multiple service messages at regular intervals and pushes the generated multiple service messages to the client in a centralized manner.

[0004] However, in the above method of pushing service messages to the client in a centralized manner, there may be a large number of clients accessing the business client after receiving the service messages, resulting in a relatively large system processing pressure on the business side and even causing the business side to freeze. Summary of the Invention

[0005] To solve the above technical problems or at least partially solve the above technical problems, the present disclosure provides a method, apparatus, medium, device, and program product for sending service messages.

[0006] An embodiment of the present disclosure provides a method for sending service messages. The method is applied to the server side and includes the following steps: obtaining multiple service messages to be sent generated by the business side; determining the scheduled sending time of each service message, where the scheduled sending times of the service messages are not all the same; storing each service message in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, where the first time differences corresponding to the service messages stored in the preset non-relational database are all less than the first time differences corresponding to the service messages stored in the preset relational database, and monitoring whether the stored multiple service messages reach their corresponding scheduled sending times; adding the service messages that reach the scheduled sending time to a preset message queue, where the business side processes the service messages in the preset message queue for sending.

[0007] An embodiment of the present disclosure provides a method for sending service messages. The method is applied to a service end and includes the following steps: In response to generating a plurality of service messages to be sent, send the plurality of service messages to a server end, where the server end determines the scheduled sending time of each service message, and the scheduled sending times of the respective service messages are not completely the same. Store each service message in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, where the first time differences corresponding to the service messages stored in the preset non-relational database are all less than the first time differences corresponding to the service messages stored in the preset relational database, and add the service messages that reach the scheduled sending time to a preset message queue; perform sending processing on the service messages in the preset message queue.

[0008] An embodiment of the present disclosure further provides a service message sending device. The device is applied to a server end and includes: an acquisition module for acquiring a plurality of service messages to be sent generated by a service end; a determination module for determining the scheduled sending time of each service message, where the scheduled sending times of the respective service messages are not completely the same; a storage module for storing each service message in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, where the first time differences corresponding to the service messages stored in the preset non-relational database are all less than the first time differences corresponding to the service messages stored in the preset relational database; a monitoring module for monitoring whether the stored plurality of service messages reach the corresponding scheduled sending time; a processing module for adding the service messages that reach the scheduled sending time to a preset message queue, where the service end performs sending processing on the service messages in the preset message queue.

[0009] An embodiment of the present disclosure further provides a service message sending device. The device is applied to a service end and includes: a first sending module for, in response to generating a plurality of service messages to be sent, sending the plurality of service messages to a server end, where the server end determines the scheduled sending time of each service message, and the scheduled sending times of the respective service messages are not completely the same. Store each service message in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, where the first time differences corresponding to the service messages stored in the preset non-relational database are all less than the first time differences corresponding to the service messages stored in the preset relational database, and add the service messages that reach the scheduled sending time to a preset message queue; a second sending module for performing sending processing on the service messages in the preset message queue.

[0010] An embodiment of the present disclosure also provides an electronic device, which includes: a processor; a memory for storing executable instructions executable by the processor; the processor is configured to read the executable instructions from the memory and execute the above-mentioned service message sending method.

[0011] An embodiment of the present disclosure also provides a computer-readable storage medium storing a computer program for executing the service message sending method provided by the embodiment of the present disclosure.

[0012] An embodiment of the present disclosure also provides a computer program product including a computer program, which when executed by a processor implements the above-mentioned service message sending method. The technical solution provided by the embodiment of the present disclosure has the following advantages compared with the prior art:

[0013] The service message sending solution provided by the embodiment of the present disclosure obtains a plurality of service messages to be sent generated by a service end, and further determines the scheduled sending time of each service message, where the scheduled sending times of the respective service messages are not completely the same, and each service message is stored in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, where the first time differences corresponding to the service messages stored in the preset non-relational database are all smaller than the first time differences corresponding to the service messages stored in the preset relational database, and monitors whether the stored plurality of service messages reach their corresponding scheduled sending times, and adds the service messages that reach the scheduled sending time to a preset message queue, where the service end performs sending processing on the service messages in the preset message queue. In this technical solution, batch sending of service messages is realized, avoiding simultaneous large-scale access to the service end and ensuring the running performance of the service end. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In combination with the accompanying drawings and with reference to the following specific embodiments, the above and other features, advantages and aspects of the various embodiments of the present disclosure will become more apparent. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the elements and elements are not necessarily drawn to scale.

[0015] Figure 1 It is a flowchart of a service message sending method provided by an embodiment of the present disclosure;

[0016] Figure 2 Another flowchart of a service message sending method provided by an embodiment of the present disclosure;

[0017] Figure 3 Another flowchart of a service message sending method provided by an embodiment of the present disclosure;

[0018] Figure 4Schematic diagram of an interaction scenario for sending service messages provided by an embodiment of the present disclosure;

[0019] Figure 5 Schematic diagram of the structure of a service message sending device provided by an embodiment of the present disclosure;

[0020] Figure 6 Schematic diagram of the structure of another service message sending device provided by an embodiment of the present disclosure;

[0021] Figure 7 Schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. Detailed implementation manners

[0022] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Instead, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

[0023] It should be understood that the various steps recited in the method embodiments of the present disclosure can be executed in a different order and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this regard.

[0024] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to". The term "based on" is "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0025] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence relationship of the functions performed by these devices, modules or units.

[0026] It should be noted that the modifications of "one" and "plural" mentioned in the present disclosure are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly stated in the context, it should be understood as "one or more".

[0027] The names of the service messages or information exchanged between multiple devices in the embodiments of the present disclosure are only for illustrative purposes and are not used to limit the scope of these service messages or information.

[0028] To solve the above problems, embodiments of the present disclosure provide a method for sending service messages.

[0029] For the convenience of description, the above method for sending service messages will be described first on the server side. The method will be introduced below in conjunction with specific embodiments.

[0030] Figure 1 FIG. is a schematic flowchart of a method for sending service messages provided by an embodiment of the present disclosure. This method can be executed by a server, and the device can be implemented by software and / or hardware.

[0031] As Figure 1 shown, the method includes:

[0032] Step 101, obtain multiple service messages to be sent generated by the service side.

[0033] Among them, the service side is a service message side generated according to service requirements.

[0034] In this embodiment, after the service side generates multiple service messages, they are not directly sent to the corresponding client, but sent to the server side to facilitate the server side to allocate the planned sending time for the multiple service messages.

[0035] Step 102, determine the planned sending time for each service message, where the planned sending times of the respective service messages are not completely the same.

[0036] Among them, the planned sending time may include a specific sending time point, or may include a countdown duration from the current time, etc.

[0037] After obtaining multiple service messages, determine the planned sending time for each service message, where the planned sending times of the respective service messages are not completely the same, thereby realizing the batch sending of service messages based on different planned sending times. Among them, in this embodiment, the planned sending times of the respective service messages may be partially the same.

[0038] Step 103, store each service message in a preset non-relational database or a preset relational database according to the first time difference between the planned sending time and the current time, where the first time differences corresponding to the service messages stored in the preset non-relational database are all less than the first time differences corresponding to the service messages stored in the preset relational database, and monitor whether the multiple stored service messages reach their corresponding planned sending times.

[0039] After determining the planned sending time, perform storage processing on the multiple service messages according to the planned sending time, and monitor whether the multiple stored service messages reach their corresponding planned sending times.

[0040] Among them, when storing and processing multiple service messages, the multiple service messages can be stored in different databases. In the scenario where the multiple service messages are stored in different databases, the first time difference between each scheduled sending time and the current time can be determined, where the current time is the time after determining the scheduled sending times of each service message. Each service message is stored in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, and the first time differences corresponding to the service messages stored in the preset non-relational database are all smaller than the first time differences corresponding to the service messages stored in the preset relational database.

[0041] In an embodiment of the present disclosure, it is determined whether the first time difference corresponding to each service message is smaller than a preset time difference threshold according to the first time difference. Among some possible embodiments, when the first time difference is smaller than the preset time difference threshold, it can be determined that the preset hot storage condition is satisfied, and the preset time difference threshold can be calibrated according to the scenario. For example, the preset time difference threshold is 30 minutes, etc.

[0042] In this embodiment, the service messages smaller than the preset time difference threshold are stored in the preset non-relational database, and the preset non-relational database can be a database with relatively high processing performance, such as a Redis database, etc.

[0043] In this embodiment, the service messages not less than the preset time difference threshold are stored in the preset relational database, and the data reading speed of the preset relational database is slower than that of the preset non-relational database. Among some possible embodiments, the preset relational database can be one or more of mysql, mongoDb, TiDB, etc.

[0044] In this embodiment, considering that the preset non-relational database is prone to message loss in the scenario of a large number, but the data speed is accelerated and the processing performance is relatively high. Therefore, the service messages that meet the hot storage condition can be stored in the preset non-relational database, while the preset relational database is not easy to lose data and is a data persistent storage device, but the data reading speed is slow. Therefore, in order to ensure the security of the service messages, etc., the service messages that do not meet the hot storage condition are stored in the preset relational database.

[0045] Step 104, add the service messages that reach the scheduled sending time to the preset message queue, and the service end processes the service messages in the preset message queue for sending.

[0046] In one embodiment of the present disclosure, a preset message queue can be maintained, and service messages that reach the scheduled sending time are added to the preset message queue, that is, each message that reaches the scheduled sending time is added to the end of the preset message queue, so that the service side can process the sending of the service messages in the preset message queue. Since the service messages are batched in advance based on the scheduled sending time, centralized sending of service messages is avoided. Thus, centralized access to the service side is avoided, the processing pressure on the service side is reduced, and the processing efficiency of the service side is improved.

[0047] In some possible embodiments, when storing service messages based on different databases, the second time difference between the scheduled sending time and the real-time time of the service messages in the preset relational database can be monitored, where the real-time time is the currently monitored time. When the second time difference is less than or equal to the corresponding preset time difference threshold, the corresponding service messages are stored in the preset non-relational database, and the corresponding service messages in the preset relational database are deleted from the preset relational database. That is, since the data reading efficiency of the preset non-relational database is relatively high, the service messages near the scheduled sending time can be transferred from the preset relational database to the preset non-relational database. Thus, it is easy to understand that in this embodiment, it is only necessary to monitor whether the service messages in the preset non-relational database reach the corresponding scheduled sending time, and add the service messages in the preset non-relational database that reach the scheduled sending time to the preset message queue.

[0048] Thus, in the embodiment of the present disclosure, before the service side sends service messages to the corresponding client, the server side first allocates the scheduled sending time for the service messages, and then realizes the allocation of service messages based on different scheduled sending times. In this embodiment, the server side can start a thread to continuously monitor whether the service messages in the preset non-relational database reach the corresponding scheduled sending time, add the service messages in the preset non-relational database that reach the scheduled sending time to the preset message queue, and the service side consumes the service messages in the preset message queue.

[0049] In summary, for the service message sending method in the embodiment of the present disclosure, a plurality of service messages to be sent generated by the service side are obtained, and then the scheduled sending time of each service message is determined, where the scheduled sending times of the respective service messages are not completely the same. Each service message is stored in the preset non-relational database or the preset relational database according to the first time difference between the scheduled sending time and the current time, and it is monitored whether the stored plurality of service messages reach the corresponding scheduled sending time, and the service messages that reach the scheduled sending time are added to the preset message queue, where the service side processes the sending of the service messages in the preset message queue. In this technical solution, batch sending of service messages is realized, avoiding a large number of simultaneous accesses to the service side and ensuring the running performance of the service side.

[0050] It should be noted that in different application scenarios, the method for determining the scheduled sending time of each service message is different. Examples are as follows:

[0051] In some possible embodiments, such as Figure 2 shown, determining the scheduled sending time of each service message includes:

[0052] Step 201, determine the message classification strategy corresponding to the service end.

[0053] Among them, the message classification strategy can be determined according to the service messages generated by the service end. For example, for the housing source service end, if the service messages it generates are region-based, then the message classification strategy can be classification by region; for another example, for the shopping service end, if the service messages it generates are based on membership levels, then the message classification strategy can be classification by message level (the message level can be pre-configured by the service end), etc.

[0054] In some possible embodiments, the corresponding relationship between the service type and the message classification strategy can be pre-stored, the service type of the service end can be determined (for example, the service message type generated by region, the message type generated by membership level, etc.), and the corresponding relationship can be queried based on the service type to determine the corresponding message classification strategy.

[0055] Step 202, divide multiple service messages into multiple message sets according to the message classification strategy.

[0056] After determining the message classification strategy, divide multiple service messages into multiple message sets according to the message classification strategy. For example, for the message classification strategy of classification by region, divide multiple service messages into multiple message sets by region.

[0057] Step 203, determine the scheduled sending time of each message set, where the scheduled sending times of different message sets are different, and the scheduled sending times of all service messages in the same message set are the same.

[0058] In this embodiment, the scheduled sending time is determined at the granularity of the message set, that is, determine the scheduled sending time of each message set, where the scheduled sending times of different message sets are different, and the scheduled sending times of all service messages in the same message set are the same.

[0059] In this embodiment, the method for determining the scheduled sending time of each message set is different in different application scenarios. Examples are as follows:

[0060] In some possible examples, multiple message sets can be sorted to obtain a sorting result. Among them, the sorting method can be a random sorting method, etc. In this implementation, the product value of each queuing serial number in the sorting result and a preset unit time interval is calculated, and the product value is used as the planned sending time of the message set.

[0061] Among them, the preset unit time interval can be set according to the scenario. For example, the preset unit time interval can be 10 minutes, etc. When the preset unit time interval is 10 minutes, the planned sending time determined for the message set in the first place in the sorting result is 10 minutes, and the planned sending time determined for the message set in the second place in the sorting result is 20 minutes, etc.

[0062] In some possible embodiments, in order to further avoid receiving a large number of access operations from clients to the service end, multiple message sets can be sorted to obtain a sorting result, the number of messages included in each message set in the sorting result is determined, the reference product value of the number of messages and a preset reference time interval is calculated, and the reference product value is used as the reference planned sending time of the corresponding message set. Among them, the preset reference time interval is a relatively small value. For example, it can be 1 millisecond, etc. Furthermore, the initial planned sending time is determined. For example, the moment 10 minutes after the current moment is determined as the initial moment, and starting from the initial planned sending time, the corresponding reference planned sending time is cumulatively increased in the order from the front to the back in the sorting result to determine the planned sending time of each message set.

[0063] For example, if the initial moment a is determined and the reference planned sending time of the message set in the first place in the sorting result is b, then the planned sending time of the first message set is determined as a + b. If the reference planned sending time of the message set in the second place in the sorting result is c, then the planned sending time of the second message set is determined as a + b + c, etc. Thus, the planned sending time is determined based on the number of messages in the message set, further ensuring the batch sending of service messages and reducing the processing pressure on the service end.

[0064] In some possible examples, determining the planned sending time of each service message includes: obtaining a preset maximum message concurrency, which can be determined according to the processing capacity of the service end. Furthermore, multiple service messages are divided into multiple message sets according to the preset maximum message concurrency, and the multiple message sets are sorted to obtain a sorting result. The product value of each queuing serial number in the sorting result and a preset unit time interval is calculated, and the product value is determined as the planned sending time of the corresponding message set. Among them, the preset unit time interval in this embodiment can be the same as or different from that in the above embodiment.

[0065] In summary, the business message sending method according to the embodiments of the present disclosure can flexibly determine the scheduled sending time of each business message, ensuring subsequent batch sending of business messages based on the scheduled sending time and reducing the processing pressure on the service side.

[0066] Next, the business message sending method according to the embodiments of the present disclosure will be mainly described on the service side. This method is applied to the service side.

[0067] Figure 3 It is a flowchart of a business message sending method provided by the embodiments of the present disclosure. As Figure 3 shown, the method includes:

[0068] Step 301, in response to generating multiple business messages to be sent, send the multiple business messages to the server. The server determines the scheduled sending time of each business message, and the scheduled sending times of the business messages are not completely the same. Each business message is stored in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time. The first time differences corresponding to the business messages stored in the preset non-relational database are all smaller than the first time differences corresponding to the business messages stored in the preset relational database, and the business messages that reach the scheduled sending time are added to a preset message queue.

[0069] In an embodiment of the present disclosure, after the service side generates multiple business messages to be sent, it does not directly send the business messages to the client, but sends the multiple business messages to the server. The server determines the scheduled sending time of each business message, and the scheduled sending times of the business messages are not completely the same. The multiple business messages are stored and processed according to the scheduled sending time, and the business messages that reach the scheduled sending time are added to a preset message queue. The storage and processing method can refer to the above embodiments and will not be elaborated here.

[0070] Step 302, perform a sending process on the business messages in the preset message queue.

[0071] In this embodiment, the service side consumes the business messages in the preset message queue and performs a sending process on the business messages in the preset message queue.

[0072] In some possible embodiments, the business messages can be read one by one in the order from the front to the back in the preset message queue, and the target client of each business message is determined, and the corresponding business message is sent to the target client, etc.

[0073] In some possible embodiments, corresponding service messages can be obtained from a preset message queue according to the maximum message concurrency. Among them, if the number of service messages to be sent in the preset message queue is less than the maximum message concurrency, all service messages in the preset message queue are obtained, and the target clients corresponding to all service messages are synchronously determined, and the corresponding service messages are sent to the corresponding service clients. If the number of service messages to be sent in the preset message queue is not less than the maximum message concurrency, the service messages with the maximum message concurrency in the preset message queue are obtained, and the target clients corresponding to the corresponding service messages are synchronously determined, and the corresponding service messages are sent to the corresponding service clients.

[0074] Thus, based on the planned sending time determined asynchronously by the server, batch sending of service messages can be achieved, avoiding concurrent access operations from clients at the same time, etc., and reducing the processing pressure on the service side.

[0075] To facilitate a more comprehensive understanding of the service message sending of the present disclosure, the message sending process will be exemplarily described below in combination with specific embodiments. In this example, the preset non-relational database is a Redis database, the preset relational database is a mysql database, and the preset hot storage condition is that the duration from the current moment to the planned sending time is less than 30 minutes. The description is as follows:

[0076] Refer to Figure 4 , after multiple service messages to be sent are generated at the service side, the server obtains the multiple service messages sent by the service side. Furthermore, the server sorts the multiple message sets to obtain a sorting result, calculates the product value of each queuing serial number in the sorting result and a preset unit time interval, determines the product value as the planned sending time of the corresponding message set, determines the first time difference between each planned sending time and the current moment, and stores the service messages with a time difference less than 30 minutes in the Redis database.

[0077] The service messages with a time difference not less than 30 minutes are stored in the mysql database. Among them, the second time difference between the service messages in the mysql database and the real-time moment is monitored in real time, and the service messages with a second time difference less than or equal to 30 minutes are transferred to the Redis database (the corresponding service messages in the mysql database no longer exist).

[0078] It is monitored whether the service messages in the Redis database reach the planned sending time. If the planned sending time is reached, the corresponding service messages are sent to the preset message queue, and the service side consumes the service messages in the preset message queue, that is, processes the service messages in the preset message queue and sends the corresponding service messages to the corresponding clients.

[0079] In summary, in the business message sending method of the embodiments of the present disclosure, in response to generating multiple business messages to be sent, multiple business messages are sent to the server. Among them, the server determines the scheduled sending time of each business message, and the scheduled sending times of the respective business messages are not completely the same. Each business message is stored in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time. The first time differences corresponding to the business messages stored in the preset non-relational database are all smaller than the first time differences corresponding to the business messages stored in the preset relational database, and the business messages that reach the scheduled sending time are added to a preset message queue. Furthermore, the business messages in the preset message queue are processed for sending. In this technical solution, batch sending of business messages is achieved, ensuring the operating performance of the service end.

[0080] To implement the above embodiments, the present disclosure also proposes a business message sending device.

[0081] Figure 5 As a schematic structural diagram of a business message sending device provided by the embodiments of the present disclosure, the device can be implemented by software and / or hardware and is generally integrated in a server. As Figure 5 shown, the device includes: an acquisition module 510, a determination module 520, a storage module 530, a monitoring module 540, and a processing module 550, where

[0082] The acquisition module 510 is configured to acquire multiple business messages to be sent generated by the service end;

[0083] The determination module 520 is configured to determine the scheduled sending time of each business message, where the scheduled sending times of the respective business messages are not completely the same;

[0084] The storage module 530 is configured to store each business message in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time, where the first time differences corresponding to the business messages stored in the preset non-relational database are all smaller than the first time differences corresponding to the business messages stored in the preset relational database;

[0085] The monitoring module 540 is configured to monitor whether the multiple stored business messages reach their corresponding scheduled sending times;

[0086] The processing module 550 is configured to add the business messages that reach the scheduled sending time to a preset message queue, where the service end processes the business messages in the preset message queue for sending.

[0087] The service message sending device provided by the embodiments of the present disclosure can execute the service message sending method provided on the server side in any embodiment of the present disclosure, and has the corresponding functional modules and beneficial effects for executing the method.

[0088] To implement the above embodiments, the present disclosure also proposes a service message sending device.

[0089] Figure 6 As shown in the structure schematic diagram of a service message sending device provided by an embodiment of the present disclosure, the device can be implemented by software and / or hardware, and is generally integrated at the service end. Figure 6 As shown, the device includes: a first sending module 610 and a second sending module 620, where

[0090] The first sending module 610 is configured to, in response to generating a plurality of service messages to be sent, send the plurality of service messages to a server, where the server determines the scheduled sending time of each service message, and the scheduled sending times of the respective service messages are not completely the same. Each service message is stored in a preset non-relational database or a preset relational database according to the first time difference between the scheduled sending time and the current time. The first time differences corresponding to the service messages stored in the preset non-relational database are all smaller than the first time differences corresponding to the service messages stored in the preset relational database, and the service messages that reach the scheduled sending time are added to a preset message queue;

[0091] The second sending module 620 is configured to perform a sending process on the service messages in the preset message queue.

[0092] The service message sending device provided by the embodiments of the present disclosure can execute the service message sending method provided on the service end in any embodiment of the present disclosure, and has the corresponding functional modules and beneficial effects for executing the method.

[0093] To implement the above embodiments, the present disclosure also proposes a computer program product, including a computer program / instructions, where when the computer program / instructions are executed by a processor, the service message sending method in the above embodiments is implemented.

[0094] To implement the above embodiments, the present disclosure also proposes a computer-readable storage medium, where a computer program is used to execute the above service message sending method.

[0095] To implement the above embodiments, the present disclosure also proposes an electronic device, where the electronic device includes: a processor; a memory for storing executable instructions that can be executed by the processor; and the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the above service message sending method.

[0096] Figure 7A schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. Among them, the electronic device may be the above-mentioned server side or service side.

[0097] Specifically refer to Figure 7 , which shows a schematic structural diagram of an electronic device 700 suitable for implementing the embodiments of the present disclosure. The electronic device 700 in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), PMPs (Portable Multimedia Players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The electronic device shown is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present disclosure.

[0098] As Figure 7 shown, the electronic device 700 may include a processor (such as a central processing unit, a graphics processing unit, etc.) 701, which may perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 702 or the program loaded from the memory 708 into the random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 are also stored. The processor 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. The input / output (I / O) interface 705 is also connected to the bus 704.

[0099] Generally, the following devices may be connected to the I / O interface 705: an input device 706 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 707 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a memory 708 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 709. The communication device 709 may allow the electronic device 700 to communicate with other devices wirelessly or wiredly to exchange data. Although Figure 7 shows the electronic device 700 having various devices, it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices may be implemented or had.

[0100] In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 709, or installed from the memory 708, or installed from the ROM 702. When the computer program is executed by the processor 701, the above functions defined in the service message sending method of the embodiment of the present disclosure are executed.

[0101] It should be noted that the above computer-readable medium in the present disclosure can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, apparatus, or device. In the present disclosure, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program codes. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, and the computer-readable signal medium can send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The program codes contained on the computer-readable medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0102] The above computer-readable medium can be included in the above electronic device; or it can exist separately without being assembled into the electronic device.

[0103] The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by the electronic device, the electronic device is caused to execute the service message sending method centralized on the server side or the service side.

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a portion of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur in an order different from that noted in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0105] The units described in the embodiments of the present disclosure can be implemented in software or in hardware. Wherein, the name of the unit does not constitute a limitation to the unit itself in some cases.

[0106] The functions described above can be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that can be used include: Field Programmable Gate Arrays (FPGA), Application Specific Integrated Circuits (ASIC), Application Specific Standard Products (ASSP), System on Chip (SOC), Complex Programmable Logic Devices (CPLD), and so on.

[0107] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles applied. Those skilled in the art should understand that the scope of the disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosure concept. For example, technical solutions formed by mutually replacing the above features with (but not limited to) technical features having similar functions disclosed in the present disclosure.

[0108] Moreover, although the operations are depicted in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in a sequential order. In certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the foregoing discussion, these should not be construed as limitations on the scope of the present disclosure. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0109] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims.

Claims

1. A method for sending a business message, characterized in that: The method is applied on the server side and includes the following steps: Obtain multiple business messages to be sent generated by the business end; Determining a planned sending time of each of the service messages, wherein the planned sending times of the service messages are not exactly the same; storing each of the service messages in a preset non-relational database or a preset relational database according to the first time difference between the planned sending time and the current time, wherein the first time difference corresponding to the service messages stored in the preset non-relational database is smaller than the first time difference corresponding to the service messages stored in the preset relational database, and monitoring whether the stored multiple service messages reach the corresponding planned sending time; The service message that reaches the scheduled sending time is added to a preset message queue, wherein the service end performs sending processing on the service message in the preset message queue.

2. The method according to claim 1, characterized in that The storing each of the service messages in a preset non-relational database or a preset relational database according to the first time difference between the planned sending time and the current time includes: Determine whether the first time difference value corresponding to each of the service messages is less than a preset time difference threshold; Business messages less than the preset time difference threshold are stored in the preset non-relational database, and business messages not less than the preset time difference threshold are stored in the preset relational database, wherein the data reading speed of the preset relational database is lower than the data reading speed of the preset non-relational database.

3. The method according to claim 1, characterized in that Also includes: Monitoring a second time difference between a planned sending time and a real time of a service message in the preset relational database; When the second time difference is less than or equal to the preset time difference threshold, the corresponding service message is stored in the preset non-relational database, and the corresponding service message is deleted from the preset relational database.

4. The method according to any one of claims 1 to 3, characterized in that: The step of adding the service message that reaches the scheduled sending time to the preset message queue includes: Monitor whether the business message in the preset non-relational database reaches the corresponding planned sending time; The service messages in the preset non-relational database that have reached the scheduled sending time are added to the preset message queue.

5. The method according to claim 1, characterized in that Determining the planned sending time of each of the service messages includes: Determining a message classification strategy corresponding to the service end; Dividing the multiple business messages into multiple message sets according to the message classification strategy; Determine the planned sending time of each message set, wherein different message sets have different planned sending times, and all business messages in the same message set have the same planned sending time.

6. The method according to claim 5, characterized in that Determining the planned sending time of each message set includes: Sorting the multiple message sets to obtain a sorting result; The product value of each queue sequence number in the sorting result and the preset unit time interval is calculated, and the product value is determined as the planned sending time of the corresponding message set.

7. A method for sending a business message, characterized in that: The method is applied on the business end and includes the following steps: In response to generating multiple business messages to be sent, sending the multiple business messages to a server, wherein the server determines a planned sending time of each of the business messages, wherein the planned sending times of the various business messages are not exactly the same, and storing each of the business messages in a preset non-relational database or a preset relational database according to a first time difference between the planned sending time and the current time, wherein the first time difference corresponding to the business messages stored in the preset non-relational database is less than the first time difference corresponding to the business messages stored in the preset relational database, and adding the business messages that reach the planned sending time to a preset message queue; Send and process the business messages in the preset message queue.

8. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the service message sending method described in any one of claims 1-8.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is used to execute the service message sending method described in any one of claims 1-8.

10. A computer program product, characterized in that It includes a computer program, which, when executed by a processor, implements the service message sending method described in any one of claims 1 to 7.

Images