Service request processing method and device, electronic equipment and computer program product

Abstract

The embodiment of the invention provides a service request processing method and device, electronic equipment and a computer program product, and the method comprises the steps: accessing a first cache of the same region according to a service request, and transmitting the service request through a target standby link accessing a second cache of other regions under the condition that a main link accessing the first cache is abnormal, and querying a service result. According to the embodiment of the invention, the operation condition of the communication link is detected in real time, the cache abnormity can be found in time, the abnormal link is fused, and when the main link between the service application and the cache in the same region has an abnormal fault, the standby link can be switched to access the caches in other regions, so that the operation efficiency is improved. Therefore, the request caching success rate and request time consumption are improved, a large number of service requests are prevented from penetrating a database, and the stability and reliability of a service system are improved.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of data processing technology, and in particular, to a method, device, electronic device, and computer program product for processing a service request. Background Art

[0002] With the continuous evolution of digital financial technology, the amount of data in financial business systems is increasing. Business systems have evolved from traditional cluster deployment to multi-region deployment, which has led to the problem of cross-city access of business requests, resulting in increased time consumption for business requests. In order to alleviate the time consumption problem of cross-city access, the business system introduces cache (Redis) to reduce cross-city access.

[0003] However, during the service request process, the cache or database will often experience jitter, downtime and other problems, causing a large amount of service traffic to penetrate the remote server, increasing service time, affecting business applications, and easily causing database failures. Summary of the invention

[0004] In order to improve the disaster recovery capability of a business system and ensure system stability, the embodiments of this specification provide a business request processing method, device, electronic device, storage medium and computer program product.

[0005] In a first aspect, some embodiments of this specification provide a business request processing method, which is applied to a business system, wherein the business system includes a database and multiple caches deployed in different regions, and the method includes:

[0006] accessing, according to the service request, a first cache in the same region as the service application that initiated the service request;

[0007] In the event that an abnormality occurs in a primary link for accessing the first cache, determining a target backup link from a plurality of backup links for accessing caches in other regions;

[0008] The service request is sent using the target standby link, and the service result is queried in the second cache corresponding to the target standby link.

[0009] In some implementations, the process of determining whether the primary link is abnormal includes:

[0010] Creating a time wheel with a preset time period, and collecting service data of the primary link in each time period of the time wheel;

[0011] Determine a current link parameter based on the service data of the previous time period, wherein the link parameter is used to indicate the availability of the link;

[0012] When the link parameter is greater than or equal to a preset threshold, it is determined that no abnormality occurs in the primary link, and when the link parameter is less than the preset threshold, it is determined that an abnormality occurs in the primary link.

[0013] In some implementations, determining a target backup link from a plurality of backup links for accessing caches in other regions includes:

[0014] Creating a time wheel with a preset time period, and collecting service data of each standby link in each time period of the time wheel;

[0015] For each standby link, based on the service data of the previous time period, determine the current link parameter, wherein the link parameter is used to indicate the availability of the link;

[0016] The link parameters of the various backup links are compared, and the backup link with the largest link parameter is determined as the target backup link.

[0017] In some implementations, determining the current link parameters based on the service data of the previous time period includes:

[0018] Determine the access success rate, request duration, and most recent request success rate of the primary link based on the service data of the previous time period;

[0019] The access success rate, the request time consumption and the most recent request success rate are integrated and calculated to determine the current link parameters.

[0020] In some implementations, the service request processing method of the present specification periodically sends a liveness detection request to the first cache through the primary link during communication through the target backup link;

[0021] In response to the first cache successfully responding to the detection request, the communication link is switched from the target backup link to the primary link.

[0022] In some implementations, the cache includes a local cache and / or a server cache.

[0023] In some implementations, the cache includes a local cache and a server cache, and the method further includes:

[0024] When no service result corresponding to the service request is found in the access to the local cache, the service request is sent to the server cache in the same region as the service request;

[0025] When no business result is found by accessing the server cache in the same region as the business request, the database is queried according to the business request to obtain the business result.

[0026] In a second aspect, an embodiment of the present specification provides a business request processing device, which is applied to a business system, wherein the business system includes a database and multiple caches deployed in different regions, and the device includes:

[0027] A business application module is configured to access, according to a business request, a first cache in the same region as the business application that initiated the business request;

[0028] The disaster recovery module is configured to determine a target backup link from multiple backup links used to access caches in other regions when an abnormality occurs in the main link used to access the first cache, send the service request using the target backup link, and query the service result in the second cache corresponding to the target backup link.

[0029] In some implementations, the disaster recovery module is configured as follows:

[0030] Creating a time wheel with a preset time period, and collecting service data of the primary link in each time period of the time wheel;

[0031] Determine a current link parameter based on the service data of the previous time period, wherein the link parameter is used to indicate the availability of the link;

[0032] When the link parameter is greater than or equal to a preset threshold, it is determined that no abnormality occurs in the primary link, and when the link parameter is less than the preset threshold, it is determined that an abnormality occurs in the primary link.

[0033] In some implementations, the disaster recovery module is configured as follows:

[0034] Creating a time wheel with a preset time period, and collecting service data of each standby link in each time period of the time wheel;

[0035] For each standby link, based on the service data of the previous time period, determine the current link parameter, wherein the link parameter is used to indicate the availability of the link;

[0036] The link parameters of the various backup links are compared, and the backup link with the largest link parameter is determined as the target backup link.

[0037] In some implementations, the disaster recovery module is configured as follows:

[0038] Determine the access success rate, request duration, and most recent request success rate of the primary link based on the service data of the previous time period;

[0039] The access success rate, the request time consumption and the most recent request success rate are integrated and calculated to determine the current link parameters.

[0040] In some implementations, the disaster recovery module is configured as follows:

[0041] During communication through the target standby link, periodically sending a liveness request to the first cache through the primary link;

[0042] In response to the first cache successfully responding to the detection request, the communication link is switched from the target backup link to the primary link.

[0043] In some implementations, the cache includes a local cache and / or a server cache.

[0044] In some implementations, the business application module is configured as follows:

[0045] When no service result corresponding to the service request is found in the access to the local cache, the service request is sent to the server cache in the same region as the service request;

[0046] When no business result is found by accessing the server cache in the same region as the business request, the database is queried according to the business request to obtain the business result.

[0047] In a third aspect, an embodiment of the present specification provides an electronic device, including:

[0048] processor;

[0049] A memory stores computer instructions, wherein the computer instructions are used to enable a processor to execute the method described in any of the above embodiments.

[0050] In a fourth aspect, an embodiment of this specification provides a storage medium storing computer instructions, wherein the computer instructions are used to implement the method described in any of the above embodiments.

[0051] In a fifth aspect, an embodiment of this specification provides a computer program product, and the computer program product is used to implement the method described in any of the above embodiments.

[0052] The service request processing method of the implementation mode of the present specification includes accessing the first cache in the same region according to the service request, and when the main link for accessing the first cache is abnormal, using the target backup link for accessing the second cache in other regions to send the service request and query the service result. The implementation mode of the present specification can timely detect the cache abnormality and fuse the abnormal link by real-time detection of the operation status of the communication link. When the main link between the service application and the cache in the same region fails abnormally, the backup link can be switched to access the cache in other regions, thereby improving the success rate and request time of the cache request, avoiding a large number of service requests from penetrating into the database, and improving the stability and reliability of the service system. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 It is an architecture diagram of a business system in an exemplary embodiment of this specification.

[0054] Figure 2 It is a flowchart of a method for processing a service request in an exemplary embodiment of this specification.

[0055] Figure 3 Schematic diagram of the structure of a timing wheel in an exemplary embodiment of this specification.

[0056] Figure 4 It is a flowchart of a method for processing a service request in an exemplary embodiment of this specification.

[0057] Figure 5 It is a structural block diagram of a service request processing device in an exemplary embodiment of this specification.

[0058] Figure 6 is a structural block diagram of an electronic device in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0059] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0060] With the continuous evolution of digital financial technology, the amount of data in financial business systems is increasing. Business systems have evolved from traditional cluster deployment to multi-region deployment, which has led to the problem of cross-city access of business requests, resulting in increased time consumption for business requests. In order to alleviate the time consumption problem of cross-city access, the system introduces a near-end cache (Redis) to reduce cross-city access.

[0061] For example, taking the contract center as an example, the near-end cache can be deployed in different cities. The near-end cache can be used as a local high-speed cache and a simple memory database. When a business request initiates access, the business query can first be performed in the near-end cache in the same city. If the near-end cache query does not hit, it is necessary to cross the city to access the remote contract center server. If the server cache does not hit the query result, it is necessary to further query the database to obtain the query data.

[0062] However, during the business request process, caches or databases often experience jitters, downtime, and other problems. The contract center has a large number of concurrent accesses, with an average daily visit volume of 20 million times per minute. As a basic component of the credit business, the contract center connects various business links in series. Therefore, problems such as contract jitter and unavailability will have a huge impact on business applications. Moreover, as a traffic convergence point on each business link, the contract center has the characteristics of interface traffic amplification. If a large number of business requests penetrate to the remote server, the time taken for a single request will increase by 13ms to 50ms, and the time taken for the traffic interface will increase by 400ms to 1500ms, resulting in a business entry timeout. In addition, in the case of cache jitter or failure, a large amount of contract traffic can easily lead to an increase in database load and cause system failures. Therefore, how to detect cache and database failures in a timely manner while carrying massive requests, and how to ensure system stability through disaster recovery in a timely manner is a problem that must be solved.

[0063] Based on this, the embodiments of this specification provide a business request processing method, device, electronic device, storage medium and computer program product, which aim to improve the disaster recovery capability of the business system. When the local cache is requested abnormally, caches in other regions can be accessed across cities, thereby improving the success rate of request caches, reducing business time consumption, and reducing access traffic to remote servers or databases, thereby ensuring high reliability and stability in massive request scenarios.

[0064] Figure 1 An architecture diagram of the business system on which the business request processing method in some implementation methods of this specification relies is shown. In this specification, the business system can be any service system suitable for implementation, such as a contract center system, an asset management system, a risk control system, etc. This specification does not impose any restrictions on this.

[0065] See also Figure 1As shown, the business system takes the contract center system as an example. The contract center system includes the underlying database (DB, Data Base), server-side cache, near-end cache and business applications. As the underlying foundation of the contract center, the database is used to provide persistent storage, management and processing of contract data. The database is deployed in a cluster, that is, the database is deployed in one region. The cache of the business system includes the server-side cache and the near-end cache. The server-side cache refers to the cache of the server application of the contract center, and the near-end cache refers to the cache deployed on the business application side of the contract center. The server-side cache and the near-end cache can be deployed in multiple different regions, such as Figure 1 In the example, for the three regions A, B, and C, each region is deployed in the server cache and the near-end cache. The top-level business application refers to the contract center application, which sends business requests through the top-level business application to query the cache or database data.

[0066] The business request processing method of the implementation mode of this specification, when the business application accesses the near-end cache and / or the server-side cache, if the cache in the same region has abnormal failures such as jitter or downtime, the business request is not directly penetrated to the database, but the cache in other regions is accessed by switching the backup link for retry, thereby improving the success rate of the cache request. It can be understood that the cache is used to store business processing results. When the business request accesses the cache, there is no need for complex calls and calculations. Compared with cross-regional database queries, it is more efficient and the request time is shorter. In addition, in the case of massive requests, the number of requests that penetrate the server-side database can be greatly reduced, thereby improving the stability and reliability of the database.

[0067] Figure 2 A flowchart showing a method for processing a service request in some embodiments of the present specification is shown in FIG. Figure 2 As shown, the service request processing method of the example in this specification includes:

[0068] S210 . Access, according to the service request, a first cache in the same region as the service application that initiates the service request.

[0069] When a business application generates a business request, the system can access the local cache in the same region based on the business request. Figure 1 As shown, for example, for business applications in region A, the business requests generated by each business application in region A first access the near-end cache in the same region. It can be understood that the data stored in the near-end cache is time-sensitive. For a certain business request, if the business result is not found by accessing the near-end cache in the same region, the business request can be sent to the server cache in the same region. The server cache has more data information than the near-end cache, so the business result can be obtained by querying the server cache based on the business request.

[0070] In the implementation manner of this specification, the cache of the business system may include a proximal cache and / or a server cache. For a certain business request, the corresponding first cache may refer to a proximal cache in the same region as the business request, or may refer to a server cache in the same region as the business request. In other words, the business request processing method of this specification may be applied to the process of a business request accessing a proximal cache, or may be applied to the process of a business request accessing a server cache.

[0071] In the implementation mode of this specification, the communication link for a business application to access a local cache or server cache in the same region is defined as the primary link, and the communication link for accessing a local cache or server cache in other regions is defined as the backup link. Figure 1 In the example, for the business application in region A, the communication link for accessing the proximal cache / server cache in region A is the primary link, and the communication link for accessing the proximal cache / server cache in regions B and C is the backup link.

[0072] S220: When an abnormality occurs in a primary link for accessing the first cache, determine a target backup link from a plurality of backup links for accessing caches in other regions.

[0073] Combined with the above, it can be seen that when a business request is accessing the cache, the cache may experience abnormal failures such as jitter and downtime, resulting in request failure. In the implementation of this specification, the business system will detect in real time whether each link has abnormal failures. If a primary link is abnormal, the primary link can be switched to other backup links, so that the business request originally on the primary link can access caches in other regions across cities.

[0074] In some implementations, taking the process of a business application accessing a proximal cache as an example, assuming that a business application in region A generates a business request, the business request will be sent to the proximal cache in region A, that is, the first cache, through the primary link. If an abnormality is detected in the primary link accessing the proximal cache in region A, it means that the business request cannot access the first cache normally. In this case, a backup link with better performance can be selected from multiple backup links accessing other regions as the target backup link.

[0075] Combination Figure 1 As shown, taking the business application in area A accessing the proximal cache in area A as an example, if the main link accessing the proximal cache in area A is abnormal, a backup link with better performance can be selected as the target backup link from backup link 1 accessing the proximal cache in area B and backup link 2 accessing the proximal cache in area C, that is, a link is selected from backup link 1 and backup link 2 as the target backup link.

[0076] S230: Send a service request using the target standby link, and query the service result in the second cache corresponding to the target standby link.

[0077] In the implementation mode of this specification, the cache of the corresponding region accessed by the business application through the target backup link is defined as the second cache. For example, in the above example, in the backup link 1 for accessing the proximal cache of region B and the backup link 2 for accessing the proximal cache of region C, the target backup link is determined to be the backup link 2, so that the second cache represents the proximal cache of region C.

[0078] It can be understood that the target backup link is a link with better performance selected from multiple backup links when the main link is abnormal, so that the service request can be sent to the second cache through the target backup link, and the service result corresponding to the service request can be queried from the second cache.

[0079] In the previous example, assuming that no business results are found by accessing the proximal cache in region C, the business request can be sent to the server cache in region A, and the business results can be queried from the server cache. Similar to the above, the server cache can also achieve cross-regional access through the above-mentioned primary-backup link switching. For example, in one example, when an abnormality occurs in the primary link between the business application and the server cache in region A, a target backup link with better performance can be determined from the multiple backup links between the business application and the server cache in other regions. The target backup link is then used to send the business request to the server cache in the corresponding region, and the business results are queried from the server cache. If no business results are found when querying the server cache using the target backup link, it is necessary to send the business request to the database to query the persistent data in the database to obtain the business results.

[0080] From the above, we can see that in the business system, by detecting the operation of the communication link, abnormal problems such as cache jitter and downtime can be discovered in time. In addition, when an abnormal failure occurs in the primary link between the business application and the cache in the same region, the cache in other regions can be accessed by switching to the backup link, thereby improving the success rate and request time of the cache request, avoiding a large number of requests from flooding into the database, and improving the stability and reliability of the business system.

[0081] Time Wheel is a data structure used to efficiently process timed tasks. Figure 3 The schematic diagram of the structure of the time wheel is shown. The basic structure of the time wheel is a ring-shaped clock face. The entire clock face is divided into multiple time slots. Each time slot represents a time period. Each time period can store multiple tasks.

[0082] In some implementations of this specification, a time wheel can be used to collect, count and process the operation data of each link in the service system, so as to use the statistical data of each time period (i.e., time slot) to determine whether the current link is available, and trigger the link fuse when the link is unavailable, and switch the service request to other backup links. Figure 4 The process of detecting the availability of the primary link is described.

[0083] like Figure 4 As shown, in some implementations, the service processing method exemplified in this specification, the process of determining whether the primary link is available includes:

[0084] S410: Create a time wheel with a preset time period, and collect service data of the primary link in each time period of the time wheel.

[0085] S420. Determine the current link parameters based on the service data of the previous time period, and determine that the main link is normal if the link parameters are greater than or equal to a preset threshold, otherwise determine that the main link is abnormal.

[0086] In the implementation mode of this specification, a time wheel is used to realize the cyclic and efficient collection of business data, and the data in the time slot is calculated in real time according to the position of each request in the time wheel. First, the length of the time cycle and the number of time slots can be selected according to the needs of the business system. The specific values ​​are not limited in this specification. A time wheel for data collection and statistics is constructed, such as Figure 3 as shown in .

[0087] Taking the main link between a business application and a local cache as an example, in each time period (i.e., time slot) of the time wheel, the business data generated in the time period can be collected through the monitoring components, data collection nodes and other modules of the business system. For example, in one example, the business data may include whether each business request access is successful, the time consumption corresponding to each business request, and other data.

[0088] Then, the business data in each time period can be counted, and the corresponding link parameters can be calculated based on the comprehensive business data. The link parameters are used to indicate the stability or availability of the link. For example, taking a certain time period as an example, the access success rate, request time, and the most recent request success rate of the link in the time period can be determined based on the business data collected in the time period, and the availability of the current main link can be determined through fusion calculation. Availability is quantitatively expressed by link parameters. The larger the link parameter, the higher the link availability, that is, the more stable the link; conversely, the smaller the link parameter, the lower the link availability, that is, the more unstable the link.

[0089] In the implementation mode of this specification, a corresponding preset threshold value can be set in advance for the link parameter, and the preset threshold value indicates the threshold value of the link availability. If the link parameter is greater than or equal to the preset threshold value, it means that the current link can be accessed normally. On the contrary, if the link parameter is less than the preset threshold value, it means that the current link has an access anomaly and triggers a fuse. The specific value of the preset threshold value can be selected according to the scenario requirements, and this specification does not limit this.

[0090] For example, in an example, taking the primary link 1 between a certain service application and a near-end cache in the same region as an example, in a certain time period T of the time wheel, the various parameters of the current primary link 1 are determined by collecting the service data of the time period T as shown in Table 1 below:

[0091] Table 1

[0092] link Access success rate Request time The success rate of the last request Development Trend Link parameters Active link 1 80% (8 points) 16ms (8 minutes) Failure (0 points) Poor stability 5.6

[0093] In the example of Table 1, in the time period T, the access success rate of the service request through the primary link 1 is 80%, the request takes 16ms, and the most recent request fails, so the above-mentioned related parameters can be quantified by counting and quantifying the service data. For example, the access success rate corresponds to 8 points, the request time corresponds to 8 points, and the most recent request success rate is 0 points.

[0094] Then, in the process of fusion calculation of these parameters, a weight coefficient can be configured for each parameter according to specific business requirements, and the link parameters corresponding to the main link 1 can be determined by weighted summation. For example, in an example, assuming that the weight coefficient corresponding to the access success rate is 0.5, the weight coefficient corresponding to the request time is 0.2, and the weight coefficient corresponding to the most recent request success rate is 0.3, the link parameters of the main link 1 are: 8*0.5+8*0.2+0*0.3=5.6.

[0095] In the examples of this specification, preset thresholds of link parameters can be set in advance. For example, in one example, assuming that the preset threshold is 8.0, the link parameters of the main link 1 are compared with the preset threshold: 5.6<8.0, so that it can be determined that the current operation of the main link 1 is unstable and performance abnormalities occur, and the main link 1 needs to be fuse-broken, that is, it is determined that the main link 1 has an abnormality, and the original service request of the main link 1 needs to be switched to other backup links.

[0096] In other exemplary embodiments, if the link parameters of the main link 1 are greater than or equal to a preset threshold, indicating that the current operation of the main link 1 is stable and there is no abnormality, there is no need to fuse the main link 1, and subsequent business requests can continue to maintain communication with the main link 1 until the next time period T+1 repeats the above process and recalculates the link parameters of the time period T+1, which will not be elaborated here.

[0097] From the above, it can be seen that in the implementation mode of this specification, in the business system, by performing real-time fuse detection on each link according to the time wheel, link abnormalities can be discovered in time and abnormal links can be blown, thereby avoiding a large number of business requests from penetrating into the database and improving the stability and reliability of the business system.

[0098] In the implementation of this specification, when the main link is abnormal, the communication link needs to be switched to the backup link, and the cache in other regions is accessed across regions through the backup link. It is understandable that there may be multiple backup links, so it is necessary to select the target backup link with the best or better performance from the multiple backup links.

[0099] In some embodiments, the Figure 4 In a similar manner to the implementation method, the service data of each time period is collected and counted through a time wheel, and the link parameters of each backup link are calculated in real time, and then the link parameters of all backup links are compared, and the backup link with the largest link parameter is selected as the target backup link.

[0100] For example, see Figure 1 As shown, assuming that an abnormality occurs in the main link between the business application in area A and the proximal cache in area A, the link parameters of the backup link 1 for accessing the proximal cache in area B and the backup link 2 for accessing the proximal cache in area C can be calculated respectively. Specifically, the link parameters of the backup link 1 can be determined based on the business data of the previous time period for accessing the proximal cache in area B, and the link parameters of the backup link 2 can be determined based on the business data of the previous time period for accessing the proximal cache in area C. The calculation process of the link parameters is described above and will not be repeated here. For example, in one example, the link parameters of the backup link 1 and the backup link 2 are shown in Table 2 below:

[0101] Table 2

[0102] link Access success rate Request time The success rate of the last request Development Trend Link parameters Backup link 1 80% (8 points) 12ms(8 minutes) Success (10 points) Stablize 8.6 Backup link 2 95% (9 points) 8ms (9 minutes) Success (10 points) Stablize 9.3

[0103] In the example of Table 2, for backup link 1, by counting the business data of its current time period, it is determined that the access success rate is 80%, the request time is 12ms, and the most recent request is successful. The above-mentioned related parameters can be quantified by counting and quantifying the business data. For example, the corresponding score for the access success rate is 8 points, the corresponding score for the request time is 8 points, and the most recent request success rate is 10 points. Then, the link parameters corresponding to backup link 1 are determined by weighted summation. For example, in an example, assuming that the weight coefficient corresponding to the access success rate is 0.5, the weight coefficient corresponding to the request time is 0.2, and the weight coefficient corresponding to the most recent request success rate is 0.3, the link parameters of backup link 1 are: 8*0.5+8*0.2+10*0.3=8.6. Similarly, the link parameters of backup link 2 are: 9*0.5+9*0.2+10*0.3=9.3.

[0104] Afterwards, the link parameters of each backup link can be compared. The larger the link parameter, the higher the stability of the backup link. Therefore, the backup link with the largest link parameter can be selected as the target backup link from among multiple backup links. For example, in the example in Table 2, the link parameter of backup link 1 is 8.6, and the link parameter of backup link 2 is 9.3. By comparing the link parameters of the two, backup link 2 is determined as the target backup link.

[0105] After determining the target backup link through the above process, the communication link of the business application can be switched from the original primary link for accessing the cache in the same region to the target backup link for accessing the cache across regions. Subsequent business requests can access the corresponding cache through the target backup link, avoiding a large number of requests flooding into the database.

[0106] It is worth noting that the above mainly uses the process of business applications accessing the local cache as an example. The process of business applications accessing the server cache is the same. Those skilled in the art can undoubtedly understand and fully implement it by referring to the above, and this specification will not go into details.

[0107] In some implementations, the business system can detect the availability of each link in real time through the aforementioned process, and can display the availability of each link through a user interface. For example, in one example, an interface for displaying link performance parameters can be configured in the business application, and data such as the access success rate, request time, and link parameters of each link can be displayed in real time on the user interface, so that staff can view the current link status of the business system in real time through the user interface.

[0108] In some embodiments, the business system can provide a manual switching capability of the communication link on the user interface. For example, in one example, when the staff finds that the current main link is abnormal through the user interface, they can manually switch the main link to another backup link without waiting for the business system to automatically switch the link. In addition, the staff can view the faulty link through the user interface and repair the faulty link in time to ensure system stability. Those skilled in the art can understand and fully implement this, and this description will not be repeated.

[0109] In any of the above embodiments, when a primary link is abnormally blown, the business system can switch the link of the business application to the target backup link. In the process of sending business requests using the target backup link, the business system can send a liveness request to the primary link at regular intervals. The purpose of sending the liveness request is: when the primary link has abnormalities such as network jitter, the network may return to normal after a period of time, so that the primary link becomes available and stable again. If the communication link remains on the target backup link, the primary link will be idle, and cross-regional access requests will take longer.

[0110] Therefore, in some implementations of the present specification, when the primary link is abnormally blown, the business application can define a half-open time period of the primary link when using the target backup link to communicate. The half-open time period refers to sending a detection request to the first cache in the same area through the primary link at regular intervals.

[0111] When the primary link is restored to normal, the first cache can normally receive the live detection request and return a response signal to the business application, so that it can be determined that the primary link has been restored to normal, and the communication link can be switched from the target backup link back to the primary link, that is, the fuse state of the primary link is cancelled, and subsequent business requests will access the first cache in the same area through the primary link. On the contrary, if the primary link has not been restored to normal, the first cache cannot normally respond to the live detection request, then the target backup link can continue to send business requests, that is, the fuse state of the primary link is maintained, and wait for the next half-open time period to arrive.

[0112] In the implementation manner of this specification, the half-open time period for sending the liveness detection request can be set according to specific scenario requirements, and this specification does not impose any limitation on this.

[0113] From the above, it can be seen that in the implementation mode of this specification, when the main link is abnormally blown, it is possible to promptly discover whether the main link has recovered and is available through periodic detection, and when the main link has recovered and is available, the communication link is switched back to the main link, thereby improving the efficiency of service request processing.

[0114] In an example of the business request processing method implemented in this specification, taking a business application in region A as an example, the business application generates a business request and sends it to a proximal cache a in the same region. When the primary link for the business application to access proximal cache a is abnormal, the target backup link can be determined from backup link 1 for accessing proximal cache b in region B and backup link 2 for accessing proximal cache c in region C.

[0115] Assuming that the target backup link is backup link 1, the business request accesses the proximal cache b in region B through the target backup link 1, and returns the queried business results to the business application. If the business results are not queried through the target backup link 1, the server cache a in region A can be accessed according to the business request. If the primary link between the business application and the server cache a is abnormal, the target backup link can be determined from the backup link 3 for accessing the server cache b in region B and the backup link c for accessing the server cache 4 in region C.

[0116] Assuming that the target backup link is backup link 4, the business request accesses the server cache in region C through target backup link 4, and returns the queried business results to the business application. If the business results are not queried through target backup link 4, the query results can be obtained by accessing the underlying database (DB) according to the business request.

[0117] In the above process, for a primary link in a blown state, the link can be restored to a normal state after manually eliminating the fault through the method described above, or restored to a normal state through periodic detection.

[0118] From the above, it can be known that in the implementation of this specification, by real-time detection of the operation of the communication link, cache anomalies can be discovered in time and abnormal links can be fused. When an abnormal failure occurs in the primary link between the business application and the cache in the same region, the backup link can be switched to access the cache in other regions, thereby improving the success rate and request time of the cache request, avoiding a large number of business requests from penetrating into the database, and improving the stability and reliability of the business system. Moreover, it is possible to timely discover whether the primary link has been restored and available through periodic detection, and when the primary link is restored and available, the communication link can be switched back to the primary link, thereby improving the efficiency of business request processing.

[0119] In some implementations, this specification provides a service request processing device, which can be applied to the service system of any of the above implementations. Figure 5 As shown, the device comprises:

[0120] The service application module 10 is configured to access a first cache in the same region as the service request according to the service request;

[0121] The disaster recovery module 20 is configured to determine a target backup link from multiple backup links used to access caches in other regions when an abnormality occurs in the main link used to access the first cache, send the service request using the target backup link, and query the service result in the second cache corresponding to the target backup link.

[0122] In some implementations, the disaster recovery module 20 is configured as follows:

[0123] Creating a time wheel with a preset time period, and collecting service data of the primary link in each time period of the time wheel;

[0124] Determine a current link parameter based on the service data of the previous time period, wherein the link parameter is used to indicate the availability of the link;

[0125] When the link parameter is greater than or equal to a preset threshold, it is determined that no abnormality occurs in the primary link, and when the link parameter is less than the preset threshold, it is determined that an abnormality occurs in the primary link.

[0126] In some implementations, the disaster recovery module 20 is configured as follows:

[0127] Creating a time wheel with a preset time period, and collecting service data of each standby link in each time period of the time wheel;

[0128] For each standby link, based on the service data of the previous time period, determine the current link parameter, wherein the link parameter is used to indicate the availability of the link;

[0129] The link parameters of the various backup links are compared, and the backup link with the largest link parameter is determined as the target backup link.

[0130] In some implementations, the disaster recovery module 20 is configured as follows:

[0131] Determine the access success rate, request duration, and most recent request success rate of the primary link based on the service data of the previous time period;

[0132] The access success rate, the request time consumption and the most recent request success rate are integrated and calculated to determine the current link parameters.

[0133] In some implementations, the disaster recovery module 20 is configured as follows:

[0134] During communication through the target standby link, periodically sending a liveness request to the first cache through the primary link;

[0135] In response to the first cache successfully responding to the detection request, the communication link is switched from the target backup link to the primary link.

[0136] In some implementations, the cache includes a local cache and / or a server cache.

[0137] In some implementations, the business application module 10 is configured as:

[0138] When no service result corresponding to the service request is found in the access to the local cache, the service request is sent to the server cache in the same region as the service request;

[0139] When no business result is found by accessing the server cache in the same region as the business request, the database is queried according to the business request to obtain the business result.

[0140] In some implementations, this specification provides an electronic device, including:

[0141] processor;

[0142] A memory stores computer instructions, wherein the computer instructions are used to enable a processor to execute the method described in any of the above embodiments.

[0143] In some embodiments, the present specification provides a storage medium storing computer instructions, wherein the computer instructions are used to implement the method described in any of the above embodiments.

[0144] In some embodiments, this specification provides a computer program product, which is used to implement the method described in any of the above embodiments.

[0145] Figure 6 is a schematic structural diagram of an electronic device provided by an exemplary embodiment. Figure 6 At the hardware level, the electronic device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710, and may also include hardware required for other functions. One or more embodiments of this specification may be implemented based on software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into the memory 708 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

Claims

1. A method for processing a business request, characterized in that: Applied to a business system, the business system includes a database and multiple caches deployed in different regions, the method includes: accessing, according to the service request, a first cache in the same region as the service application that initiated the service request; In the event that an abnormality occurs in a primary link for accessing the first cache, determining a target backup link from a plurality of backup links for accessing caches in other regions; The service request is sent using the target standby link, and the service result is queried in the second cache corresponding to the target standby link.

2. The method according to claim 1, characterized in that The process of determining whether the primary link is abnormal includes: Creating a time wheel with a preset time period, and collecting service data of the primary link in each time period of the time wheel; Determine a current link parameter based on the service data of the previous time period, wherein the link parameter is used to indicate the availability of the link; When the link parameter is greater than or equal to a preset threshold, it is determined that no abnormality occurs in the primary link, and when the link parameter is less than the preset threshold, it is determined that an abnormality occurs in the primary link.

3. The method according to claim 1, characterized in that A target backup link is determined from multiple backup links for accessing caches in other regions, including: Creating a time wheel with a preset time period, and collecting service data of each standby link in each time period of the time wheel; For each standby link, based on the service data of the previous time period, determine the current link parameter, wherein the link parameter is used to indicate the availability of the link; The link parameters of the various backup links are compared, and the backup link with the largest link parameter is determined as the target backup link.

4. The method according to claim 2 or 3, characterized in that: Based on the service data of the previous time period, determine the current link parameters, including: Determine the access success rate, request duration, and most recent request success rate of the primary link based on the service data of the previous time period; The access success rate, the request time consumption and the most recent request success rate are integrated and calculated to determine the current link parameters.

5. The method according to claim 1, characterized in that Also includes: During communication through the target standby link, periodically sending a liveness request to the first cache through the primary link; In response to the first cache successfully responding to the detection request, the communication link is switched from the target backup link to the primary link.

6. The method according to claim 1, characterized in that The cache includes a local cache and / or a server cache.

7. The method according to claim 1, characterized in that The cache includes a local cache and a server cache, and the method further includes: When no service result corresponding to the service request is found in the access to the local cache, the service request is sent to the server cache in the same region as the service request; When no business result is found by accessing the server cache in the same region as the business request, the database is queried according to the business request to obtain the business result.

8. A service request processing device, characterized in that: Applied to a business system, the business system includes a database and multiple caches deployed in different regions, and the device includes: A business application module is configured to access, according to a business request, a first cache in the same region as the business application that initiated the business request; The disaster recovery module is configured to determine a target backup link from multiple backup links used to access caches in other regions when an abnormality occurs in the main link used to access the first cache, send the service request using the target backup link, and query the service result in the second cache corresponding to the target backup link.

9. An electronic device, characterized in that: include: processor; A memory storing computer instructions, wherein the computer instructions are used to enable a processor to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The computer program product is used to implement the method according to any one of claims 1 to 7.

Images