CN112988546A - Fusing scheme and system for preventing service avalanche of payment system - Google Patents
Fusing scheme and system for preventing service avalanche of payment system Download PDFInfo
- Publication number
- CN112988546A CN112988546A CN202110432068.7A CN202110432068A CN112988546A CN 112988546 A CN112988546 A CN 112988546A CN 202110432068 A CN202110432068 A CN 202110432068A CN 112988546 A CN112988546 A CN 112988546A
- Authority
- CN
- China
- Prior art keywords
- service
- state
- fuse
- downstream
- module
- 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.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
The invention provides a fusing scheme for preventing service avalanche for a payment system, which comprises the following steps: step S1, reporting the health status of each service in the payment system; step S2, the upstream service calls the downstream service; step S3, the upstream service reads the health status of the downstream service; step S4, the upstream service reads the fuse state of the downstream service; step S5, starting a maintenance thread and maintaining the accessible state of the fuse state of the downstream service; step S6, the upstream service recalls the fuse state as the downstream service of the trial state again; the invention can effectively prevent service avalanche of the payment system.
Description
Technical Field
The invention relates to the technical field of computer payment safety, in particular to a fusing scheme and a fusing system for preventing service avalanche in a payment system.
Background
In the payment system, the system does not complete all functions by a single site, and the system is divided into a plurality of independent services from the aspect of business, including order service, commodity inventory service and user point service, and is a distributed system. Under the condition of high system access pressure, one service of the system responds slowly, and the requests from other services cannot be processed in time, so that the requests are accumulated, and the whole system is possibly dragged down. The fault service is continuously requested by other services, so that the fault service has no chance of breathing, even if the service is restarted, a large amount of instantaneous flow requests come in, and the fault service may be down again to cause an avalanche phenomenon.
Disclosure of Invention
To overcome the above problems, it is an object of the present invention to provide a fusing scheme for preventing service avalanche of a payment system, which can effectively prevent service avalanche of the payment system.
The invention is realized by adopting the following scheme: a fusing scheme for a payment system to prevent service avalanches, the scheme comprising the steps of: step S1, reporting the health status of each service in the payment system;
step S2, the upstream service calls the downstream service;
step S3, the upstream service reads the health status of the downstream service;
step S4, the upstream service reads the fuse state of the downstream service;
step S5, starting a maintenance thread and maintaining the accessible state of the fuse state of the downstream service;
step S6, the upstream service recalls the fuse state again as a downstream service in an atternable state.
Further, the step S1 is further specifically: each service in the payment system starts a thread, and the health state is reported to the etcd circularly and regularly.
Further, the step S2 is further specifically: the upstream service refers to a caller, the downstream service refers to a callee, and the caller and the callee change with different steps of the payment system.
Further, the step S3 is further specifically: the upstream service reads the corresponding downstream service health state from the etcd, determines whether the health state range of the downstream service is between 5s and 10s, if so, pushes a short message to a responsible person, restarts the fault service and performs intervention recovery; otherwise, the downstream service can continue to use, attempting to continue the invocation.
Further, the step S4 is further specifically: the upstream service maintains the fuse state of the downstream service, if the prohibition request state of the fuse occurs, the failure of return is directly judged, and when the downstream service is in a healthy state and local abnormality occurs during calling, the fuse function needs to be started.
Further, the step S5 is further specifically: and each service needs to start a maintenance thread, the maintenance thread is used for maintaining the accessible state of the downstream service, whether the maintenance thread is started or not is judged, when the fuse state is a request prohibiting state, the maintenance thread needs to start timing, and when the time exceeds the time of cycle timing, the request prohibiting state is changed into an trying state, and the downstream service is continuously called.
Further, after the fuse is changed from the prohibition request state to the trial-available state, a recovery time is given to the downstream service, whether calling the downstream service is successful or not is judged, the success number is counted, if the success number exceeds 3, the downstream service is judged to be normal, the fuse state is changed from the trial-available state to the permission request state, if the success number is less than 3, the fuse state is changed to the prohibition request state, and the steps S3-S6 are repeated.
The invention also provides a fusing system for preventing service avalanche of the payment system, which comprises a reporting module, a calling module, a reading module, a fuse state module, a maintenance module and a re-calling module;
the reporting module reports the health state of each service in the payment system;
the calling module, namely the upstream service calls the downstream service;
the reading module, namely the upstream service reads the health status of the downstream service;
the fuse state module, namely the upstream service reads the fuse state of the downstream service;
the maintenance module, namely starting a maintenance thread, maintains the accessible state of the fuse state of the downstream service;
the recall module, i.e., the upstream service, recalls the fuse state again to the downstream service in an atternable state.
Further, the reporting module is further specifically configured to: each service in the payment system starts a thread, and the health state is reported to the etcd circularly and regularly.
Further, the calling module is further specifically: the upstream service refers to a caller, the downstream service refers to a callee, and the caller and the callee change with different steps of the payment system.
Further, the reading module is further specifically: the upstream service reads the corresponding downstream service health state from the etcd, determines whether the health state range of the downstream service is between 5s and 10s, if so, pushes a short message to a responsible person, restarts the fault service and performs intervention recovery; otherwise, the downstream service can continue to use, attempting to continue the invocation.
Further, the fuse state module further specifically includes: the upstream service maintains the fuse state of the downstream service, if the prohibition request state of the fuse occurs, the failure of return is directly judged, and when the downstream service is in a healthy state and local abnormality occurs during calling, the fuse function needs to be started.
Further, the maintenance module is further specifically: and each service needs to start a maintenance thread, the maintenance thread is used for maintaining the accessible state of the downstream service, whether the maintenance thread is started or not is judged, when the fuse state is a request prohibiting state, the maintenance thread needs to start timing, and when the time exceeds the time of cycle timing, the request prohibiting state is changed into an trying state, and the downstream service is continuously called.
Further, the recall module is further specifically: when the fuse is changed from the prohibition request state to the trial-available state, the fuse gives a recovery time to the downstream service, judges whether the calling of the downstream service is successful, counts the success times, judges that the downstream service is recovered to be normal if the success times exceed 3 times, changes the state of the fuse from the trial-available state to the permission request state, judges that the downstream service is not recovered to be normal if the success times are less than 3 times, changes the state of the fuse to the prohibition request state, and repeats the reading module, the fuse state module, the maintenance module and the recalling module.
The invention has the beneficial effects that: the invention provides a fusing scheme and a fusing system for preventing service avalanches of a payment system.
Drawings
FIG. 1 is a schematic flow diagram of the process of the present invention.
Fig. 2 is a schematic block diagram of the system of the present invention.
Detailed Description
The invention is further described below with reference to the accompanying drawings.
Referring to fig. 1, a fusing scheme for preventing service avalanche for a payment system of the present invention includes the following steps: step S1, reporting the health status of each service in the payment system;
step S2, the upstream service calls the downstream service;
step S3, the upstream service reads the health status of the downstream service;
step S4, the upstream service reads the fuse state of the downstream service;
step S5, starting a maintenance thread and maintaining the accessible state of the fuse state of the downstream service;
step S6, the upstream service recalls the fuse state again as a downstream service in an atternable state.
The invention is further illustrated below with reference to a specific embodiment:
step 1, reporting health status by service
Each service starts a thread, and the health state is reported to the etcd in a cycle timing of 5s, wherein the etcd is a high-availability distributed key value middleware and is used for registering between upstream and downstream services in a discovery function.
Step 2, the upstream service calls the downstream service
The upstream service is a caller, the downstream service is a callee, and the caller and the callee can change along with different steps, for example, after an order is created on an order service, a commodity stock service is called to reduce stock, so that the order service is the upstream service, and the commodity stock service is the downstream service; and after the commodity inventory is deducted, calling a user point service to add points to the user, wherein the commodity inventory is an upstream service at the moment, and the user point service is a downstream service.
Step 3, reading the health status of the downstream service
The upstream service reads the health state of the downstream service from the etcd, the etcd reports the health state through a url to identify that the upstream service is still alive and can provide services, and if the health state reported finally is 10s ago, the downstream service is unavailable, does not need to try to call and directly returns failure. And the short message is pushed to the responsible person, and the responsible person restarts the fault service and manually intervenes to recover.
Step 4, reading the fuse state of the downstream service
The upstream service maintains the fuse state of the downstream service, the fuse is a state table of the downstream service maintained in the current service memory, and is defined in the memory variable, and the memory variable is changed by calling the successful state returned after the downstream service. If the fuse is in the inhibit request state, a failure is returned directly. Although the downstream service is in a healthy state, it may only be that a local exception to the call occurs, resulting in the method being unavailable, and the fuse function needs to be enabled.
Step 5, starting maintenance thread
Each service requires the opening of a maintenance thread, which acts to maintain the accessible state of the downstream services. Judging whether the maintenance thread is started or not, avoiding repeated starting, if the fuse state is a request prohibition state, the maintenance thread needs to start timing, and if the time exceeds 5 seconds, the opening state is changed into a trial-able state, and the downstream service is allowed to be called continuously.
Step 6, the upstream service recalls the downstream service in the trial-able state
After the fuse is changed from the request prohibition state to the trial-available state, the downstream service is given a certain gasp time, if the calling of the downstream service is successful, the success number is counted, if the calling of the downstream service is more than 3 times, the downstream service is considered to be recovered, and the trial-available state of the fuse is changed to the request permission state. If the calling of the downstream service fails and the counting retry fails for 3 times, the downstream service is considered not to be recovered to be normal, the fuse state is changed into the request prohibition state, and the step 3-6 is continuously repeated.
In short, in the distributed system, when it is detected that a certain service response duration is abnormal or the number of times of timeout exceeds a threshold, the service is stopped from being called, the calling of the service is quickly failed, so that resources held by the request are released, a maintenance thread is started, and the like, the service attempt is continuously allowed to be called after countdown is finished, and the state of the service is continuously changed according to the number of times of success and the number of times of failure. Each service reports its health status to the configuration center, and in combination with the invocation of upstream services, the fuses of the services have 3 states: 1. forbidding the request state, not being remotely called, and directly returning failure by the upstream service; 2. an attempted state, after the countdown is finished, allowing the attempt to be called by the remote service; 3. the request allowed state may be invoked by the service as normal.
Referring to fig. 2, the present invention further provides a fusing system for preventing service avalanche for a payment system, including a reporting module, a calling module, a reading module, a fuse state module, a maintenance module, and a recall module;
the reporting module reports the health state of each service in the payment system;
the calling module, namely the upstream service calls the downstream service;
the reading module, namely the upstream service reads the health status of the downstream service;
the fuse state module, namely the upstream service reads the fuse state of the downstream service;
the maintenance module, namely starting a maintenance thread, maintains the accessible state of the fuse state of the downstream service;
the recall module, i.e., the upstream service, recalls the fuse state again to the downstream service in an atternable state.
The reporting module is further specifically: each service in the payment system starts a thread, and the health state is reported to the etcd circularly and regularly.
The calling module is further specifically: the upstream service refers to a caller, the downstream service refers to a callee, and the caller and the callee change with different steps of the payment system.
The reading module is further specifically: the upstream service reads the corresponding downstream service health state from the etcd, determines whether the health state range of the downstream service is between 5s and 10s, if so, pushes a short message to a responsible person, restarts the fault service and performs intervention recovery; otherwise, the downstream service can continue to use, attempting to continue the invocation.
The fuse state module is further embodied as: the upstream service maintains the fuse state of the downstream service, if the prohibition request state of the fuse occurs, the failure of return is directly judged, and when the downstream service is in a healthy state and local abnormality occurs during calling, the fuse function needs to be started.
The maintenance module is further specifically: and each service needs to start a maintenance thread, the maintenance thread is used for maintaining the accessible state of the downstream service, whether the maintenance thread is started or not is judged, when the fuse state is a request prohibiting state, the maintenance thread needs to start timing, and when the time exceeds the time of cycle timing, the request prohibiting state is changed into an trying state, and the downstream service is continuously called.
The recall module is further specifically: when the fuse is changed from the prohibition request state to the trial-available state, the fuse gives a recovery time to the downstream service, judges whether the calling of the downstream service is successful, counts the success times, judges that the downstream service is recovered to be normal if the success times exceed 3 times, changes the state of the fuse from the trial-available state to the permission request state, judges that the downstream service is not recovered to be normal if the success times are less than 3 times, changes the state of the fuse to the prohibition request state, and repeats the reading module, the fuse state module, the maintenance module and the recalling module.
The above description is only a preferred embodiment of the present invention, and all equivalent changes and modifications made in accordance with the claims of the present invention should be covered by the present invention.
Claims (14)
1. A fusing scheme for a payment system to prevent service avalanches, the scheme comprising the steps of: step S1, reporting the health status of each service in the payment system;
step S2, the upstream service calls the downstream service;
step S3, the upstream service reads the health status of the downstream service;
step S4, the upstream service reads the fuse state of the downstream service;
step S5, starting a maintenance thread and maintaining the accessible state of the fuse state of the downstream service;
step S6, the upstream service recalls the fuse state again as a downstream service in an atternable state.
2. A fusing scheme for a payment system against service avalanches as claimed in claim 1, wherein: the step S1 further includes: each service in the payment system starts a thread, and the health state is reported to the etcd circularly and regularly.
3. A fusing scheme for a payment system against service avalanches as claimed in claim 1, wherein: the step S2 further includes: the upstream service refers to a caller, the downstream service refers to a callee, and the caller and the callee change with different steps of the payment system.
4. A fusing scheme for a payment system against service avalanches as claimed in claim 1, wherein: the step S3 further includes: the upstream service reads the corresponding downstream service health state from the etcd, determines whether the health state range of the downstream service is between 5s and 10s, if so, pushes a short message to a responsible person, restarts the fault service and performs intervention recovery; otherwise, the downstream service can continue to use, attempting to continue the invocation.
5. A fusing scheme for a payment system against service avalanches as claimed in claim 1, wherein: the step S4 further includes: the upstream service maintains the fuse state of the downstream service, if the prohibition request state of the fuse occurs, the failure of return is directly judged, and when the downstream service is in a healthy state and local abnormality occurs during calling, the fuse function needs to be started.
6. A fusing scheme for a payment system against service avalanches as claimed in claim 1, wherein: the step S5 further includes: and each service needs to start a maintenance thread, the maintenance thread is used for maintaining the accessible state of the downstream service, whether the maintenance thread is started or not is judged, when the fuse state is a request prohibiting state, the maintenance thread needs to start timing, and when the time exceeds the time of cycle timing, the request prohibiting state is changed into an trying state, and the downstream service is continuously called.
7. A fusing scheme for a payment system against service avalanches as claimed in claim 1, wherein: when the fuse is changed from the request prohibition state to the trial-available state, giving a recovery time to the downstream service, judging whether calling the downstream service is successful or not, counting the success times, judging that the downstream service is recovered to be normal if the success times exceed 3 times, changing the fuse state from the trial-available state to the request permission state, judging that the downstream service is not recovered to be normal if the success times are less than 3 times, changing the fuse state to the request prohibition state, and repeating the steps S3-S6.
8. A fusing system for a payment system to prevent service avalanches, comprising: the system comprises a reporting module, a calling module, a reading module, a fuse state module, a maintenance module and a re-calling module;
the reporting module reports the health state of each service in the payment system;
the calling module, namely the upstream service calls the downstream service;
the reading module, namely the upstream service reads the health status of the downstream service;
the fuse state module, namely the upstream service reads the fuse state of the downstream service;
the maintenance module, namely starting a maintenance thread, maintains the accessible state of the fuse state of the downstream service;
the recall module, i.e., the upstream service, recalls the fuse state again to the downstream service in an atternable state.
9. A fusing system for a payment system to prevent service avalanches as claimed in claim 8, wherein: the reporting module is further specifically: each service in the payment system starts a thread, and the health state is reported to the etcd circularly and regularly.
10. A fusing system for a payment system to prevent service avalanches as claimed in claim 8, wherein: the calling module is further specifically: the upstream service refers to a caller, the downstream service refers to a callee, and the caller and the callee change with different steps of the payment system.
11. A fusing system for a payment system to prevent service avalanches as claimed in claim 8, wherein: the reading module is further specifically: the upstream service reads the corresponding downstream service health state from the etcd, determines whether the health state range of the downstream service is between 5s and 10s, if so, pushes a short message to a responsible person, restarts the fault service and performs intervention recovery; otherwise, the downstream service can continue to use, attempting to continue the invocation.
12. A fusing system for a payment system to prevent service avalanches as claimed in claim 8, wherein: the fuse state module is further embodied as: the upstream service maintains the fuse state of the downstream service, if the prohibition request state of the fuse occurs, the failure of return is directly judged, and when the downstream service is in a healthy state and local abnormality occurs during calling, the fuse function needs to be started.
13. A fusing system for a payment system to prevent service avalanches as claimed in claim 8, wherein: the maintenance module is further specifically: and each service needs to start a maintenance thread, the maintenance thread is used for maintaining the accessible state of the downstream service, whether the maintenance thread is started or not is judged, when the fuse state is a request prohibiting state, the maintenance thread needs to start timing, and when the time exceeds the time of cycle timing, the request prohibiting state is changed into an trying state, and the downstream service is continuously called.
14. A fusing system for a payment system to prevent service avalanches as claimed in claim 8, wherein: the recall module is further specifically: when the fuse is changed from the prohibition request state to the trial-available state, the fuse gives a recovery time to the downstream service, judges whether the calling of the downstream service is successful, counts the success times, judges that the downstream service is recovered to be normal if the success times exceed 3 times, changes the state of the fuse from the trial-available state to the permission request state, judges that the downstream service is not recovered to be normal if the success times are less than 3 times, changes the state of the fuse to the prohibition request state, and repeats the reading module, the fuse state module, the maintenance module and the recalling module.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110432068.7A CN112988546A (en) | 2021-04-21 | 2021-04-21 | Fusing scheme and system for preventing service avalanche of payment system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110432068.7A CN112988546A (en) | 2021-04-21 | 2021-04-21 | Fusing scheme and system for preventing service avalanche of payment system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112988546A true CN112988546A (en) | 2021-06-18 |
Family
ID=76341570
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110432068.7A Withdrawn CN112988546A (en) | 2021-04-21 | 2021-04-21 | Fusing scheme and system for preventing service avalanche of payment system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112988546A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113472879A (en) * | 2021-06-29 | 2021-10-01 | 中国平安财产保险股份有限公司 | Service request method, device, computer equipment and storage medium |
| CN115170131A (en) * | 2022-09-06 | 2022-10-11 | 云账户技术(天津)有限公司 | Payment method and device based on fuse, storage medium and terminal equipment |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150127578A1 (en) * | 2013-11-01 | 2015-05-07 | Amazon Technologies, Inc. | Stateless simulation service |
| CN106776099A (en) * | 2017-01-11 | 2017-05-31 | 北京皮尔布莱尼软件有限公司 | One kind service fusing shielding system and method |
| CN107465627A (en) * | 2017-08-11 | 2017-12-12 | 北京小度信息科技有限公司 | Overload protection method, device, electronic equipment and flow processing system |
| CN108600005A (en) * | 2018-04-23 | 2018-09-28 | 国云科技股份有限公司 | A method of defence micro services avalanche effect |
| CN108712309A (en) * | 2018-06-11 | 2018-10-26 | 郑州云海信息技术有限公司 | A kind of micro services node means of defence under micro services framework and system |
| CN109976935A (en) * | 2019-03-14 | 2019-07-05 | 北京三快在线科技有限公司 | Micro services framework, micro services node and its fusing restoration methods, device |
| CN111355664A (en) * | 2020-02-19 | 2020-06-30 | 中国农业银行股份有限公司 | Flow control method and device |
-
2021
- 2021-04-21 CN CN202110432068.7A patent/CN112988546A/en not_active Withdrawn
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150127578A1 (en) * | 2013-11-01 | 2015-05-07 | Amazon Technologies, Inc. | Stateless simulation service |
| CN106776099A (en) * | 2017-01-11 | 2017-05-31 | 北京皮尔布莱尼软件有限公司 | One kind service fusing shielding system and method |
| CN107465627A (en) * | 2017-08-11 | 2017-12-12 | 北京小度信息科技有限公司 | Overload protection method, device, electronic equipment and flow processing system |
| CN108600005A (en) * | 2018-04-23 | 2018-09-28 | 国云科技股份有限公司 | A method of defence micro services avalanche effect |
| CN108712309A (en) * | 2018-06-11 | 2018-10-26 | 郑州云海信息技术有限公司 | A kind of micro services node means of defence under micro services framework and system |
| CN109976935A (en) * | 2019-03-14 | 2019-07-05 | 北京三快在线科技有限公司 | Micro services framework, micro services node and its fusing restoration methods, device |
| CN111355664A (en) * | 2020-02-19 | 2020-06-30 | 中国农业银行股份有限公司 | Flow control method and device |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113472879A (en) * | 2021-06-29 | 2021-10-01 | 中国平安财产保险股份有限公司 | Service request method, device, computer equipment and storage medium |
| CN113472879B (en) * | 2021-06-29 | 2023-12-08 | 中国平安财产保险股份有限公司 | Service request method, device, computer equipment and storage medium |
| CN115170131A (en) * | 2022-09-06 | 2022-10-11 | 云账户技术(天津)有限公司 | Payment method and device based on fuse, storage medium and terminal equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112988546A (en) | Fusing scheme and system for preventing service avalanche of payment system | |
| JP3720356B2 (en) | Method for controlling overload in a telecommunications network | |
| CN106776099B (en) | Service fusing isolation system and method | |
| US9626236B2 (en) | Method, apparatus and computer program for administering messages which a consuming application fails to process | |
| CN111078453B (en) | Method, device, computer equipment and storage medium for automatically fusing and recovering micro-service | |
| CN106533805B (en) | Micro-service request processing method, micro-service controller and micro-service architecture | |
| CN111901422B (en) | Method, system and device for managing nodes in cluster | |
| CN111209110B (en) | Task scheduling management method, system and storage medium for realizing load balancing | |
| WO2007106649A2 (en) | Method and apparatus for dynamically prioritize network faults based on real-time service degradation | |
| CN111782487A (en) | Alarm notification method and device | |
| CN112269674A (en) | Method for abnormal fusing and self-recovery of service interface | |
| CN101102217B (en) | Processing method for duplicate alert and discontinuous reporting and monitoring in telecom network management system | |
| CN115794549A (en) | Method, device and medium for managing and controlling resource occupied by application program | |
| CN111385359A (en) | Load processing method and device of object gateway | |
| CN113867915A (en) | Task scheduling method, electronic device and storage medium | |
| CN111949421B (en) | SDK calling method, device, electronic equipment and computer readable storage medium | |
| CN101951571A (en) | Short message retrying method and short message gateway | |
| CN101170717A (en) | A method and system for realizing license mechanism of mobile switching center in the pool | |
| WO2014040470A1 (en) | Alarm message processing method and device | |
| CN109634787B (en) | Distributed file system monitor switching method, device, equipment and storage medium | |
| CN112350860A (en) | System and method for judging user fault recovery condition | |
| CN113157493A (en) | Backup method, device and system based on ticket checking system and computer equipment | |
| JP2007259368A (en) | Load controlling method, load controlling system, and load controlling program for exchange | |
| CN111538612B (en) | Method and system for realizing rapid switching of main server and standby server through service degradation | |
| JP2565105B2 (en) | Automatic call back method |
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 | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20210618 |