CN109039732B - Message processing system and message processing method - Google Patents
Message processing system and message processing method Download PDFInfo
- Publication number
- CN109039732B CN109039732B CN201810833499.2A CN201810833499A CN109039732B CN 109039732 B CN109039732 B CN 109039732B CN 201810833499 A CN201810833499 A CN 201810833499A CN 109039732 B CN109039732 B CN 109039732B
- Authority
- CN
- China
- Prior art keywords
- threads
- live
- thread
- group
- sending
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
Abstract
The invention discloses a message processing system and a message processing method, wherein the message processing system comprises: a first set of live threads for servicing messages sent to a first service object; a second set of live threads for providing services for sending messages to the second service object; a first switching module, configured to execute thread switching in the first group of live threads/the second group of live threads in response to a single thread fault of the first group of live threads/the second group of live threads; a second switching module to merge service objects of a failed group into service objects of a non-failed group in response to a failure of one of the first set of live threads and the second set of live threads. By adopting the invention, the problem that the message cannot be sent in time due to faults can be reduced or even avoided, and the invention is beneficial to the targeted processing for different types of merchants.
Description
Technical Field
The present invention relates to the field of message processing, and more particularly, to a message processing system and a message processing method.
Background
Existing message processing has drawbacks in some specific application scenarios. Taking a common online payment scenario as an example, online payment is a mainstream payment method, and after an individual customer completes online payment, an online bank sends a merchant notification, that is, order information, a payment state, and the like, to a merchant. Due to the instability of the internet, the merchant notification is occasionally failed, commonly called 'drop order', and in order to avoid 'drop order', the notification of the failure needs to be sent again.
In the prior art, when the notification is sent again, the normal reception of the merchant is ensured by using a single-thread resending notification. However, for payment transactions with large transaction amount, in the prior art, if the thread is abnormal, the notification of the merchant is out of order, which may cause a large amount of single-side accounts and easily cause business disputes; meanwhile, when some merchant networks with large transaction amount are abnormal, too much data waiting for the notification retransmission can be caused, and other merchant notifications are seriously delayed or cannot be sent out. The existing single-threaded retransmission notification technology obviously cannot solve the problems.
In addition, the single-thread notification mechanism lacks flexibility, and cannot realize targeted processing for different types of merchants.
Disclosure of Invention
In view of the foregoing defects in the prior art, embodiments of the present invention provide a message processing system and a message processing method, which can reduce or even avoid the problem that a message cannot be sent in time due to a failure, and are beneficial to performing targeted processing for different types of merchants.
Specifically, an embodiment of the present invention provides a message processing system, including:
a first set of live threads for servicing messages sent to a first service object;
a second set of live threads for providing services for sending messages to the second service object;
a first switching module, configured to execute thread switching in the first group of live threads/the second group of live threads in response to a single thread fault of the first group of live threads/the second group of live threads;
a second switching module to merge service objects of a failed group into service objects of a non-failed group in response to a failure of one of the first set of live threads and the second set of live threads.
Correspondingly, the embodiment of the invention also provides a message processing method, which comprises the following steps:
providing a service for sending messages to a first service object through a first set of live-active threads;
providing a service for sending messages to the first service object through the second set of live-active threads;
wherein a thread switch in the first/second set of live threads is performed in response to a single thread fault in the first/second set of live threads;
wherein in response to a failure of one of the first set of live-active threads and the second set of live-active threads, incorporating the service object of the failed group into the service object of the non-failed group.
Accordingly, the embodiment of the present invention also provides a message processor, which includes a memory and a processor, wherein the memory is used for storing one or more computer instructions, and the processor is used for calling and executing the one or more computer instructions from the memory so as to implement the message processing method as described above.
In addition, the embodiment of the present invention also provides a computer storage medium, which stores computer instructions, and the computer instructions implement the message processing method as described above when executed.
By adopting the embodiment of the invention, different double-active thread groups are set for different service objects, which is beneficial to realizing the personalized processing aiming at different service objects. By switching to another thread of the same group to continue providing service when one thread of the same group crashes, and by switching to another thread of the same group to continue processing when one thread of the same group fails, the normal operation is favorably ensured. In addition, the control of the execution authority of the double-active thread is provided through the uniqueness controller, and the system confusion and deadlock caused by resource contention among threads are avoided; by carrying out prejudgment before sending the message and executing probability sending if necessary, the occupation of system resources is reduced and the utilization efficiency of the resources is improved.
Drawings
FIG. 1 is a block diagram of a message processing system according to an embodiment of the present invention;
FIG. 2 is a block diagram of a message processing apparatus according to an embodiment of the present invention;
FIG. 3 is a flow chart illustrating a message processing method according to an embodiment of the present invention;
FIG. 4 is a block diagram of a merchant notification and retransmission mechanism according to an embodiment of the present invention;
fig. 5 is a block diagram of a message processor according to an embodiment of the present invention.
Detailed Description
In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention.
In some of the flows described in the present specification and claims and in the above figures, a number of operations are included that occur in a particular order, but it should be clearly understood that these operations may be performed out of order or in parallel as they occur herein, with the order of the operations being indicated as 101, 102, etc. merely to distinguish between the various operations, and the order of the operations by themselves does not represent any order of performance. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, program modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different.
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Variations, modifications, and the like based on the embodiments of the present invention are within the scope of the present invention.
Fig. 1 is a block diagram of a message processing system according to an embodiment of the present invention. Referring to fig. 1, the message processing system includes a first set of live threads 10, a second set of live threads 12, a first switch module 14, and a second switch module 16. The details will be described below.
In this embodiment, a first set of live threads 10 is used to service sending messages to a first service object and a second set of live threads 12 is used to service sending messages to a second service object. The first service object and the second service object are different types of service objects, and can be configured as different object lists. As to how to classify specifically, the classification can be flexibly processed according to specific scenes, requirements and the like, which is not specifically limited in the present application.
In this embodiment, the first switching module 14 is configured to execute a thread switch in the first set of live threads/the second set of live threads in response to a single thread fault of the first set of live threads/the second set of live threads. That is, for each set of live threads, if one single thread fails, the single thread which does not fail is switched to continue processing.
In this embodiment, the second switching module 16 is configured to merge the service object of the failed group into the service object of the non-failed group in response to a failure of one of the first set of live threads and the second set of live threads. Thus, when a set of live threads crashes, the service objects of the live threads of the failed set may be serviced by the non-failed set of live threads.
Optionally, in an implementation manner of this embodiment, the thread groups are not limited to two live threads, and each of the two live thread groups employs the switching mechanism provided in this embodiment.
By adopting the system provided by the embodiment, different live thread groups are set for different service objects, which is beneficial to realizing personalized processing aiming at different service objects. Through the double-live thread and the first switching module, when one thread in the same group crashes, the other thread in the same group can be switched to continue to provide service; through two or more groups of double-active threads and the second switching module, when one group of double-active threads fails, the double-active threads can be switched to the other group of double-active threads for processing continuously. This provides a favorable guarantee for normal operation.
Optionally, in an implementation manner of this embodiment, two single threads in the first group of live-active threads/the second group of live-active threads poll the execution permission information to determine a current executable thread. The execution authority information includes, for example, a unique code and a thread occupying the unique code. As shown by the dashed box in FIG. 1, the first switch module 14 may include a uniqueness controller for setting the thread occupying the uniqueness code and changing the thread occupying the uniqueness code in response to a failure of the thread occupying the uniqueness code.
By adopting the realization mode, the control of the execution authority of the double-active thread is provided through the uniqueness controller, and the system confusion and deadlock caused by resource contention among threads are avoided.
Optionally, in an implementation manner of this embodiment, the system further includes a message sending apparatus as shown in fig. 2, where the message sending apparatus includes a prejudging module 20, a sending module 22, and a counting module 24. The prejudging module 20 is configured to judge whether a target object (an object receiving a message) falls into a grey list; the sending module 22 is configured to send a message to a target object, where probability sending is performed when the target object falls into the gray list; the statistic module 24 is configured to update the unreachable times of the target object according to the sending result of the sending module, and update the grey list according to the unreachable times.
As an application of this implementation, the message sending apparatus may be used to send a message to a target object, and if the sending fails, the failed message is recorded in a retransmission message queue, and then the first group of live threads/the second group of live threads are used to send the message.
As an application of this implementation, the message sending apparatus shown is multiplexed when sending a message using the first group of live-active threads/the second group of live-active threads.
By adopting the implementation mode, the efficiency of merchant notification can be ensured through the grey list and the probability sending mechanism, and the accumulation of invalid notification and retransmission queues is reduced.
Fig. 3 is a flowchart illustrating a message processing method according to an embodiment of the present invention. Referring to fig. 3, the method includes:
300: the sending of the message to the first service object is serviced by the first set of live-active threads.
302: the second service object is served by the second set of live threads for sending messages to the second service object.
304: performing a thread switch in the first set of live-active threads/second set of live-active threads in response to a single thread fault in the first set of live-active threads/second set of live-active threads.
306: in response to a failure of one of the first set of live-active threads and the second set of live-active threads, merging the service object of the failed group into the service object of the non-failed group.
Of course, although the method provided in this embodiment is illustrated in the form of a flowchart, in practice, the sequence of 300-306 is not strictly executed.
By adopting the method provided by the embodiment, different live thread groups are set for different service objects, which is beneficial to realizing personalized processing aiming at different service objects. By switching to another thread of the same group to continue providing service when one thread of the same group crashes, and by switching to another thread of the same group to continue processing when one thread of the same group fails, the normal operation is favorably ensured.
Optionally, in an implementation manner of this embodiment, two single threads in the first group of live-active threads/the second group of live-active threads poll the execution permission information to determine a current executable thread. The execution authority information comprises a unique code and a thread occupying the unique code; the method further comprises the following steps: setting a thread occupying the unique code and changing the thread occupying the unique code in response to a failure of the thread occupying the unique code. By adopting the implementation mode, the control of the execution authority of the double-active thread is provided, and the system confusion and deadlock caused by resource contention among threads are avoided.
Optionally, in an implementation manner of this embodiment, the method further includes: judging whether the target object falls into a grey list or not; sending a message to a target object, wherein probability sending is performed when the target object falls into the gray list; and updating the unreachable times of the target object according to the sending result, and updating the grey list according to the unreachable times. By adopting the implementation mode, the efficiency of merchant notification can be ensured through the grey list and the probability sending mechanism, and the accumulation of invalid notification and retransmission queues is reduced.
A specific application of the embodiment of the present invention is described in detail below with an example of application to merchant notification retransmission.
The merchant notification is an important means for online payment of the merchant to update the order state, and plays a significant role in an online payment system. The traditional realization mode of merchant notification is that the online bank background sends order information to a merchant feedback address through a post request, and after the notification fails, the merchant notification thread resends the order information as a supplementary notification means. Some systems realize a retransmission mechanism of merchant notification mechanically, single-point failure is caused by single-thread transmission, and when a network is unstable and a single drop occurs, a notification thread is busy, so that the phenomenon of serious delay of merchant notification is caused, and account checking of online payment merchants is seriously influenced.
For the above problem, in this embodiment, the notification of the merchant is mainly completed by the cooperative work of multiple groups of live threads, and the threads are divided into three types: 1) the general merchant notifies the retransmission thread: the method is mainly used for informing general online payment merchants, reading the information of the retransmission queue for merchant notification retransmission; 2) the key merchant notifies the retransmission thread: independently sending merchant notice for key merchants in the retransmission queue; 3) customizing the merchant notification retransmission thread: and sending the timed notification for the merchant needing to send the timed notification in the retransmission queue.
Each group of notification threads has a respective service merchant list, the merchant list is configurable, and the timing notification time interval for customizing the merchant notification retransmission threads is also configurable. Although merchants and functions of the three groups of thread services are different, when one group of threads is crashed, the merchant information of the merchant list served by the threads can be adjusted into the merchant lists of the other two groups of threads to continue to execute the services, and the functions of the three groups of threads are mutually complemented.
And the three groups of merchants inform that the retransmission threads are all dual-active deployment, and the execution authority of the threads is judged by the uniqueness controller. When one thread in the same group breaks down, another thread in the same group can obtain the execution authority to continue providing the service.
When the merchant notification is sent, the reachability prejudging device of the merchant notification sending module is called to prejudge the reachability, and invalid merchant notification sending is reduced.
A general architecture diagram of the merchant notification and its retransmission mechanism is shown in fig. 4. This is explained in detail below with reference to fig. 4.
After the online payment transaction is completed, a merchant notification is sent, the online payment module calls the notification sending module to send the notification, the notification sending module calls the prejudging device to prejudge the accessibility when executing each notification, invalid notification sending is reduced, data accumulation waiting for a retransmission queue is reduced, and merchant notification efficiency is improved. The reachability prejudger mainly takes the steps of checking the number of times of non-attainability and a grey list and executing probability transmission as main working means, and the related parts are described as follows:
1): before sending the merchant notification each time, checking whether the notification address of the merchant is in a grey list, if so, sending the merchant notification with a probability of 10% (the probability value is only an example), and discarding 90% of the probabilities, thereby avoiding that the merchant which is unreachable occupies notification sending resources of other normal merchants, and simultaneously, intercepting whether the merchant notification address is recovered to be smooth.
2): checking the number of times of being unreachable after sending the merchant notification every time, if the notification is unreachable, increasing the number of times of being unreachable by 1 for the merchant notification address, and putting into a grey list when a preset threshold value is reached; if the number of times of reaching is up, the number of times of reaching is clear 0, and the name is removed by a grey list.
3): the grey list and the unreachable times are stored in a server memory and are realized based on a java hash table (hashtable), the grey list and the unreachable times have effective duration, after the effective duration is over, the grey list is invalid, the unreachable times are clear 0, the merchant notifies that the unreachable times and the grey list are not sent in probability any more, but the unreachable times and the grey list are checked according to the step 2) in each sending.
When the merchant notification fails to be sent, the notification sending module inserts the failed notification into a merchant notification retransmission queue of the database. The three groups of retransmission notification threads select the failure notification of the corresponding commercial tenant to retransmit according to the commercial tenant list configured by the three groups of retransmission notification threads, and the multiplexing notification sending module and the reachability prejudging device are used for sending the failure notification during retransmission.
The three groups of retransmission notification threads are provided with merchant lists configured respectively, merchant information can be switched among the three merchant lists, namely merchants can customize and use each type of merchant notification thread, and more importantly, when one type of merchant notifies the retransmission threads to be broken down, the merchants can be switched into the merchant lists of the other two types of merchant notification threads, so that notification thread resource sharing is realized, and high availability is further kept. For example, the major merchant notification retransmission threads P1 and P2 crash, the merchant information corresponding to the major merchant notification retransmission threads may be switched from the merchant list to the merchant list of the general merchant notification retransmission threads, and then the general merchant notification retransmission threads T1 and T2 continue to execute the notification.
Meanwhile, each group of merchant notification threads are double-live threads, when one thread in the same group crashes, the other thread can obtain the execution authority to continue providing service, and the execution authority is determined by the uniqueness controller. For example, the universal merchant notifies the retransmission threads T1 and T2, determines the execution authority through the uniqueness controller, ensures that T1 operates, waits for T2, complements each other, and when T1 crashes, the uniqueness controller switches to acquire the execution authority through T2, continues to execute the merchant notification retransmission, and maintains high availability. This is true for both the focused merchant notification retransmission threads P1, P2 and the customized merchant notification retransmission threads C1, C2.
The same group of merchants inform the double-live threads in the retransmission threads, for example, the general merchant informs the retransmission threads T1 and T2, which are deployed on two thread servers in physical architecture, and the execution authority of the two thread machines is controlled by a unique controller. The uniqueness controller stores the uniqueness code and the thread server information occupying the code by using a database, and judges whether the current thread has the execution authority, and the related contents are described as follows:
1): the double-active thread polls whether the access uniqueness code is occupied or not, and the execution authority adopts a rule of first-come first-obtained. For example, the unique code of the live threads T1 and T2 is a 'SHTZ' character string, the two threads poll the 'SHTZ' together to determine whether the thread occupies the character string, and if the T1 is accessed first, the controller associates the server information of the 'SHTZ' and the T1 and keeps the server information in the database to inform the T1 that the T1 can execute; t2, the controller is accessed, and the controller checks that "SHTZ" in the database is occupied by T1, and informs T2 that it is not executable. The two-thread continues to perform polling.
2): the active threads do not stop polling, when one thread crashes, the other thread can obtain the execution authority to continue executing the merchant notification task. For example, the monitoring finds that the T1 in the live threads T1 and T2 crashes, and can flush (or can flush manually) the thread server information of "SHTZ" in the database, at this time, T2 polls the uniqueness controller, the controller checks that "SHTZ" is not occupied, and then associates "SHTZ" with the server information of T2 and keeps in the database, and informs T2 that it is executable, and high availability of merchant notification is maintained through live complementation.
Embodiments of the system and method of the present invention have been described in detail above. In another embodiment of the present invention, a message processor is provided as shown in FIG. 5, the message processor comprising a memory and a processor. Wherein the memory is configured to store one or more computer instructions, and the processor is configured to retrieve and execute the one or more computer instructions from the memory to implement the methods provided by the method embodiments of the present invention. Optionally, the message processor may further include an input-output interface for data communication.
In addition, the embodiment of the present invention also provides a computer storage medium, which stores one or more computer instructions, and when the computer instructions are executed, the computer storage medium implements the method provided by the method embodiments of the present invention.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described method, system and program module may be mutually referred to or correspond, and are not described herein again.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.
Claims (10)
1. A message processing system, the system comprising:
a first set of live threads for servicing messages sent to a first service object;
a second set of live threads for providing services for sending messages to the second service object;
a first switching module, configured to execute thread switching in the first group of live threads/the second group of live threads in response to a single thread fault of the first group of live threads/the second group of live threads;
a second switching module to merge service objects of a failed group into service objects of a non-failed group in response to a failure of one of the first set of live threads and the second set of live threads.
2. The system of claim 1,
and polling the execution authority information by two single threads in the first group of double-active threads/the second group of double-active threads to determine the current executable thread.
3. The system of claim 2,
the execution authority information comprises a unique code and a thread occupying the unique code;
the first switching module includes a uniqueness controller for setting a thread occupying the uniqueness code and changing the thread occupying the uniqueness code in response to a failure of the thread occupying the uniqueness code.
4. The system of any one of claims 1-3, further comprising:
the prejudgment module is used for judging whether the target object falls into a grey list or not;
a sending module, configured to send a message to a target object, where probability sending is performed when the target object falls into the gray list;
and the statistical module is used for updating the unreachable times of the target object according to the sending result of the sending module and updating the grey list according to the unreachable times.
5. A method of message processing, the method comprising:
providing a service for sending messages to a first service object through a first set of live-active threads;
providing a service for sending a message to a second service object through a second set of live threads;
wherein a thread switch in the first/second set of live threads is performed in response to a single thread fault in the first/second set of live threads;
wherein in response to a failure of one of the first set of live-active threads and the second set of live-active threads, incorporating the service object of the failed group into the service object of the non-failed group.
6. The method of claim 5, wherein the method further comprises:
and polling the execution authority information by two single threads in the first group of double-active threads/the second group of double-active threads to determine the current executable thread.
7. The method of claim 6,
the execution authority information comprises a unique code and a thread occupying the unique code;
the method further comprises the following steps: setting a thread occupying the unique code and changing the thread occupying the unique code in response to a failure of the thread occupying the unique code.
8. The method of any one of claims 5-7, further comprising:
judging whether the target object falls into a grey list or not;
sending a message to a target object, wherein probability sending is performed when the target object falls into the gray list;
and updating the unreachable times of the target object according to the sending result, and updating the grey list according to the unreachable times.
9. A message processor, comprising:
a memory for storing one or more computer instructions;
a processor for invoking and executing the one or more computer instructions from the memory to implement the method of any one of claims 5-8.
10. A computer storage medium having stored thereon one or more computer instructions which, when executed, implement the method of any one of claims 5-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810833499.2A CN109039732B (en) | 2018-07-26 | 2018-07-26 | Message processing system and message processing method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810833499.2A CN109039732B (en) | 2018-07-26 | 2018-07-26 | Message processing system and message processing method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109039732A CN109039732A (en) | 2018-12-18 |
| CN109039732B true CN109039732B (en) | 2021-07-23 |
Family
ID=64646494
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810833499.2A Active CN109039732B (en) | 2018-07-26 | 2018-07-26 | Message processing system and message processing method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109039732B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111078433A (en) * | 2019-12-12 | 2020-04-28 | 中国建设银行股份有限公司 | Merchant notification sending method and device and electronic equipment |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104683460A (en) * | 2015-02-15 | 2015-06-03 | 青岛海尔智能家电科技有限公司 | Communication method, device and server for Internet of things |
| CN105279640A (en) * | 2014-07-07 | 2016-01-27 | 世纪禾光科技发展（北京）有限公司 | System and method of cross-border payment multi-store service state notification |
| CN106936688A (en) * | 2015-12-30 | 2017-07-07 | 北京国双科技有限公司 | Notice sending method and device |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050050305A1 (en) * | 2003-08-28 | 2005-03-03 | Kissell Kevin D. | Integrated mechanism for suspension and deallocation of computational threads of execution in a processor |
-
2018
- 2018-07-26 CN CN201810833499.2A patent/CN109039732B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105279640A (en) * | 2014-07-07 | 2016-01-27 | 世纪禾光科技发展（北京）有限公司 | System and method of cross-border payment multi-store service state notification |
| CN104683460A (en) * | 2015-02-15 | 2015-06-03 | 青岛海尔智能家电科技有限公司 | Communication method, device and server for Internet of things |
| CN106936688A (en) * | 2015-12-30 | 2017-07-07 | 北京国双科技有限公司 | Notice sending method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109039732A (en) | 2018-12-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108200544B (en) | Short message issuing method and short message platform | |
| CN111104235B (en) | Queue-based asynchronous processing method and device for service requests | |
| US9736034B2 (en) | System and method for small batching processing of usage requests | |
| CN111698158B (en) | Method and device for electing master equipment and machine-readable storage medium | |
| US10389801B2 (en) | Service request processing method, related apparatus, and system | |
| KR20150086649A (en) | Apparatus and method for distribution processing of data, storage server | |
| US20030158883A1 (en) | Message processing | |
| CN110769040B (en) | Access request processing method, device, equipment and storage medium | |
| US9846618B2 (en) | System and method for supporting flow control in a distributed data grid | |
| US20230046979A1 (en) | Microservice call method and apparatus, device, and medium | |
| CN109039732B (en) | Message processing system and message processing method | |
| CN111552543A (en) | Container management and control method and processing node | |
| CN111314443A (en) | Node processing method, device and equipment based on distributed storage system and medium | |
| CN113867915A (en) | Task scheduling method, electronic device and storage medium | |
| CN108241616B (en) | Message pushing method and device | |
| CN111124593B (en) | Information processing method and device, network element and storage medium | |
| WO2020252724A1 (en) | Log processing method and device, and computer-readable storage medium | |
| CN110635968A (en) | Monitoring method, device and equipment for stacked double-active detection channel and storage medium | |
| CN112615901B (en) | Method for sending user request by client and storage system | |
| US20160261476A1 (en) | Message system for avoiding processing-performance decline | |
| CN109634787B (en) | Distributed file system monitor switching method, device, equipment and storage medium | |
| CN105426118B (en) | A kind of method that serial ports backup heartbeat passage is utilized in double-control system | |
| CN114237910A (en) | Client load balancing implementation method and device | |
| US20110289165A1 (en) | Method, apparatus and computer program for message handling | |
| CN117478600B (en) | Flow control method and system for serving high concurrency multi-center business center |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |