Data processing methods, apparatus and equipment

Abstract

This application discloses a data processing method, apparatus, and device. The method includes obtaining a token escrow data configuration table containing N configuration data entries from a third-party platform in a first service system; determining the verification result of a first token corresponding to a first platform identifier of the third-party platform in the N configuration data entries based on token verification information in a remote dictionary service, wherein the remote dictionary service stores tokens from the third-party platform obtained by at least two service systems; when the verification result indicates that the first token is invalid, sending a second request to the third-party platform to request a second token associated with the first platform identifier; and upon receiving a second token from the third-party platform, storing first association information between the first platform identifier and the second token in the remote dictionary service, and updating the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table. This achieves unified maintenance of third-party platform tokens and improves service stability.

Description

Technical Field

[0001] This application belongs to the field of computer application technology, and in particular relates to a data processing method, apparatus and device. Background Technology

[0002] Service platforms or sub-platforms within service platforms often involve multiple systems calling external interfaces provided by a third-party platform to access the platform. When calling these external interfaces, authentication is required using the third-party platform's account and token. A single platform account can be used by multiple systems, while the token needs to be refreshed and acquired periodically.

[0003] In related technologies, service platforms and multiple systems on different sub-platforms typically maintain and manage tokens independently. However, this maintenance method is prone to token refreshes by different systems, causing tokens used by other systems on the service platform or sub-platforms to become invalid, resulting in interruptions to access third-party platforms and affecting the normal operation of services. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, and storage medium that can solve the problem in related technologies where refreshing tokens in different systems causes the tokens being used by other systems on the service platform or sub-platform to become invalid, affecting service stability.

[0005] In a first aspect, embodiments of this application provide a data processing method, which may include:

[0006] Obtain the token escrow data configuration table from the first service system. The token escrow data configuration table includes N configuration data entries from the third-party platform, where N is a positive integer.

[0007] Based on the token verification information in the remote dictionary service, determine the verification result of the first token corresponding to the first platform identifier of the third-party platform in N configuration data. The remote dictionary service is used to store the tokens of the third-party platform obtained by at least two service systems, including the first service system.

[0008] If the verification result indicates that the first token is invalid, a second request is sent to the third-party platform. The second request is used to request the first platform to identify the associated second token.

[0009] Upon receiving a second token from a third-party platform, the system stores the first platform identifier and the first association information of the second token in the remote dictionary service, and updates the token escrow data configuration table with the latest token acquisition time corresponding to the first platform identifier.

[0010] Secondly, embodiments of this application provide a data processing apparatus, which may include:

[0011] The acquisition module is used to acquire the token escrow data configuration table in the first service system. The token escrow data configuration table includes N configuration data from the third-party platform, where N is a positive integer.

[0012] The determination module is used to determine the verification result of the first token corresponding to the first platform identifier of the third-party platform in N configuration data based on the token verification information in the remote dictionary service. The remote dictionary service is used to store the tokens of the third-party platform obtained by at least two service systems, including the first service system.

[0013] The sending module is used to send a second request to a third-party platform when the verification result indicates that the first token is invalid. The second request is used to request the first platform to identify the associated second token.

[0014] The processing module is used to store the first platform identifier and the first association information of the second token in the remote dictionary service when a second token is obtained from the third-party platform, and to update the latest token acquisition time corresponding to the first platform identifier in the token custody data configuration table.

[0015] Thirdly, embodiments of this application provide a computer device, which includes: a processor and a memory storing computer program instructions;

[0016] When the processor executes computer program instructions, it implements the data processing method as described in the first aspect.

[0017] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the data processing method as described in the first aspect.

[0018] Fifthly, embodiments of this application provide a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the data processing method as shown in the first aspect.

[0019] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the data processing method as described in the first aspect.

[0020] The data processing method, apparatus, device, and storage medium of this application embodiment obtain a token escrow data configuration table in a first service system, the token escrow data configuration table including N configuration data from a third-party platform; determine the verification result of a first token corresponding to a first platform identifier of the third-party platform in the N configuration data according to token verification information in a remote dictionary service, the remote dictionary service being used to store tokens obtained from the third-party platform by at least two service systems, the at least two service systems including the first service system; if the verification result indicates that the first token is invalid, send a second request to the third-party platform, the second request being used to request a second token associated with the first platform identifier; if a second token is obtained from the third-party platform, store the first association information of the first platform identifier and the second token in the remote dictionary service, and update the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table. In this way, based on the configuration data in the token escrow data configuration table, the platform identifier of the third-party platform is used to check whether the token corresponding to the platform identifier has expired. If the token has expired, the token refresh information of the third-party platform is dynamically added or removed by configuring the association information and updating the token escrow data configuration table. This allows for the addition or removal of the token refresh process without downtime. It can manage the token of the platform identifier of an external third-party platform that provides only one platform identifier for multiple service systems to use at the same time, and avoid the situation where multiple service systems compete for the refresh token, causing the token to expire. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application;

[0023] Figure 2 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0024] Figure 3 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of the structure of a data processing apparatus provided in one embodiment of this application;

[0026] Figure 5 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application. Detailed Implementation

[0027] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0028] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0029] The acquisition, storage, use, and processing of data (including but not limited to features and information mentioned in this document) in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0030] A service platform or its sub-platforms may contain multiple service systems that need to call third-party interfaces of external platforms or their sub-platforms to access those platforms. These multiple service systems can be within the same service platform or on different sub-platforms. When calling external third-party interfaces, a pre-acquired token is typically required for authentication. Generally, a service platform can only apply for one platform account on a third-party platform for use by that service platform or its sub-platforms. In this case, if multiple service systems need to use third-party capabilities, each service system can manage its own token refresh process.

[0031] However, if each service system is left to maintain its own token, there's a high probability that if one service system refreshes its token, another service system using the old token will be unable to access data from the third-party platform, thus impacting business operations. For example, both service system 1 and service system 2 have the function of maintaining and managing tokens. If service system 1 calls the third-party platform's interface at 12:00 to request token 1, and service system 2 calls the third-party platform's interface at 12:05 to request token 2, normally, since service system 1 obtains token 1 first, it will use token 1 to access... The third-party platform is requested to write token1 to the storage space to update the latest token acquisition time in the storage space. However, sometimes service system 1 may fail to write token1 to the storage space in time due to factors such as signal delay or network instability. As a result, service system 2 writes token2 to the storage space before service system 1 writes token1. In this case, the acquisition time of token2 is the latest token acquisition time, and token1 will become invalid. This can easily lead to different systems refreshing tokens, causing the tokens being used by other service systems to become invalid, causing the service system to interrupt access to the third-party platform and affecting the normal operation of the service.

[0032] Furthermore, since the third-party interfaces used by the service system change with business updates, each time a new third-party interface is added or a third-party interface is taken offline, it is usually necessary to shut down the system, modify the code that calls the token acquisition interface, and redeploy it to take effect. As a result, every time a third-party platform's token is added or deleted, it will inevitably affect the user's experience.

[0033] To address the aforementioned technical problems, embodiments of this application provide a data processing method, apparatus, computer equipment, and storage medium.

[0034] Based on this, the following will be combined with the appendix Figures 1 to 5 This application describes in detail the data processing methods, apparatus, computer equipment, and storage media of the embodiments. It should be noted that these embodiments are not intended to limit the scope of this application.

[0035] Based on this, in order to better illustrate the content of the embodiments of this application, the following will be combined with Figure 1 The data processing system provided in the embodiments of this application will be described in detail below.

[0036] The data processing system 10 may include a third-party centralized token management system, M service systems, and a remote dictionary service, where M is a positive integer.

[0037] The M service systems include a first service system, a second service system, ..., and an Mth service system. These M service systems can be configured on a single service device or multiple service devices. The service device can be a device of the service platform or a device of a sub-platform within the service platform. Each service system may include a token escrow data configuration table, which contains N configuration data entries for each third-party platform. This configuration data is generated by the service system for each request from a third-party platform and the process of associating that third-party platform's token with that request.

[0038] Redis (Remote Dictionary Server) is an open-source, ANSI C-written, network-enabled, in-memory or persistent, log-structured key-value database that provides application programming interfaces (APIs) in multiple languages. It is a high-performance key-value database. Specifically, Redis can store data based on key-value mappings and provide the latest tokens obtained from a third-party platform to M service systems.

[0039] The centralized third-party token management system is used to manage tokens used by M service systems to access third-party platforms. The centralized third-party token management system has an application module that refreshes tokens periodically. Every minute, it scans the token custody data configuration table, then iterates through each configuration data in the token custody data configuration table, uses the platform identifier of the third-party platform and queries the corresponding value in Redis to calculate whether the token is invalid. There is also a manual refresh interface used when the token is missing in Redis. Specifically, the centralized third-party token management system can obtain the token escrow data configuration table from any of the M service systems, such as the first service system, based on a scheduled task of the third-party platform or user input. The token escrow data configuration table includes N configuration data entries from the third-party platform, where N is a positive integer. Based on the token verification information in the remote dictionary service, it determines the verification result of the first token corresponding to the first platform identifier of the third-party platform among the N configuration data entries. The remote dictionary service stores tokens from the third-party platform obtained by at least two service systems, including the first service system. If the verification result indicates that the first token is invalid, a second request is sent to the third-party platform to request the second token associated with the first platform identifier. If the second token is received from the third-party platform, the first association information between the first platform identifier and the second token is stored in the remote dictionary service, and the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table is updated.

[0040] Here, the token escrow data configuration table can be stored in a database. The configuration data can store the following fields: the platform identifier of the third-party platform, the Uniform Resource Locator (URL) of the interface, the interface protocol, the interface calling method, the input parameter exchange format (JSON), the output parameter regular expression, the token validity period, the latest token acquisition time, and the token update interval. Thus, when it's necessary to add or remove tokens to access external interfaces of third-party platforms, simply add or remove configuration data from this token escrow data configuration table. No downtime or upgrades are required. The centralized third-party token management system will dynamically call the relevant external interfaces based on the configuration data in the token escrow data configuration table and extract the tokens for management in a remote dictionary service.

[0041] Specifically, the platform identifier in this embodiment is a unique identifier string (key). As a unique identifier for a third-party platform, one third-party platform can correspond to one platform identifier, such as the first platform identifier and the second platform identifier of a newly added third-party platform in this embodiment. This platform identifier can also be used as a Redis key to store the corresponding token value, allowing other systems to retrieve the token corresponding to the platform identifier from Redis. The Uniform Resource Locator (URL) of the interface is the URL of the third-party platform's token retrieval interface. The interface protocol can be Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). Interface call methods include GET and POST. The GET method is used to request specific resources, such as tokens, from the third-party platform; the POST method is used to retrieve specific resources, such as tokens, from the third-party platform. JSON is a JSON string assembling the function parameters passed when calling the third-party platform to retrieve tokens, such as Header and Body parameters. The JSON is parsed and used by the third-party centralized token management system when calling the external interface of the third-party platform. The token validity period is the token validity period specified by the third-party platform, in minutes. The latest token acquisition time is empty during initialization. This field is updated with the current time each time the token is successfully refreshed to Redis. The token update interval specifies how many minutes before the token expires to update it, preventing tokens from being missing or expired in Redis.

[0042] Therefore, the data processing method provided in this application embodiment is based on the configuration data in the token custody data configuration table. By using the platform identifier of the third-party platform, it verifies whether the token corresponding to the platform identifier has expired. In the case of expired token, the token of the third-party platform can be dynamically added or removed by configuring the association information and updating the token custody data configuration table. This allows the third-party token centralized management system to uniformly maintain the token of the platform identifier, while avoiding the situation where multiple service systems compete to refresh the token, resulting in the token becoming invalid. It also allows the token refresh process to be released or taken offline without downtime, reducing the impact on the business of the token user.

[0043] It should be noted that the data processing method provided in this application embodiment can be applied to the scenario of centralized management of tokens for a third-party platform when the third-party platform only provides one platform identifier for use by multiple internal service systems.

[0044] Based on this, the following is combined with Figure 2 The following describes a data processing method provided in an embodiment of this application.

[0045] Figure 2 This is a flowchart of a data processing method provided in an embodiment of this application.

[0046] like Figure 2 As shown, this data processing method can be applied to a data processing system, which can be installed in a computer device. Specifically, the data processing method may include the following steps:

[0047] Step 210: Obtain the token escrow data configuration table from the first service system. The token escrow data configuration table includes N configuration data entries from the third-party platform, where N is a positive integer. Step 220: Based on the token verification information in the remote dictionary service, determine the verification result of the first token corresponding to the first platform identifier of the third-party platform among the N configuration data entries. The remote dictionary service stores tokens from the third-party platform obtained by at least two service systems, including the first service system. Step 230: If the verification result indicates that the first token is invalid, send a second request to the third-party platform. The second request requests the second token associated with the first platform identifier. Step 240: If the second token is received from the third-party platform, store the first association information between the first platform identifier and the second token in the remote dictionary service, and update the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table.

[0048] In this way, based on the configuration data in the token escrow data configuration table, the platform identifier of the third-party platform is used to check whether the token corresponding to the platform identifier has expired. If the token has expired, the token refresh information of the third-party platform is dynamically added or removed by configuring the association information and updating the token escrow data configuration table. This allows for the addition or removal of the token refresh process without downtime. It can manage the token of the platform identifier of an external third-party platform that provides only one platform identifier for multiple service systems to use at the same time, and avoid the situation where multiple service systems compete for the refresh token, causing the token to expire.

[0049] The steps described above are explained in detail below.

[0050] First, regarding step 210, in some embodiments of this application, before step 210, the data processing method may further include step 250: sending a first request to the lock service system, the first request being used to request a distributed lock, the distributed lock being used to limit the number of service systems requesting tokens from a third-party platform within the same time window.

[0051] For example, such as Figure 1 The third-party token centralized management system shown needs to be deployed in a distributed multi-instance manner to improve system reliability. To avoid multiple instances in the third-party token centralized management system calling the external interface of the third-party platform to obtain tokens at the same time, each instance needs to acquire a distributed lock before executing the process of reading the token escrow data configuration table from the storage space of the first service system. If the instance has acquired the distributed lock, then step 210 is executed; otherwise, if the instance has not acquired the distributed lock, the process ends. In this way, it can be guaranteed that only one instance is working at the same time.

[0052] In this way, by requesting a distributed lock, the token stored in Redis can be updated in a single thread, avoiding the token expiration problem caused by multi-threaded updates.

[0053] Specifically, this application provides two ways to trigger the execution of step 250, as shown below.

[0054] Method 1, step 250 may specifically include:

[0055] If the scheduled task corresponds to a third-party platform and the preset execution time of the scheduled task matches the current system time of the first service system, a first request is sent to the lock service system.

[0056] For example, a scheduled task is included in the third-party token centralized management system, and when the scheduled task is started, a first request is sent to the system being served.

[0057] It should be noted that the lock service system in this application embodiment can be a system used to manage distributed locks in a third-party centralized token management system, or it can be set up in a system such as... Figure 1 The system for managing distributed locks in the data processing system shown can also be a system set up in Redis for managing distributed locks.

[0058] Method 2, step 250 may specifically include:

[0059] Upon receiving a token request from the client, a first request is sent to the lock service system. This token request is used to trigger the acquisition of the latest token from the third-party platform.

[0060] For example, if a token request is received from a client, indicating that the client needs to obtain a token, a first request can be sent to the lock service system.

[0061] It should be noted that in this embodiment of the application, when a token request is received from the client, in addition to sending a first request to the lock service system, the token can also be obtained directly from Redis using the key. If the key does not exist in Redis, the client enables the compensation mechanism, that is, it calls the manual token acquisition interface of the third-party token centralized management system, passes in the key, and the third-party token centralized management system will directly obtain a new token from the third party using the key, forward it to the client, and refresh the token in Redis.

[0062] Based on this, step 210 may specifically include:

[0063] Upon receiving a distributed lock from the lock service system, the token escrow data configuration table is read from the storage space of the first service system.

[0064] It should be noted that the configuration data in this application embodiment includes the first platform identifier, the interface's Uniform Resource Locator, the interface protocol, the interface calling method, the input parameter exchange format, the output parameter regular expression, the token validity period, the latest time the token was acquired, and the token update time interval.

[0065] The Uniform Resource Locator (URL) for the API is the URL of the third-party platform's token retrieval interface. The API protocol can be Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). API calls can be made using GET and POST methods. GET is used to request specific resources, such as a token, from the third-party platform; POST is used to retrieve specific resources, such as a token, from the third-party platform. JSON is a string representing the function parameters passed when calling the third-party platform to retrieve the token, such as header and body parameters. This JSON is parsed and used by the third-party centralized token management system when calling the third-party platform's external API. The token validity period is the time specified by the third-party platform, in minutes. The latest token acquisition time is empty upon initialization; it is updated to this field after each successful token refresh to Redis. The token update interval specifies how many minutes before the token expires to update it, preventing tokens from being missing or invalid in Redis.

[0066] Next, in step 220, the scheduled task can first read configuration data from the token custody data configuration table. If the obtained configuration data is empty, it means that no third-party platform has been introduced for token custody, and the scheduled task ends. Otherwise, step 220 is executed.

[0067] Based on this, in some embodiments of this application, the token verification information includes the platform identifier and the token association information. Based on this, step 220 may specifically include steps 2201 and 2202.

[0068] Step 2201: Traverse N configuration data entries and match the first platform identifier in each of the N configuration data entries with the association information of the platform identifier and the token to obtain the matching result.

[0069] Step 2202: If the matching result indicates that no token corresponding to the first platform identifier is matched, a verification result is generated to indicate that the first token is invalid.

[0070] For example, configuration data is obtained from the token custody data configuration table. If configuration data exists, that is, the configuration data is not empty, the obtained configuration data is traversed, and the key in each configuration data is searched in Redis. If the key does not exist in Redis, it means that the token of the key has reached the renewal condition, that is, the first token has expired.

[0071] In some other embodiments of this application, the token verification information includes verification conditions. Based on this, step 220 may specifically include steps 2203 and 2204.

[0072] Step 2203: Obtain the first token corresponding to the first platform identifier from the token verification information. The first token is the latest token of the third-party platform stored in the remote dictionary service. The first token has a first time for updating the first token and a first validity time.

[0073] Step 2204: If the verification conditions are met at the first time and the first valid time, a verification result is generated to indicate that the first token has expired; wherein, the verification conditions include that the difference between the target time and the current system time of the first service system is less than the token update time interval, and the target time is the sum of the first time and the first valid time.

[0074] For example, configuration data is obtained from the token custody data configuration table. If configuration data exists, when retrieving configuration data from database table A, if data exists, the first time and the first validity time of updating the first token are obtained. The first time and the first validity time of updating the first token are verified to meet the following verification condition: (first time of updating the first token + first validity time - current system time of the first service system) < token update interval. When the verification condition is met, it means that the token of the current key has reached the renewal condition, that is, the first token has expired.

[0075] Furthermore, regarding step 230, in some embodiments of this application, step 230 may specifically include steps 2301 to 2303.

[0076] Step 2301: If the verification result indicates that the first token is invalid, obtain the first configuration data corresponding to the first platform identifier from N configuration data.

[0077] Step 2302: Based on the target data in the first configuration data, generate a second request. The target data includes the interface's Uniform Resource Locator, interface protocol, and interface invocation method.

[0078] Step 2303: Call the external interface of the third-party platform and send a second request to the third-party platform.

[0079] For example, based on the URL, interface protocol, interface call method, and input parameter JSON in N configuration data entries for this key, a second request, such as an HTTP or HTTPS request, is assembled, and the external interface of the third-party platform is invoked to send the second request to the third-party platform.

[0080] In addition, after step 230, the data processing method further includes the process of extracting the second token. Based on this, the data processing method may also include steps 2601 and 2602.

[0081] Step 2601: Receive the response information sent by the third-party platform corresponding to the second request.

[0082] For example, continuing with the content shown in step 2303 above, response information can also be received through the external interface of the third-party platform.

[0083] Step 2602: Extract the second token from the response information using the output parameter regular expression of the first configuration data.

[0084] For example, the second token in the response information is obtained using the output parameter regular expression in the first configuration data corresponding to the key.

[0085] Then, regarding step 240, in some embodiments of this application, step 240 includes steps 2401 to 2403.

[0086] Step 2401: Use the first platform identifier as the index of the remote dictionary service and the second token as the value to obtain the mapping information.

[0087] Step 2402: Adjust the update token time interval in the remote dictionary service according to the second validity period of the second token;

[0088] Step 2403: Based on the mapping information and the token update time interval, store the first association information of the first platform identifier and the second token in the remote dictionary service.

[0089] For example, taking the example shown in step 2602 above, the key can be used as a Redis index and the token as the value and stored together in Redis so that multiple service platforms can access it to obtain the latest token.

[0090] In some other embodiments of this application, step 240 may include step 2404, adding a second configuration data entry to the token escrow data configuration table. The second configuration data includes a second time for updating the second token. The second time is used to identify the latest time when the third-party platform obtained the token stored in the token escrow data configuration table.

[0091] For example, the automatic expiration time of the second token in Redis is set according to the token validity period in the token escrow data configuration table, and the last time the token was obtained is updated in the token escrow data configuration table.

[0092] Furthermore, the data processing method provided in this application embodiment may also include steps 2701 to 2704, as detailed below.

[0093] Step 2701: Receive a token escrow request sent by the newly added third-party platform. The token escrow request carries the second platform identifier of the newly added third-party platform.

[0094] Step 2702: In response to the token escrow request, add the third configuration data of the newly added third-party platform to the token escrow data configuration table.

[0095] Step 2703: Based on the third configuration data, obtain the third token corresponding to the second platform identifier.

[0096] Step 2704: Store the second association information of the second platform identifier and the third token in the remote dictionary service.

[0097] For example, if a token escrow request is received from another third-party platform, i.e., a newly added third-party platform, the third-party token centralized management system can add the third configuration data of the newly added third-party platform to the token escrow data configuration table, and update the third token of the newly added third-party platform through the steps involved in steps 210 to 230 above.

[0098] Therefore, this embodiment dynamically adds or removes token refresh information from third-party platforms by configuring associated information and updating the token escrow data configuration table. This allows the centralized third-party token management system to add or remove token refresh processes without downtime, minimizing the impact on business systems. This enables the unified maintenance of tokens for external third-party platforms that provide only one platform identifier for multiple service systems to use simultaneously, while preventing token expiration due to competition for refresh tokens among multiple service systems. Furthermore, N configuration data entries are used to configure the input and output parameters of the third-party platform's token acquisition interface, achieving the goal of no code changes and no downtime for upgrades.

[0099] Based on this, in order to better explain as Figure 2 The content shown below, in conjunction with Figure 3 Taking a scheduled task as an example, the data processing method provided in this application embodiment will be described in detail.

[0100] Step 310: If the scheduled task is corresponding to a third-party platform and the preset execution time of the scheduled task matches the current system time of the first service system, send a first request to the lock service system.

[0101] Step 320: Upon receiving the distributed lock sent by the lock service system, read the token escrow data configuration table from the storage space of the first service system.

[0102] Conversely, if no distributed lock is received from the lock service system, the process ends.

[0103] Step 330: If the token escrow data configuration table contains N configuration data entries, iterate through the N configuration data entries and match the first platform identifier in each of the N configuration data entries with the association information between the platform identifier and the token to obtain a matching result. Conversely, if the token escrow data configuration table does not contain N configuration data entries (i.e., the value is empty), end the process. If the matching result indicates that no token corresponding to the first platform identifier was found, generate a verification result indicating that the first token is invalid. Conversely, if the matching result indicates that a token corresponding to the first platform identifier was found, end the process.

[0104] Step 340: If the verification result indicates that the first token is invalid, a second request is sent to the third-party platform. The second request is used to request the first platform to identify the associated second token.

[0105] It should be noted that step 340 is similar in principle to step 230 above. For details, please refer to the content shown in step 230 above. It will not be repeated here.

[0106] Step 350: Upon receiving the second token from the third-party platform, store the first association information between the first platform identifier and the second token in the remote dictionary service, and update the latest token acquisition time corresponding to the first platform identifier in the token custody data configuration table.

[0107] It should be noted that step 350 is similar in principle to step 240 above. For details, please refer to the content shown in step 240 above. It will not be repeated here.

[0108] Therefore, the HTTP and JSON interfaces for obtaining tokens from third-party platforms in this application embodiment are based on technologies such as Redis, token escrow data configuration tables, regular expressions, and scheduled tasks. Specifically, Redis is used to centrally store tokens, and the token value in Redis is updated using a single thread, avoiding token expiration issues caused by multi-threaded updates. The token escrow data configuration table is used to configure the input and output parameters of the token acquisition interface for third-party platforms, achieving the goal of no code changes and no downtime upgrades. Regular expressions are used to extract the token value, and once the token is stored in Redis in key+value format, Redis's built-in expiration function manages the token's lifecycle.

[0109] This application also provides a data processing apparatus, specifically combined with... Figure 4 Please provide a detailed explanation.

[0110] Figure 4 This is a schematic diagram of the structure of a data processing apparatus provided in one embodiment of this application.

[0111] In some embodiments of this application, Figure 4 The data processing device shown can be installed in the computing device provided in the embodiments of this application.

[0112] like Figure 4 As shown, the data processing device 40 may specifically include:

[0113] The acquisition module 401 is used to acquire the token escrow data configuration table in the first service system. The token escrow data configuration table includes N configuration data from the third-party platform, where N is a positive integer.

[0114] The determination module 402 is used to determine the verification result of the first token corresponding to the first platform identifier of the third-party platform in N configuration data based on the token verification information in the remote dictionary service. The remote dictionary service is used to store the tokens of the third-party platform obtained by at least two service systems, including the first service system.

[0115] The sending module 403 is used to send a second request to a third-party platform when the verification result indicates that the first token is invalid. The second request is used to request the first platform to identify the associated second token.

[0116] The processing module 404 is used to store the first platform identifier and the first association information of the second token in the remote dictionary service when a second token is obtained from the third-party platform, and to update the latest token acquisition time corresponding to the first platform identifier in the token custody data configuration table.

[0117] In this way, the token escrow data configuration table in the first service system is obtained, which includes N configuration data entries from the third-party platform; based on the token verification information in the remote dictionary service, the verification result of the first token corresponding to the first platform identifier of the third-party platform in the N configuration data is determined, whereby the remote dictionary service is used to store tokens obtained from the third-party platform by at least two service systems, including the first service system; if the verification result indicates that the first token is invalid, a second request is sent to the third-party platform, which requests the second token associated with the first platform identifier; if the second token is obtained from the third-party platform, the first association information between the first platform identifier and the second token is stored in the remote dictionary service, and the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table is updated. In this way, based on the configuration data in the token escrow data configuration table, the platform identifier of the third-party platform is used to check whether the token corresponding to the platform identifier has expired. If the token has expired, the token refresh information of the third-party platform is dynamically added or removed by configuring the association information and updating the token escrow data configuration table. This allows for the addition or removal of the token refresh process without downtime. It can manage the token of the platform identifier of an external third-party platform that provides only one platform identifier for multiple service systems to use at the same time, and avoid the situation where multiple service systems compete for the refresh token, causing the token to expire.

[0118] The data processing device 40 in the embodiments of this application will be described in detail below.

[0119] In some embodiments of this application, the data processing device 40 may further include a reading module; wherein,

[0120] The sending module 403 can also be used to send a first request to the lock service system. The first request is used to request a distributed lock. The distributed lock is used to limit the number of service systems that request tokens from the third-party platform within the same time window.

[0121] The read module is used to read the token escrow data configuration table from the storage space of the first service system when a distributed lock is received from the lock service system.

[0122] In some other embodiments of this application, the sending module 403 in this application embodiment can be specifically used to send a first request to the lock service system when there is a scheduled task corresponding to a third-party platform and the preset execution time of the scheduled task matches the current system time of the first service system.

[0123] Alternatively, the sending module 403 in the application embodiment can be specifically used to send a first request to the lock service system upon receiving a token request sent by the client. The token request is used to trigger the acquisition of the latest token from the third-party platform.

[0124] In some other embodiments of this application, the data processing device 40 may further include a matching module and a first generation module; wherein,

[0125] The matching module is used to traverse N configuration data when the token verification information includes the platform identifier and the token association information, and match the first platform identifier in the N configuration data with the platform identifier and the token association information to obtain the matching result;

[0126] The first generation module is used to generate a verification result indicating that the first token is invalid when the matching result indicates that no token corresponding to the first platform identifier is matched.

[0127] In some further embodiments of this application, the data processing device 40 may further include a second generation module; wherein,

[0128] The acquisition module 401 is used to acquire the first token corresponding to the first platform identifier from the token verification information when the token verification information includes verification conditions. The first token is the latest token of the third-party platform stored in the remote dictionary service. The first token corresponds to the first time of updating the first token and the first valid time.

[0129] The second generation module is used to generate a verification result indicating that the first token has expired, provided that the verification conditions are met at the first time and the first valid time.

[0130] The verification conditions include that the difference between the target time and the current system time of the first service system is less than the token update interval, and the target time is the sum of the first time and the first valid time.

[0131] In some further embodiments of this application, the data processing device 40 may further include a third generation module; wherein,

[0132] The acquisition module 401 can also be used to retrieve the first configuration data corresponding to the first platform identifier from N configuration data when the verification result indicates that the first token is invalid.

[0133] The third generation module is used to generate a second request based on the target data in the first configuration data. The target data includes the interface's Uniform Resource Locator, interface protocol, and interface calling method.

[0134] The acquisition module 401 can also be used to call the external interface of a third-party platform and send a second request to the third-party platform.

[0135] In some further embodiments of this application, the data processing device 40 may further include a first receiving module and an extraction module; wherein,

[0136] The first receiving module is used to receive response information sent by a third-party platform corresponding to the second request;

[0137] The extraction module is used to extract the second token from the response information using the output parameter regular expression of the first configuration data.

[0138] In some further embodiments of this application, the data processing device 40 may further include an adjustment module and a first storage module; wherein,

[0139] The determination module 402 can also be used to obtain mapping information by using the first platform identifier as the index of the remote dictionary service and the second token as the value.

[0140] The adjustment module is used to adjust the update token time interval in the remote dictionary service based on the second validity period of the second token;

[0141] The first storage module is used to store the first association information of the first platform identifier and the second token in the remote dictionary service based on the mapping information and the token update time interval.

[0142] In some other embodiments of this application, the processing module 404 may be specifically used to add a second configuration data entry to the token escrow data configuration table. The second configuration data includes a second time for updating the second token. The second time is used to identify the latest time when the third-party platform obtained the token stored in the token escrow data configuration table.

[0143] In some other embodiments of this application, the configuration data includes a first platform identifier, a Uniform Resource Locator (URL) for the interface, an interface protocol, an interface invocation method, an input parameter exchange format, an output parameter regular expression, a token validity period, the time of the latest token acquisition, and a token update interval.

[0144] In some further embodiments of this application, the data processing device 40 may further include a second receiving module and a second storage module; wherein,

[0145] The second receiving module is used to receive token escrow requests sent by newly added third-party platforms. The token escrow requests carry the second platform identifier of the newly added third-party platforms.

[0146] Specifically, processing module 404 can be used to add third-party configuration data of the third-party platform to the token escrow data configuration table in response to a token escrow request.

[0147] The acquisition module 401 is used to acquire the third token corresponding to the second platform identifier based on the third configuration data;

[0148] The second storage module is used to store the second association information of the second platform identifier and the third token in the remote dictionary service.

[0149] Based on the same inventive concept, this application also provides a computer device. (Specifically combined with...) Figure 5 Please provide a detailed explanation.

[0150] Figure 5 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application.

[0151] like Figure 5 As shown, the computer device may include at least one of the following as described in the embodiments of this application: an electronic device, a server. The computer device may include a processor 501 and a memory 502 storing computer program instructions.

[0152] Specifically, the processor 501 may include a central processing unit (CPU), an application-specific integrated circuit (ASTC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0153] Memory 502 may include a large-capacity memory for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 502 is non-volatile solid-state memory. In a particular embodiment, memory 502 includes solid-state storage (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0154] The processor 501 implements any of the data processing methods described in the above embodiments by reading and executing computer program instructions stored in the memory 502.

[0155] In one example, the computer device may also include a communication interface 503 and a bus 510. Wherein, as... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0156] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0157] Bus 510 includes hardware, software, or both, that couples components of a flow control device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard System (ETSA) bus, a Front Side Bus (FSB), an HyperTransport (HT) interconnect, an Industry Standard System (TSA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel System (MCA) bus, a Peripheral Component Interconnect (PCT) bus, a PCT-Express (PCT-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0158] The data processing device can execute the data processing method described in the embodiments of this application, thereby achieving the combination Figures 1 to 3 The data processing methods and apparatus described.

[0159] Furthermore, in conjunction with the data processing methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the data processing methods in the above embodiments.

[0160] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0161] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASTCs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0162] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0163] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A data processing method, characterized in that, include: Obtain the token escrow data configuration table from the first service system. The token escrow data configuration table includes N configuration data entries from the third-party platform, where N is a positive integer. Based on the token verification information in the remote dictionary service, the verification result of the first token corresponding to the first platform identifier of the third-party platform in the N configuration data is determined. The remote dictionary service is used to store the tokens of the third-party platform obtained by at least two service systems, including the first service system. If the verification result indicates that the first token is invalid, a second request is sent to the third-party platform, the second request being used to request the first platform to identify the associated second token; Upon receiving a second token from the third-party platform, the first association information between the first platform identifier and the second token is stored in the remote dictionary service, and the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table is updated.

2. The method according to claim 1, characterized in that, Before obtaining the token escrow data configuration table in the first service system, the method further includes: Send a first request to the lock service system. The first request is used to request a distributed lock. The distributed lock is used to limit the number of service systems that request tokens from the third-party platform within the same time window. The step of obtaining the token escrow data configuration table in the first service system includes: Upon receiving a distributed lock from the lock service system, the token escrow data configuration table is read from the storage space of the first service system.

3. The method according to claim 2, characterized in that, Sending the first request to the lock service system includes: If the scheduled task includes a task corresponding to the third-party platform and the preset execution time of the scheduled task matches the current system time of the first service system, a first request is sent to the lock service system. or, Upon receiving a token request from the client, a first request is sent to the lock service system, which is used to trigger the acquisition of the latest token from the third-party platform.

4. The method according to claim 1, characterized in that, The token verification information includes the platform identifier and the token association information; determining the verification result of the first token corresponding to the first platform identifier of the third-party platform in the N configuration data based on the token verification information in the remote dictionary service includes: Traverse the N configuration data entries, match the first platform identifier in the N configuration data entries with the association information of the platform identifier and the token, and obtain the matching result; If the matching result indicates that no token corresponding to the first platform identifier is matched, a verification result is generated to indicate that the first token is invalid.

5. The method according to claim 1, characterized in that, The token verification information includes verification conditions; determining the verification result of the first token corresponding to the first platform identifier of the third-party platform in the N configuration data based on the token verification information in the remote dictionary service includes: Obtain the first token corresponding to the first platform identifier from the token verification information. The first token is the latest token of the third-party platform stored in the remote dictionary service. The first token corresponds to a first time for updating the first token and a first validity period. If the verification condition is met at the first time and the first valid time, a verification result indicating that the first token has expired is generated; The verification conditions include that the difference between the target time and the current system time of the first service system is less than the update token time interval, and the target time is the sum of the first time and the first valid time.

6. The method according to claim 1, characterized in that, The step of sending a second request to the third-party platform when the verification result indicates that the first token is invalid includes: If the verification result indicates that the first token is invalid, the first configuration data corresponding to the first platform identifier is obtained from the N configuration data; Based on the target data in the first configuration data, a second request is generated, wherein the target data includes the interface's Uniform Resource Locator, interface protocol, and interface invocation method; Call the external interface of the third-party platform to send a second request to the third-party platform.

7. The method according to claim 6, characterized in that, After sending the second request to the third-party platform, the method further includes: Receive the response information sent by the third-party platform corresponding to the second request; The second token is extracted from the response information using the output parameter regular expression of the first configuration data.

8. The method according to claim 1, characterized in that, The first association information of storing the first platform identifier and the second token in the remote dictionary service includes: Using the first platform identifier as the index of the remote dictionary service and the second token as the value, the mapping information is obtained; The update token time interval in the remote dictionary service is adjusted according to the second validity period of the second token; Based on the mapping information and the update token time interval, the first association information of the first platform identifier and the second token is stored in the remote dictionary service.

9. The method according to claim 1, characterized in that, The updating of the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table includes: Add a second configuration data entry to the token escrow data configuration table. The second configuration data includes a second time for updating the second token. The second time is used to identify the latest time when the third-party platform obtained the token, which is stored in the token escrow data configuration table.

10. The method according to claim 1, characterized in that, The configuration data includes the first platform identifier, the interface's Uniform Resource Locator, the interface protocol, the interface calling method, the input parameter exchange format, the output parameter regular expression, the token validity period, the latest time the token was acquired, and the token update time interval.

11. The method according to claim 1, characterized in that, The method further includes: Receive a token escrow request sent by a newly added third-party platform, wherein the token escrow request carries the second platform identifier of the newly added third-party platform; In response to the token escrow request, the third configuration data of the newly added third-party platform is added to the token escrow data configuration table; Based on the third configuration data, obtain the third token corresponding to the second platform identifier; The remote dictionary service stores the second platform identifier and the second association information of the third token.

12. A data processing apparatus, characterized in that, include: The acquisition module is used to acquire the token escrow data configuration table in the first service system. The token escrow data configuration table includes N configuration data entries from the third-party platform, where N is a positive integer. The determination module is used to determine the verification result of the first token corresponding to the first platform identifier of the third-party platform in the N configuration data based on the token verification information in the remote dictionary service. The remote dictionary service is used to store the tokens of the third-party platform obtained by at least two service systems, including the first service system. The sending module is configured to send a second request to the third-party platform when the verification result indicates that the first token is invalid, the second request being used to request the first platform to identify the associated second token; The processing module is configured to, upon receiving a second token from the third-party platform, store the first association information of the first platform identifier and the second token in the remote dictionary service, and update the latest token acquisition time corresponding to the first platform identifier in the token escrow data configuration table.

13. A computer device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the data processing method as described in any one of claims 1-11.

Images