IP address management method, system, device, equipment and readable storage medium

Abstract

This application discloses an IP address management method, system, apparatus, device, and readable storage medium, belonging to the field of data processing technology. The method includes: upon detecting that the cache time has expired, sending a synchronization request to a central IP geodatabase, the synchronization request including: the number of resolutions, the cache time, and the version number; receiving response data from the central IP geodatabase, the response data including: a patch data packet, the rank value of the number of resolutions, and the 99th percentile value P of the cache time. 99 Update IP address information based on the patch data packet; update IP address information based on rank value and P 99 The cache time is updated; the number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase, and the IP resolution service increments the resolution count by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through K8s CRD definition.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically relating to an IP address management method, system, device, equipment, and readable storage medium. Background Technology

[0002] Existing technical solutions primarily query geographic location information via the Internet Protocol (IP) through both online and offline methods. Online methods, where the raw data resides with the service provider, cannot match the access speed and security of offline methods, although they offer high data timeliness. Offline methods, by backing up data locally, offer better access speed and security than online methods, but the data cannot be updated in a timely manner. Since IP geographic information changes frequently, failure to update it promptly compromises the accuracy of the resolution results. Summary of the Invention

[0003] This application provides an IP address management method, system, device, equipment, and readable storage medium, which can solve the problem that existing IP address management methods cannot balance data acquisition efficiency and timely data updates.

[0004] Firstly, an IP address management method is provided, the method being executed by a local IP geodatabase, the method comprising:

[0005] Upon detecting that the cache time has expired, a synchronization request is sent to the central IP geodatabase. The synchronization request includes: the number of parsing attempts, the cache time, and the version number.

[0006] Response data is received from a central IP geodatabase. This response data includes: a patch data packet, the rank value of the number of parsing attempts, and the 99th percentile value of the cache time. 99 ,

[0007] Update the IP address information according to the patch data package;

[0008] Based on the rank value and the P 99 Update the cache time;

[0009] The number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition.

[0010] Optionally, the method further includes:

[0011] When the IP resolution service receives a resolution request, it sends IP address information to the IP resolution service.

[0012] The notification indicates that the IP resolution service will set the resolution count to 0.

[0013] Optionally, the step of basing the value on the rank and the P value on the rank is... 99 Updating the cache time includes:

[0014] Based on the rank value, Step value, and P in the response data 99 Calculate the updated cache time based on the current cache time;

[0015] The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

[0016] Optionally, the step is based on the rank value, Step value, and P value in the response data. 99 Calculate the updated cache time based on the current cache time, including:

[0017] Calculate the updated cache time using the following formula;

[0018] Tnew=(T+(R1-R2)×Step)×(1+(TP 99 ) / (T×P 99 ))

[0019] Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2, and Step are maintained by the K8s CRD.

[0020] Optionally, the method further includes:

[0021] Assign the value of R1 to R2.

[0022] Secondly, an IP address management method is provided, the method being executed by a central IP geodatabase, the method comprising:

[0023] Receive a synchronization request from a target local IP geodatabase from multiple local IP geodatabases, the synchronization request including: number of resolutions, cache time and version number;

[0024] Calculate the rank value of the number of resolutions in all local IP geodatabases;

[0025] Calculate the cache time in the P of all local IP geodatabases.99 ;

[0026] Generate a patch data package based on the version number;

[0027] The response data is sent to the target local IP geodatabase, and the response data includes: the patch data packet, the rank value, and the P 99 ;

[0028] The number of resolutions is determined by the IP resolution service corresponding to the target local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition.

[0029] Optionally, calculating the rank value of the number of resolutions in all local IP geodatabases includes:

[0030] Calculate the rank R1 of the number of times the target local IP geodatabase is resolved among the number of times all local IP geodatabases are resolved;

[0031] R1 is determined as the rank value of the number of resolutions in all local IP geodatabases.

[0032] Optionally, the calculation of the cache time in all local IP geodatabases P 99 ,include:

[0033] The cache time in all local IP geodatabases is calculated using the following formula. 99 :

[0034] P 99 =sectionStart+(sectionEnd-sectionStart)*(rank / sectionCount);

[0035] Wherein, section is the interval in which the 99th percentile value of the cache time falls, sectionStart is the starting value of the interval, sectionEnd is the ending value of the interval, sectionCount is the total number of times the interval is parsed, and rank is the position of the 99th percentile value in the interval.

[0036] Optionally, generating the patch data package based on the version number includes:

[0037] Compare the IP geolocation database corresponding to the version number with the IP geolocation database corresponding to the previous version number;

[0038] The patch data package is generated by traversing the differences.

[0039] Thirdly, an IP address management method is provided, the method being executed by an IP resolution service, the method comprising:

[0040] Upon receiving a parsing request, increment the parsing count by 1;

[0041] Receive IP address information from the local IP geodatabase corresponding to the IP resolution service;

[0042] The IP resolution service and the local IP geodatabase are implemented through K8s CRD definitions.

[0043] Optionally, the method further includes:

[0044] Based on the notification from the local IP geodatabase, the number of resolutions is set to 0.

[0045] Fourthly, an IP address management system is provided, including:

[0046] A central IP geodatabase, which centrally stores the latest mapping information between IP addresses and geographic information;

[0047] Multiple resolution zones, each of which deploys a local IP geodatabase and an IP resolution service;

[0048] The local IP geodatabase is used to perform the IP address management method as described in the first aspect, the central IP geodatabase is used to perform the IP address management method as described in the second aspect, and the IP resolution service is used to perform the IP address management method as described in the third aspect.

[0049] Fifthly, an IP address management device is provided, the device being applied to a local IP geodatabase, the device comprising:

[0050] The first sending module is used to send a synchronization request to the central IP geodatabase when the cache time is detected to be exhausted. The synchronization request includes: the number of parsing attempts, the cache time, and the version number.

[0051] The first receiving module is used to receive response data from the central IP geodatabase. The response data includes: a patch data packet, the rank value of the number of parsing attempts, and the P value of the cache time. 99 ,

[0052] The first update module is used to update the IP address information according to the patch data package;

[0053] The second update module is used to update the rank value and the P value. 99 Update the cache time;

[0054] The number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition.

[0055] Optionally, the device further includes:

[0056] The third sending module is used to send IP address information to the IP resolution service when the IP resolution service receives a resolution request;

[0057] The notification module is used to notify the IP resolution service to set the resolution count to 0.

[0058] Optionally, the second update module is specifically used for:

[0059] Based on the rank value, Step value, and P in the response data 99 Calculate the updated cache time based on the current cache time;

[0060] The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

[0061] Optionally, the second update module is specifically used for:

[0062] Calculate the updated cache time using the following formula;

[0063] Tnew=(T+(R1-R2)×Step)×(1+(TP 99 ) / (T×P 99 ))

[0064] Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2, and Step are maintained by the K8s CRD.

[0065] Optionally, the device further includes:

[0066] The second processing module is used to assign the value of R1 to R2.

[0067] Sixthly, an IP address management device is provided, the device being applied to a central IP geographic database, the device comprising:

[0068] The second receiving module is used to receive a synchronization request from a target local IP geodatabase in multiple local IP geodatabases. The synchronization request includes: number of parsing times, cache time, and version number.

[0069] The first calculation module is used to calculate the rank value of the number of resolutions in all local IP geo databases;

[0070] The second calculation module is used to calculate the P value of the cache time in all local IP geodatabases. 99 ;

[0071] The generation module is used to generate a patch data package based on the version number;

[0072] The second sending module is used to send response data to the target local IP geodatabase. The response data includes: the patch data packet, the rank value, and the P... 99 ;

[0073] The number of resolutions is determined by the IP resolution service corresponding to the target local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition.

[0074] Optionally, the first calculation module is specifically used for:

[0075] Calculate the rank R1 of the number of times the target local IP geodatabase is resolved among the number of times all local IP geodatabases are resolved;

[0076] R1 is determined as the rank value of the number of resolutions in all local IP geodatabases.

[0077] Optionally, the second calculation module is specifically used for:

[0078] The cache time in all local IP geodatabases is calculated using the following formula. 99 :

[0079] P 99 =sectionStart+(sectionEnd-sectionStart)*(rank / sectionCount);

[0080] Wherein, section is the interval in which the 99th percentile value of the cache time falls, sectionStart is the starting value of the interval, sectionEnd is the ending value of the interval, sectionCount is the total number of times the interval is parsed, and rank is the position of the 99th percentile value in the interval.

[0081] Optionally, the generation module is specifically used for:

[0082] Compare the IP geolocation database corresponding to the version number with the IP geolocation database corresponding to the previous version number;

[0083] The patch data package is generated by traversing the differences.

[0084] Seventhly, an IP address management device is provided, the device being used for IP resolution services, the device comprising:

[0085] The first processing module is used to increment the parsing count by 1 when a parsing request is received;

[0086] The third receiving module is used to receive IP address information from the local IP geodatabase corresponding to the IP resolution service;

[0087] The IP resolution service and the local IP geodatabase are implemented through K8s CRD definitions.

[0088] Optionally, the device further includes:

[0089] The third processing module is used to set the number of parsing attempts to 0 based on the notification from the local IP geodatabase.

[0090] Eighthly, an electronic device is provided, the terminal including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method as described in the first aspect, or implementing the steps of the method as described in the second aspect, or implementing the steps of the method as described in the third aspect.

[0091] A ninth aspect provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect, or the steps of the method described in the second aspect, or the steps of the method described in the third aspect.

[0092] In a tenth aspect, a chip is provided, the chip including a processor and a communication interface coupled to the processor, the processor being configured to run a program or instructions to implement the steps of the method described in the first aspect, or the steps of the method described in the second aspect, or the steps of the method described in the third aspect.

[0093] Eleventhly, a computer program / program product is provided, the computer program / program product being stored in a storage medium, the program / program product being executed by at least one processor to implement the steps of the method as described in the first aspect, or the steps of the method as described in the second aspect, or the steps of the method as described in the third aspect.

[0094] In this embodiment, the cache time of the local IP geodatabase is calculated based on the ranking changes of the number of resolutions reported by the central IP geodatabase and the 99th percentile of the old cache time in all resolution regions. This adapts to the uneven use of resolution services due to factors such as geographical location and economic development. Cache time calculation is performed in the local IP geodatabase, reducing the computational burden on the central IP geodatabase. When the IP resolution service receives a resolution request, it prioritizes accessing the local IP geodatabase, reducing network latency and improving resolution efficiency. The IP resolution service and the local IP geodatabase are implemented through Kubernetes CRD definitions. Leveraging the cloud-native features of Kubernetes, custom resource objects are used to manage cache time calculation, version retrieval, and data reporting, enabling rapid scaling, reducing operational complexity, and achieving hot updates. Attached Figure Description

[0095] Figure 1 This is a schematic diagram of the architecture of the IP address management system provided in the embodiments of this application;

[0096] Figure 2 This is one of the flowcharts illustrating the IP address management method provided in the embodiments of this application;

[0097] Figure 3 This is a second flowchart illustrating the IP address management method provided in the embodiments of this application;

[0098] Figure 4 This is the third flowchart illustrating the IP address management method provided in this application embodiment;

[0099] Figure 5 This is the fourth flowchart illustrating the IP address management method provided in the embodiments of this application;

[0100] Figure 6 This is one of the structural schematic diagrams of the IP address management device provided in the embodiments of this application;

[0101] Figure 7 This is a second schematic diagram of the structure of the IP address management device provided in the embodiments of this application;

[0102] Figure 8 This is the third schematic diagram of the IP address management device provided in the embodiments of this application;

[0103] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0104] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0105] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, the first object can be one or more. Furthermore, "and / or" in this application indicates at least one of the connected objects. For example, "A or B" covers three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0106] To better understand the technical solution of this application, the following will be introduced first:

[0107] Cloud Native:

[0108] Cloud-native architecture and technologies are methodologies for designing, constructing, and operating workloads built in the cloud and fully leveraging cloud computing models. Common paradigms include container technologies, service meshes, microservices, and declarative application programming interfaces (APIs). Kubernetes (often shortened to K8s) is an open-source container management platform that enables more agile deployments and helps reduce operational costs.

[0109] IP geodatabase:

[0110] The full name is IP geolocation database, which is a database that stores IP addresses and comprehensive geographic information (such as country, region, city, latitude / longitude, postal code, time zone, connection speed, Internet Service Provider (ISP)). It is mainly used to identify the geolocation domain name of visitors, international direct dial (IDD) country code, area code, weather station code and name, mobile operator information, altitude and usage type, agent information, etc.

[0111] The IP address management provided in this application will be described in detail below with reference to the accompanying drawings, through some embodiments and application scenarios.

[0112] See Figure 1 , Figure 1 The IP address management system provided in this application embodiment includes:

[0113] A central IP geodatabase, which centrally stores the latest mapping information between IP addresses and geographic information;

[0114] Multiple resolution zones, each deploying a local IP geodatabase and an IP resolution service; for example Figure 1 The image shows a scenario where three resolution zones are deployed, each containing a local IP geodatabase and IP resolution service. Different permissions...

[0115] In this embodiment, the system consists of a central IP geodatabase and multiple resolution zones. Each resolution zone consists of an IP resolution service and a local IP geodatabase.

[0116] Central IP Geographic Database: A data center for IP geographic locations, centrally storing the latest mapping information between IPs and geographic information.

[0117] IP resolution service: Deployed in each major region, responsible for resolving the IP geolocation initiated by clients in that region.

[0118] Local IP geodatabase: Deployed in each major region, providing IP geodatabase data for IP resolution services within that region. Data is dynamically and incrementally synchronized from the central IP geodatabase.

[0119] The technical solutions of this application are described below from the perspectives of the local IP geodatabase, the central IP geodatabase, and the IP resolution service:

[0120] See Figure 2 This application provides an IP address management method, which is executed by a local IP geospatial database and includes:

[0121] Step 201: Upon detecting that the cache time has expired, send a synchronization request to the central IP geodatabase. The synchronization request includes: the number of resolutions, the cache time, and the version number.

[0122] Step 202: Receive response data from the central IP geodatabase. The response data includes: patch data packets, the rank value of the number of times the data was parsed, and the 99th percentile value of the cache time. 99 ,

[0123] Step 203: Update the IP address information according to the patch data package;

[0124] Step 204: Based on the rank value and P 99 Update cache time;

[0125] The number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase. Whenever the IP resolution service receives a resolution request, it increments the resolution count by 1. The IP resolution service and the local IP geodatabase are defined through a Kubernetes Custom Resource Definition (CRD).

[0126] In this embodiment, the cache time of the local IP geodatabase is calculated based on the ranking changes of the number of resolutions reported by the central IP geodatabase and the 99th percentile of the old cache time across all regions. This adapts to the uneven use of resolution services due to factors such as geographical location and economic development. Cache time calculation is performed in the local IP geodatabase, reducing the computational burden on the central IP geodatabase. When the IP resolution service receives a resolution request, it prioritizes accessing the local IP geodatabase, reducing network latency and improving resolution efficiency. The IP resolution service and the local IP geodatabase are implemented using Kubernetes CRDs. Leveraging the cloud-native features of Kubernetes, custom resource objects are used to manage cache time calculation, version retrieval, and data reporting, enabling rapid scaling, reducing operational complexity, and achieving hot updates.

[0127] The aforementioned cache time can specifically be the Time To Live (TTL) of IP address information. The local IP geodatabase can read the initial parameters of TTL and listen for it. When it detects that TTL has expired, it indicates that the IP address information needs to be updated, and then the above steps 201-204 are executed.

[0128] Steps 201-204 above mainly address the process of synchronizing and updating IP address information between the local IP geodatabase and the central IP geodatabase. This ensures that when an IP resolution service in each resolution region receives a resolution request, it can obtain the latest IP address information from the local IP geodatabase corresponding to the IP resolution service (i.e., the local IP geodatabase deployed in the same resolution region as the IP resolution service).

[0129] In one possible implementation, the method further includes:

[0130] (1) When the IP resolution service receives a resolution request, send the IP address information to the IP resolution service;

[0131] (2) Notify the IP resolution service to set the resolution count to 0.

[0132] In this embodiment of the application, based on the above steps 201-204, when the IP resolution service receives a resolution request, the IP address information provided by the local IP geodatabase to the IP resolution service can be guaranteed to be timely updated. After providing the IP address information, the IP resolution service is notified to set the resolution count to 0 so as to ensure the accuracy of subsequent updates to the IP address information.

[0133] In one possible implementation, based on the rank value and P 99 Update cache times, including:

[0134] Based on the rank value, Step value, and P value in the response data 99 Calculate the updated cache time based on the current cache time;

[0135] The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in resolution frequency.

[0136] In this embodiment, the rank value in the response data corresponds to the ranking of the old cache time among the cache times of the local IP geodatabase in all resolution regions. This ranking is specifically determined by the central IP geodatabase. Similarly, P... 99 It is the 99th percentile of the old cache time among the cache times of the local IP geodatabase in all resolution regions, specifically calculated by the central IP geodatabase.

[0137] Using the rank value and P returned by the central IP geodatabase 99 The updated cache time is calculated by taking the Step value that the local IP geodatabase can read and the current cache time (i.e. the old cache time mentioned above).

[0138] In one possible implementation, based on the rank value, Step value, and P value in the response data... 99 Calculate the updated cache time based on the current cache time, including:

[0139] Calculate the updated cache time using the following formula;

[0140] Tnew=(T+(R1-R2)×Step)×(1+(TP 99 ) / (T×P 99 ));

[0141] Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2, and Step are maintained by the K8s CRD.

[0142] In one possible implementation, the method further includes:

[0143] Assign the value of R1 to R2.

[0144] Understandably, after each update, the new rank value is stored in the local IP geodatabase for the next IP address information update. That is, R2 is the rank value in the response data of the central IP geodatabase during the previous IP address information update. In the current IP address information update, the new rank value R1 is obtained from the response data of the central IP geodatabase. After the update is completed, R1 is assigned to R2, so that the new rank value is stored in the local IP geodatabase for the next IP address information update.

[0145] See Figure 3 This application provides an IP address management method, which is executed by a central IP geographic database and includes:

[0146] Step 301: Receive a synchronization request from the target local IP geodatabase in multiple local IP geodatabases. The synchronization request includes: number of resolutions, cache time, and version number.

[0147] Step 302: Calculate the rank value of the number of resolutions in the local IP geodatabase;

[0148] Step 303: Calculate the cache time in the P of all local IP geodatabases. 99 ;

[0149] Step 304: Generate a patch data package based on the version number;

[0150] Step 305: Send response data to the target local IP geodatabase. The response data includes: patch data packet, rank value, and P. 99 ;

[0151] The number of resolutions is determined by the IP resolution service corresponding to the target local IP geodatabase. Whenever the IP resolution service receives a resolution request, it increments the resolution count by 1. The IP resolution service and the local IP geodatabase are defined and implemented through K8sCRD.

[0152] In this embodiment, the cache time of the local IP geodatabase is calculated based on the ranking changes of the number of resolutions reported by the central IP geodatabase and the 99th percentile of the old cache time across all regions. This adapts to the uneven use of resolution services due to factors such as geographical location and economic development. Cache time calculation is performed in the local IP geodatabase, reducing the computational burden on the central IP geodatabase. When the IP resolution service receives a resolution request, it prioritizes accessing the local IP geodatabase, reducing network latency and improving resolution efficiency. The IP resolution service and the local IP geodatabase are implemented using Kubernetes CRDs. Leveraging the cloud-native features of Kubernetes, custom resource objects are used to manage cache time calculation, version retrieval, and data reporting, enabling rapid scaling, reducing operational complexity, and achieving hot updates.

[0153] The aforementioned central IP geodatabase is used to centrally store the latest mapping information between IPs and geographic information, and can achieve ultra-high-precision IP positioning through network measurement and data mining models.

[0154] It should be noted that, as Figure 1 The system shown has a central IP geodatabase corresponding to multiple resolution regions. Therefore, the central IP geodatabase can be one or more local IP geodatabases deployed in each resolution region. The process described in steps 301-305 above is the process by which the central IP geodatabase updates the IP address information of one of the one or more local IP geodatabases. That is, the target local IP geodatabase specifically refers to one of the one or more local IP geodatabases. Each local IP geodatabase that needs to update its IP address information can be processed according to the above process.

[0155] In one possible implementation, the rank value of the number of resolutions in all local IP geodatabases is calculated, including:

[0156] (1) Calculate the ranking R1 of the number of times the target local IP geodatabase is resolved among all the number of times the local IP geodatabase is resolved;

[0157] (2) R1 is determined as the rank value of the number of resolutions in all local IP geodatabases.

[0158] In one possible implementation, calculate the cache time P in all local IP geodatabases. 99 ,include:

[0159] Calculate the cache time P in all local IP geodatabases using the following formula. 99 :

[0160] P 99=sectionStart+(sectionEnd-sectionStart)*(rank / sectionCount);

[0161] Where section is the interval where the 99th percentile value of the cached time falls, sectionStart is the starting value of the interval, sectionEnd is the ending value of the interval, sectionCount is the total number of times the interval is parsed, and rank is the position of the 99th percentile value in the interval.

[0162] In one possible implementation, a patch data package is generated based on the version number, including:

[0163] (1) Compare the IP geolocation database corresponding to the version number with the IP geolocation database corresponding to the previous version number;

[0164] (2) Generate patch data packages by traversing the differences.

[0165] In this embodiment, the central IP geolocation database is constantly changing. A scheduled task periodically adds a version number v, compares the IP geolocation database corresponding to the current version number with the IP geolocation database corresponding to the previous version number, iterates through the diff to find the differences, and records them as patches. v1,v2 This indicates the differences between version 2 and version 1, which are then stored.

[0166] This involves comparing IP geolocation database differences based on version numbers, and then generating a patch data package, which is used to update IP address information in the local IP geolocation database.

[0167] The central IP geodatabase sets the rank value R1 of the number of resolutions in all local IP geodatabases and the P value of the cache time in all local IP geodatabases. 99 These two parameters are returned to the local IP geodatabase along with the IP data (i.e., the patch data packet).

[0168] See Figure 4 This application provides an IP address management method, which is executed by an IP resolution service and includes:

[0169] Step 401: Upon receiving a parsing request, increment the parsing count by 1;

[0170] Step 402: Receive IP address information from the local IP geodatabase corresponding to the IP resolution service;

[0171] The IP resolution service and the local IP geodatabase are implemented through K8s CRD definitions.

[0172] In this embodiment of the application, whenever the IP resolution service receives a resolution request, the resolution count is incremented by 1. This resolution count can be used to update IP address information in the local IP geodatabase. The IP resolution service receives IP address information from the local IP geodatabase based on the resolution request.

[0173] In one possible implementation, the method further includes:

[0174] Based on the notification from the local IP geodatabase, the number of resolutions is set to 0.

[0175] In this embodiment of the application, after the local IP geodatabase provides IP address information, the local IP geodatabase notifies the IP resolution service to set the resolution count to 0, so as to ensure the accuracy of subsequent updates to the IP address information.

[0176] The technical solution of this application will be further described below in conjunction with the overall collaborative process of the local IP geodatabase, the central IP geodatabase, and the IP resolution service:

[0177] See Figure 5 The diagram illustrates the overall process of the IP address management scheme provided in this application. The entire system consists of three parts: IP resolution service, local IP geodatabase, and central IP geodatabase.

[0178] The IP resolution service is responsible for handling IP resolution requests from clients. Each time a request is received, the resolution count is incremented by 1.

[0179] The local IP geodatabase is responsible for the synchronous update of the IP geodatabase for this region. The specific process is as follows:

[0180] The first step is to read the initial parameters such as cache time (TTL) and step size.

[0181] The second step is to monitor whether the TTL has been exhausted.

[0182] The third step is to send a synchronization request to the central geographic database if the TTL is exhausted. The request includes the number of parsing attempts (count), the cache time (TTL), and the version number (version).

[0183] The fourth step involves receiving response data from the central geographic database, reading the rank of the number of parsing attempts, and the 99th percentile value of the TTL. The TTL is then refreshed.

[0184] Step 5: Update the local IP geodatabase file according to the data packet patch.

[0185] Step 6: Update the previous ranking LastRank to the rank received this time.

[0186] Step 7: Instruct the IP resolution service to set the count to 0.

[0187] The central IP geodatabase is responsible for collecting IP data and processing synchronization requests from the local IP geodatabase. The specific process is as follows:

[0188] The first step is to receive synchronization requests.

[0189] The second step is to store the number of parsing attempts (count) and the cache time (TTL) in the request body.

[0190] The third step is to calculate the rank of the current count value in all local IP geodatabases.

[0191] The fourth step is to calculate the 99th percentile value P of the current TTL in all local IP geodatabases. 99 .

[0192] The fifth step is to compare the version number in the request with the latest version number, and then compare the patch, rank, and P data packets. 99 Returned to the local IP geodatabase.

[0193] The specific implementation method is as follows:

[0194] (I) Defining the Central IP Geographic Database

[0195] This database is used to centrally store the latest IP-geographic mapping information. It achieves ultra-high-precision IP location through network measurement and data mining models. The central IP geographic database is constantly changing; a scheduled task periodically adds a version number (v), compares the IP geographic location database corresponding to the current version number with the database corresponding to the previous version number, iterates through the diff, and records the differences as patches. v1,v2 This indicates the differences between version 2 and version 1, which are then stored.

[0196] The central IP geodatabase cluster calculates the following data:

[0197] (1)P 99 This value represents the 99th percentile of the T-values ​​across all local IP geodatabases. If the total number of local IP geodatabases is large, a bucket-based approach can be used for more accurate estimation. This is achieved by using a formula based on the cumulative histogram method for all local IP geodatabases, considering the number of points within a preset interval.

[0198] P 99 =sectionStart+(sectionEnd-sectionStart)*(rank / sectionCount);

[0199] The interval in which the 99th percentile value falls is called "section", "sectionStart" is the starting value of the interval, "sectionEnd" is the ending value of the interval, "sectionCount" is the total number of times the interval is parsed, and "rank" is the position of the 99th percentile value in the interval.

[0200] (2) R1, which means the ranking of the count parameter of the local IP geodatabase that is currently processing the synchronization request in all local IP geodatabases.

[0201] (3) The above two parameters will be returned to the local IP geodatabase along with the IP data when the local IP geodatabase synchronizes the data.

[0202] (II) Defining IP Resolution Service

[0203] Deployed across various regions, it can be defined by Kubernetes deployment resources and run as a pod within a Kubernetes cluster, responsible for handling client IP resolution requests. The processing flow is as follows:

[0204] Define the parameter `count`, which represents the number of IP resolution requests accepted from clients within the range of value `T`. This parameter must be visible to the following custom resource CRD Controller.

[0205] Upon receiving a client request, access the local IP geodatabase to provide a response and increment the count parameter by 1.

[0206] (III) Defining the local IP geodatabase

[0207] Deployed across various regions, it can be implemented using the K8s extension function CRD+Operator, responsible for TTL calculation of the local IP geodatabase, data reporting, version updates, etc.

[0208] CRD Schema: A custom resource structure, defining the following parameters:

[0209] (1) GeoLibDB is the path to the local IP geodatabase file, which is visible to the IP resolution service mentioned above.

[0210] (2)v, which means the version number of the local IP geolocation database.

[0211] (3)T, which means the cache time of the local IP geolocation database.

[0212] (4) Step, which means the step size of the T value that needs to be adjusted for each unit increase or decrease in the ranking of the count parameter of the local IP resolution service.

[0213] (5) R2, which means the ranking of the count parameter returned by the central IP geodatabase among all local IP geodatabases when the current local IP geodatabase last sent a synchronization request to the central IP geodatabase.

[0214] CRD Controller: A custom resource event handler function that defines the following logic:

[0215] (1) Monitor changes in the T value. When the T value is exhausted, immediately send a synchronization request to the central IP geodatabase. The necessary parameters are as follows:

[0216] a) version: The current version number of the local IP geolocation database.

[0217] b) The current cache time of the local IP geolocation database.

[0218] c) count the number of IP resolution requests received from clients within the T value range of the IP resolution service.

[0219] (2) After receiving the response data, apply the patch and update LocalGeoLib.

[0220] (3) The cache refresh time T is calculated using the following formula:

[0221] Tnew=(T+(R1-R2)×Step)×(1+(TP 99 ) / (T×P 99 ));

[0222] Among them, T, R2, and Step are maintained by CRD Schema, and R1, P... 99 Obtained from the response data. If R2 does not exist, the T value is not refreshed.

[0223] (4) Assign R1 to R2 and store the previous count value ranking.

[0224] (5) Notify the IP resolution service to reset the count to 0.

[0225] The following describes an application example:

[0226] Step 1: Build a central IP geodatabase and define a Map data structure to store the parameters carried in synchronization requests from local IP geodatabases of various regions. The process for handling synchronization requests is as follows:

[0227] (1) Read the number of parsing attempts (count) and cache time (TTL) from the request, and store the two variables with the UUID of the IP geodatabase of each region as the key.

[0228] (2) Calculate the rank of the current IP geodatabase count value among all local IP geodatabases, and the 99th percentile value of the cache time among all local IP geodatabases, P. 99 .

[0229] (3) Apply a patch based on the version number in the request, and add Rank and P 99 It is returned to the local IP geodatabase along with the patch package.

[0230] Step 2: Deploy the IP resolution service in each major region using Kubernetes deployments. Define a variable `count` to represent the number of resolution requests processed within the cache period. Increment `count` by 1 each time the IP resolution service completes an IP resolution request.

[0231] Step 3: Build a local IP geodatabase data update mirror (geo_update) to send synchronization requests to the central geodatabase. The synchronization request must include the local IP geodatabase's unique identifier (UUID), the number of times it has been parsed (count), and the current TTL value. Update the IP geodatabase data based on the returned patch, and refresh the T value according to the T value calculation formula. Here, Step, T, and R2 are derived from environment variables, and R1, P... 99 This is derived from the central geographic database. Then, the `apiserver` function updates the `spec` attribute `TTL` of the following CRD to the refreshed `T` value. Next, the environment variable `LastRank` is assigned the value `Rank`. Finally, the `count` value is set to 0.

[0232] Step 4: Use the Operator-SDK scaffolding to define the logic for automatically updating the local IP geodatabase based on Go. The specific steps are as follows:

[0233] (1) Define a structure LocalGeoLibSpec to specify initial parameters, which includes the following properties:

[0234] GeoLibDB means the path where the IP geodatabase data file is located.

[0235] Step refers to the step size of the T value that needs to be adjusted for each unit increase or decrease in the ranking of the count parameter of the local IP resolution service.

[0236] TTL stands for the cache time of the local IP geodatabase.

[0237] (2) Write the Controller logic, specifically:

[0238] 1) Check if the CRD resource instance exists. If it does not exist, create it.

[0239] 2) Listen for update events of the CRD resource LocalGeoLibSpec. If detected, perform the following steps:

[0240] a. Determine if the ConfigMap resource instance exists. If it does not exist, create a ConfigMap resource instance and define the GeoLibDB, Step, and LastRank attributes.

[0241] b. Check if the CronJob resource instance exists. If not, create a CronJob resource instance. The image of this resource instance is the aforementioned image geo_update, and GeoLibDB and Step are mounted as environment variables of the container application via ConfigMap; the schedule is a cron expression for the current TTL.

[0242] c. If GeoLibDB and Step change, update the ConfigMap resource instance and restart the CronJob resource instance.

[0243] d. If the TTL changes, update the schedule field of the CronJob resource instance.

[0244] Step 5: Deploy the custom resource CRD in each region.

[0245] Compared with existing offline data package downloading schemes, this application has the following main advantages:

[0246] By leveraging Kubernetes' cloud-native features and using custom resource objects to manage TTL calculations, version pulls, and data reporting, rapid scaling can be achieved, reducing operational complexity and enabling hot updates.

[0247] Within a given region, DNS resolution services prioritize accessing the local IP geodatabase, reducing network latency and improving resolution efficiency. The local IP geodatabase cache time is calculated based on changes in the ranking of resolution frequency and the 99th percentile of the old cache time across all regions. This accommodates the uneven usage of DNS resolution services across different regions due to factors such as geographical location and economic development. Cache time calculation within the local IP geodatabase reduces the computational burden on the central IP geodatabase.

[0248] The IP address management system provided in this application consists of a central IP geodatabase and multiple local IP geodatabases, forming a multi-site backup architecture to achieve disaster recovery in different locations and improve system availability.

[0249] The IP address management method provided in this application can be executed by an IP address management device. This application uses an IP address management device executing the IP address management method as an example to illustrate the IP address management device provided in this application.

[0250] See Figure 6 This application provides an IP address management device, which is applied to a local IP geographic database. The device includes:

[0251] The first sending module 601 is used to send a synchronization request to the central IP geodatabase when the cache time is detected to be exhausted. The synchronization request includes: the number of parsing times, the cache time and the version number.

[0252] The first receiving module 602 is configured to receive response data from the central IP geodatabase. The response data includes: a patch data packet, the rank value of the number of parsing attempts, and the P value of the cache time. 99 ,

[0253] The first update module 603 is used to update the IP address information according to the patch data packet;

[0254] The second update module 604 is used to update the rank value and the P value according to the rank value. 99 Update the cache time;

[0255] The number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition.

[0256] Optionally, the device further includes:

[0257] The third sending module is used to send IP address information to the IP resolution service when the IP resolution service receives a resolution request;

[0258] The notification module is used to notify the IP resolution service to set the resolution count to 0.

[0259] Optionally, the second update module is specifically used for:

[0260] Based on the rank value, Step value, and P in the response data 99 Calculate the updated cache time based on the current cache time;

[0261] The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

[0262] Optionally, the second update module is specifically used for:

[0263] Calculate the updated cache time using the following formula;

[0264] Tnew=(T+(R1-R2)×Step)×(1+(TP 99 ) / (T×P 99 ))

[0265] Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2, and Step are maintained by the K8s CRD.

[0266] Optionally, the device further includes:

[0267] The second processing module is used to assign the value of R1 to R2.

[0268] See Figure 7 This application provides an IP address management device, which is applied to a central IP geographic database. The device includes:

[0269] The second receiving module 701 is used to receive a synchronization request from a target local IP geodatabase in multiple local IP geodatabases. The synchronization request includes: number of parsing times, cache time, and version number.

[0270] The first calculation module 702 is used to calculate the rank value of the number of resolutions in all local IP geo databases;

[0271] The second calculation module 703 is used to calculate the P value of the cache time in all local IP geodatabases. 99 ;

[0272] The generation module 704 is used to generate a patch data package based on the version number;

[0273] The second sending module 705 is used to send response data to the target local IP geodatabase, the response data including: the patch data packet, the rank value, and the P... 99 ;

[0274] The number of resolutions is determined by the IP resolution service corresponding to the target local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition.

[0275] Optionally, the first calculation module is specifically used for:

[0276] Calculate the rank R1 of the number of times the target local IP geodatabase is resolved among the number of times all local IP geodatabases are resolved;

[0277] R1 is determined as the rank value of the number of resolutions in all local IP geodatabases.

[0278] Optionally, the second calculation module is specifically used for:

[0279] The cache time in all local IP geodatabases is calculated using the following formula. 99 :

[0280] P 99 =sectionStart+(sectionEnd-sectionStart)*(rank / sectionCount);

[0281] Wherein, section is the interval in which the 99th percentile value of the cache time falls, sectionStart is the starting value of the interval, sectionEnd is the ending value of the interval, sectionCount is the total number of times the interval is parsed, and rank is the position of the 99th percentile value in the interval.

[0282] Optionally, the generation module is specifically used for:

[0283] Compare the IP geolocation database corresponding to the version number with the IP geolocation database corresponding to the previous version number;

[0284] The patch data package is generated by traversing the differences.

[0285] See Figure 8 This application provides an IP address management device, which is applied to IP resolution services. The device includes:

[0286] The first processing module 801 is used to increment the parsing count by 1 when a parsing request is received;

[0287] The third receiving module 802 is used to receive IP address information from the local IP geo database corresponding to the IP resolution service;

[0288] The IP resolution service and the local IP geodatabase are implemented through K8s CRD definitions.

[0289] Optionally, the device further includes:

[0290] The third processing module is used to set the number of parsing attempts to 0 based on the notification from the local IP geodatabase.

[0291] The IP address management device in this application embodiment can be an electronic device, such as an electronic device with an operating system, or a component in an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. The IP address management device provided in this application embodiment can achieve... Figures 2 to 5 The various processes implemented in the method embodiments achieve the same technical effect, and will not be described again here to avoid repetition.

[0292] See Figure 9 This invention provides an electronic device 900, including at least one processor 901, a memory 902, a user interface 903, and at least one network interface 904. The various components of the electronic device 900 are coupled together via a bus system 905.

[0293] Understandably, bus system 905 is used to implement communication between these components. In addition to a data bus, bus system 905 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general labeled all buses as Bus System 905.

[0294] The user interface 903 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0295] It is understood that the memory 902 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 902 described in this embodiment is intended to include, but is not limited to, these and any other suitable types of memory.

[0296] In some implementations, memory 902 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof: operating system 9021 and application program 9022.

[0297] The operating system 9021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 9022 includes various applications, such as media players and browsers, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 9022.

[0298] In this embodiment of the invention, the electronic device 900 may further include: a program stored in a memory 902 and executable on a processor 901, which, when executed by the processor 901, implements the steps of the method provided in this embodiment of the invention.

[0299] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 901. Processor 901 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in processor 901. The processor 901 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature computer-readable storage media in the art. The computer-readable storage medium is located in memory 902. Processor 901 reads information from memory 902 and, in conjunction with its hardware, completes the steps of the above method. Specifically, a computer program is stored on the computer-readable storage medium.

[0300] It is understood that the embodiments described in this invention can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more ASICs, DSPs, digital signal processing devices (DSP Devices, DSPDs), programmable logic devices (PLDs), FPGAs, general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in this application, or combinations thereof.

[0301] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0302] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. In some examples, the readable storage medium may be a non-transient readable storage medium.

[0303] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0304] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0305] This application also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0306] It should be noted that, in this document, 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 one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0307] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of computer software products plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes several instructions to cause the terminal or network-side device to execute the methods described in the various embodiments of this application.

[0308] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other implementations under the guidance of this application without departing from the spirit and scope of the claims. All of these implementations are within the protection scope of this application.

Claims

1. An IP address management method, characterized in that, The method is executed by a local IP geodatabase and includes: Upon detecting that the cache time has expired, a synchronization request is sent to the central IP geodatabase. The synchronization request includes: the number of parsing attempts, the cache time, and the version number. Response data is received from the central IP geodatabase. This response data includes: a patch data packet, the rank value of the number of times the data was parsed, and the 99th percentile value of the cache time. 99 , Update the IP address information according to the patch data package; Based on the rank value and the P 99 Update the cache time; The number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition. The rank value and P are used as the basis 99 Updating the cache time includes: Calculate the updated cache time using the following formula; Tnew=(T+(R1-R2)×Step)×(1+(T-P 99 ) / (T×P 99 )) Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2 and Step are maintained by K8s CRD. The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

2. The method according to claim 1, characterized in that, The method further includes: When the IP resolution service receives a resolution request, it sends IP address information to the IP resolution service. The notification indicates that the IP resolution service will set the resolution count to 0.

3. The method according to claim 1, characterized in that, The method further includes: Assign the value of R1 to R2.

4. An IP address management method, characterized in that, The method is executed by a central IP geodatabase and includes: Receive a synchronization request from a target local IP geodatabase from multiple local IP geodatabases, the synchronization request including: number of resolutions, cache time and version number; Calculate the rank value of the number of resolutions in all local IP geodatabases; Calculate the 99th percentile value P of the cache time in all local IP geodatabases. 99 ; Generate a patch data package based on the version number; The response data is sent to the target local IP geodatabase, and the response data includes: the patch data packet, the rank value, and the P. 99 ; The number of resolutions is determined by the IP resolution service corresponding to the target local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition. The target local IP geodatabase is used to calculate the updated cache time according to the following formula; Tnew=(T+(R1-R2)×Step)×(1+(T-P 99 ) / (T×P 99 )) Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2 and Step are maintained by K8s CRD. The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

5. The method according to claim 4, characterized in that, The calculation of the rank value of the number of resolutions in all local IP geodatabases includes: Calculate the rank R1 of the number of times the target local IP geodatabase is resolved among the number of times all local IP geodatabases are resolved; R1 is determined as the rank value of the number of resolutions in all local IP geodatabases.

6. The method according to claim 4, characterized in that, The calculation of the cache time in all local IP geodatabases P 99 ,include: The cache time in all local IP geodatabases is calculated using the following formula. 99 : P 99 = sectionStart + (sectionEnd-sectionStart)*(rank / sectionCount); Wherein, section is the interval in which the 99th percentile value of the cache time falls, sectionStart is the starting value of the interval, sectionEnd is the ending value of the interval, sectionCount is the total number of times the interval is parsed, and rank is the position of the 99th percentile value in the interval.

7. The method according to claim 4, characterized in that, The step of generating a patch data package based on the version number includes: Compare the IP geolocation database corresponding to the version number with the IP geolocation database corresponding to the previous version number; The patch data package is generated by traversing the differences.

8. An IP address management system, characterized in that, include: A central IP geodatabase, which centrally stores the latest mapping information between IP addresses and geographic information; Multiple resolution zones, each of which deploys a local IP geodatabase and an IP resolution service; The local IP geodatabase is used to perform the IP address management method as described in any one of claims 1 to 3, and the central IP geodatabase is used to perform the IP address management method as described in any one of claims 4 to 7.

9. An IP address management device, characterized in that, The device is used in a local IP geodatabase, and the device includes: The first sending module is used to send a synchronization request to the central IP geodatabase when the cache time is detected to be exhausted. The synchronization request includes: the number of parsing attempts, the cache time, and the version number. The first receiving module is used to receive response data from the central IP geodatabase. The response data includes: a patch data packet, the rank value of the number of parsing attempts, and the 99th percentile value of the cache time. 99 , The first update module is used to update the IP address information according to the patch data package; The second update module is used to update the rank value and the P value. 99 Update the cache time; The number of resolutions is determined by the IP resolution service corresponding to the local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition. The second update module is further configured to: calculate the updated cache time according to the following formula; Tnew=(T+(R1-R2)×Step)×(1+(T-P 99 ) / (T×P 99 )) Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2 and Step are maintained by K8s CRD. The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

10. An IP address management device, characterized in that, The device is used in a central IP geographic database, and the device includes: The second receiving module is used to receive a synchronization request from a target local IP geodatabase in multiple local IP geodatabases. The synchronization request includes: number of parsing times, cache time, and version number. The first calculation module is used to calculate the rank value of the number of resolutions in all local IP geo databases; The second calculation module is used to calculate the P value of the cache time in all local IP geodatabases. 99 ; The generation module is used to generate a patch data package based on the version number; The second sending module is used to send response data to the target local IP geodatabase. The response data includes: the patch data packet, the rank value, and the P... 99 ; The number of resolutions is determined by the IP resolution service corresponding to the target local IP geodatabase, and the IP resolution service increments the number of resolutions by 1 whenever it receives a resolution request. The IP resolution service and the local IP geodatabase are implemented through a K8s CRD definition. The target local IP geodatabase is used to calculate the updated cache time according to the following formula; Tnew=(T+(R1-R2)×Step)×(1+(T-P 99 ) / (T×P 99 )) Where Tnew is the updated cache time, T is the current cache time, R1 is the rank value in the response data, and R2 is the rank value in the response data of the central IP geodatabase when the local IP geodatabase last sent a synchronization request to the central IP geodatabase. T, R2 and Step are maintained by K8s CRD. The Step value represents the step size required to adjust the ranking of the IP resolution service for each unit increase or decrease in the number of resolutions.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the IP address management method as described in any one of claims 1 to 3, or the steps of the IP address management method as described in any one of claims 4 to 7.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the IP address management method as described in any one of claims 1 to 3, or the steps of the IP address management method as described in any one of claims 4 to 7.

Images