Method for asynchronously and concurrently storing domain name registration information

Abstract

The invention provides a method for asynchronously and concurrently storing domain name registration information, and the method comprises the steps: obtaining a transaction result through a transaction component, the transaction result comprising transaction success and transaction failure; if the transaction result is that the transaction succeeds, registration information is obtained, a task object is constructed, the task object is sent to an asynchronous storage component, the registration information is stored through the asynchronous storage component, and the task object is organized through the registration information. According to the method, an asynchronous storage component is provided, the asynchronous storage component can decouple a data storage component and a transaction component, influence on the transaction component is avoided, and by organizing registration information as task objects, asynchronous storage is achieved, and the reliability of data storage is improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method for asynchronously and concurrently storing domain name registration information. Background Art

[0002] Domain name registrars use the Extensible Provisioning Protocol (EPP) to communicate with top-level domain (TLD) registries to ensure that domain name registrars can provide services to users efficiently. However, not all registrars have the ability or authority to communicate directly with the registry. In this case, a gateway service provided by a third-party organization can be used.

[0003] The gateway service acts as an intermediary layer, allowing registrars to perform domain name transaction operations with the registry, such as registration, renewal, transfer, etc. The results of these operations are determined by the registry that manages the domain name. In order to facilitate subsequent query, audit, statistics and analysis, the gateway service still needs to store successful transaction records in the local database, and can speed up the system's response speed.

[0004] For domain name users, the response time for transaction results is often high, and local data storage should avoid significant impact on the forwarding of successful transactions. Since the domain name transaction has been completed, local storage should be completed as soon as possible to reduce delays, but concurrent processing may cause errors in the storage of registration information. For example, the final result of a domain name is incorrect after multiple modifications are entered into the database, or when creating a host, its parent domain name cannot be processed because it does not exist. Summary of the invention

[0005] The present application provides a method for asynchronously and concurrently storing domain name registration information to solve the problem of errors in storing registration information.

[0006] The present application provides a method for asynchronously and concurrently storing domain name registration information, comprising:

[0007] Obtaining transaction results through the transaction component, wherein the transaction results include transaction success and transaction failure;

[0008] If the transaction result is successful, obtaining registration information;

[0009] A task object is constructed and sent to an asynchronous storage component so that the registration information is stored by the asynchronous storage component, wherein the task object is organized by the registration information.

[0010] Through the asynchronous storage component, the data storage and transaction components can be decoupled to avoid affecting the transaction components, and the registration information can be organized into task objects to achieve asynchronous storage and improve the reliability of data storage.

[0011] In some feasible embodiments, the asynchronous storage component includes a first distribution module, an execution module, and a log module;

[0012] The step of constructing a task object and sending the task object to an asynchronous storage component so as to store the registration information through the asynchronous storage component includes:

[0013] Obtain the status of the log module, which includes enabled and disabled;

[0014] If the state is enabled, controlling the log module to receive the task object;

[0015] If the state is an inactive state, sending the task object to a first distribution module;

[0016] The execution module instance is matched through the first distribution module, and the registration information is stored through the execution module.

[0017] Through the log module and the first distribution module, the asynchronous storage component can realize a more flexible and configurable storage operation processing flow. Whether the log module is enabled or not can be configured according to actual needs. At the same time, the first distribution module can make the storage operation more efficiently distributed and executed, further improving the response speed and throughput.

[0018] In some feasible embodiments, the log module includes a first executor and a loader;

[0019] The sending the task object to the first distribution module includes:

[0020] By means of the first executor, the task object is serialized and sent to a log queue;

[0021] The loader reads the task object in the log queue, and sends the task object to the first distribution module according to the reading progress.

[0022] By introducing the first executor and loader, the log module can implement a flexible and efficient log processing mechanism. This mechanism not only ensures that log information can be recorded and processed, but also improves processing efficiency and scalability.

[0023] In some feasible embodiments, the first distribution module includes a distribution queue and a distributor, and the distributor reads the message of the distribution queue;

[0024] The method further comprises:

[0025] Receiving the task object in the distribution queue and obtaining the task object through the distributor;

[0026] Acquire a command type based on the task object, where the command type includes a domain name related command and a host related command;

[0027] Extracting a first keyword and / or a second keyword, wherein the first keyword is a domain name of the domain name-related command, and the second keyword is a parent domain name of a host of the host-related command;

[0028] A hash calculation is performed on the first keyword and / or the second keyword to obtain a hash value.

[0029] In some feasible embodiments, the execution module includes a second actuator;

[0030] The matching of the execution module instance by the first distribution module and storing the registration information by the execution module includes:

[0031] Obtaining the index number of the execution module instance through the hash value;

[0032] According to the index number, the task object is sent to the task queue of the execution module;

[0033] Obtaining the registration information to be stored through the task object;

[0034] The registration information to be stored is stored in a local storage through the second executor, wherein the registration information to be stored is information whose update time is earlier than the completion time of the storage operation.

[0035] Through hash values, load balancing and uniform distribution of task objects can be achieved, avoiding situations where some execution modules are overloaded while other modules are idle, and operations on related data are split into different execution instances, which makes it more prone to out-of-order execution.

[0036] In some feasible embodiments, the domain name related command and / or host related command includes a create command, an update command and a delete command;

[0037] After storing the registration information to be stored in the local storage, the method further includes:

[0038] If the domain name related command and / or host related command is a creation command, and the stored registration information in the local storage is the same as the registration information to be stored, and the creation time of the stored registration information is earlier than the transaction success time of the storage command, then the stored registration information is deleted, and the registration information to be stored is stored in the local storage;

[0039] If the domain name related command and / or the host related command is an update command, the registration information to be stored is stored in the local storage, and the registration information to be stored is information whose update time is earlier than the time when the transaction result is received as a successful transaction;

[0040] If the domain name related command and / or host related command is a deletion command, and the stored registration information in the local storage is the same as the registration information to be stored, then the stored registration information is deleted, and the stored registration information is the information whose update time is earlier than the time when the transaction result is received as a successful transaction.

[0041] By setting command processing rules, you can ensure reliability and consistency and avoid problems such as data disorder during concurrent processing.

[0042] In some feasible embodiments, at least two transaction components share the asynchronous storage component;

[0043] The method further comprises:

[0044] Get a shared storage device;

[0045] If there is a shared storage device, storing the task object of the log queue in the shared storage device;

[0046] If there is no shared storage device, the distribution queue is controlled to be adjusted to a remote queue, so as to distribute the task object through the remote queue.

[0047] If a shared storage device exists, the task object will be stored on the device, and multiple components can share data, improving data availability and consistency. If the system cannot obtain a shared storage device, the task object is distributed to a remote server, so that even if there is a problem with the local storage device, the data can still be safely stored and backed up.

[0048] In some feasible embodiments, the method further includes:

[0049] Obtaining the stored result of the execution module;

[0050] If the storage result is a failure, the loader is controlled to stop reading the task object, and the first executor is controlled to serialize the task object and send it to the log queue.

[0051] By adjusting the reading progress of the loader, data can be processed twice or data can be skipped. This can improve reliability and fault tolerance, and ensure data consistency and integrity when problems occur.

[0052] In some feasible embodiments, a request distributor is deployed at the request end of the transaction component;

[0053] Before sending the task object to the asynchronous storage component, the method includes:

[0054] Parsing the request message sent by the transaction component through the request distributor, and acquiring a command type based on the request message, wherein the command type includes a domain name related command and a host related command;

[0055] Extracting a first keyword and / or a second keyword, wherein the first keyword is a domain name of the domain name-related command, and the second keyword is a parent domain name of a host of the host-related command;

[0056] Performing a hash calculation on the first keyword and / or the second keyword to obtain a hash value;

[0057] Obtaining the index number of the asynchronous storage component instance through the hash value;

[0058] According to the index number, matching the asynchronous storage component instance;

[0059] The request message is sent to the transaction component through the request distributor.

[0060] In some feasible embodiments;

[0061] The obtaining of registration information includes:

[0062] Sending the registration information to a remote queue through the first distribution module;

[0063] The control execution module receives registration information from the remote queue.

[0064] Through the first distribution module and the remote queue, the transaction component can return the transaction result faster, while the execution module and the asynchronous storage component can asynchronously process the registration information in the background, thereby achieving a more efficient and flexible domain name registration information processing process.

[0065] It can be seen from the above technical solutions that the present application provides a method for asynchronously and concurrently storing domain name registration information, the method comprising: obtaining a transaction result through a transaction component, the transaction result including a successful transaction and a failed transaction; if the transaction result is a successful transaction, obtaining registration information, reconstructing a task object, and sending the task object to an asynchronous storage component to store the registration information through the asynchronous storage component, wherein the task object is organized by the registration information. The method provides an asynchronous storage component, which can decouple data storage and transaction components to avoid affecting the transaction components, and realizes asynchronous storage by organizing registration information into task objects, thereby improving the reliability of data storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] In order to more clearly illustrate the technical solution of the present application, the drawings required for use in the embodiments are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0067] Figure 1 A flowchart of a method for asynchronously and concurrently storing domain name registration information provided by an embodiment of the present application;

[0068] Figure 2 A schematic diagram of the structure of an asynchronous storage component provided in an embodiment of the present application;

[0069] Figure 3 A schematic diagram of the execution process of the asynchronous storage component provided in an embodiment of the present application;

[0070] Figure 4 A schematic diagram of the read-write separation process of the log module provided in an embodiment of the present application;

[0071] Figure 5 A schematic diagram of the load balancing process of the transaction component provided in an embodiment of the present application;

[0072] Figure 6 A schematic diagram of a log module storage process using shared storage provided in an embodiment of the present application;

[0073] Figure 7 A schematic diagram of a stored procedure using a remote distribution queue provided in an embodiment of the present application;

[0074] Figure 8 A schematic diagram of a stored procedure using a remote execution queue provided in an embodiment of the present application. DETAILED DESCRIPTION

[0075] The following embodiments are described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following embodiments do not represent all implementations consistent with the present application. They are only examples of systems and methods consistent with some aspects of the present application as detailed in the claims.

[0076] In the process of domain name transaction, local data storage is required to quickly record registration information without affecting the forwarding and success rate of the transaction. The domain name transaction results can be stored in the database system, local file system storage and memory database storage.

[0077] In some embodiments, a database is obtained, including a relational database and a non-relational database, and then the data table structure, field type, index, etc. in the database are defined, a database, table, index, etc. are created, and corresponding SQL statements or codes are written to insert, query, update and delete data. Among them, relational databases such as MySQL, PostgreSQL, etc. can establish complex table structures and constraints; non-relational databases such as MongoDB, Redis, etc. are suitable for processing a large number of concurrent read and write operations.

[0078] Even if a database system is used to store domain name registration information, the query efficiency is high and the consistency and integrity of the data can be ensured. However, for relational databases, complex table structures and constraints may increase the difficulty of development and maintenance; for non-relational databases, although the read and write performance is high, the data consistency guarantee is relatively weak.

[0079] The local file system is a file management system installed on a personal computer, server or other computing device, which is used to organize, manage and provide access to data on non-volatile storage, such as hard disk drives, solid-state drives, etc. In other implementations, in response to an instruction from a user or application to save the domain name transaction results, a write request is issued to the local file system. After receiving the request, the file system will find a suitable storage location on the disk and write the domain name transaction results to the location. However, the local file system has limited concurrent processing capabilities, which may cause data write conflicts and data saving errors.

[0080] In-memory databases store data in memory to enable fast data access and processing. Storing domain name registration information in memory can increase read and write speeds, but data may be lost if the system crashes or restarts.

[0081] In order to solve the above-mentioned problem of data storage errors, some embodiments of the present application provide a method for asynchronously and concurrently storing domain name registration information. The method organizes the registration information into tasks and puts the tasks into a queue of an asynchronous storage component. The registration information can be asynchronously stored with the help of the queue, thereby improving the reliability of data storage.

[0082] like Figure 1 As shown, the method comprises the following steps:

[0083] S100: Obtain transaction results through the transaction component.

[0084] When registering a domain name, in some embodiments, before obtaining the transaction result, in response to a request initiated by a user, the registrar submits a request to the registry. After receiving the request, the registry processes the request and feeds back the processing result to the registrar. The registrar notifies the user of the processing result, and the processing result is the transaction result. However, there are still some situations when the registrar cannot trade directly with the registry, and needs to be transferred through a gateway authorized by the registry. Among them, the transaction component is a gateway component located between the registrar and the registry, which is used to process user requests, send requests to the registry, and feed back the response results to the user.

[0085] The transaction result includes transaction success and transaction failure. If the transaction result is transaction failure, error handling can be performed or the user can be notified. If the transaction result is transaction success, registration information is obtained, that is, when the transaction component receives the result of successful domain name transaction feedback from the registry, the registration information is obtained.

[0086] S200: If the transaction result is successful, obtain registration information.

[0087] The registration information includes the EPP request, transaction result, result reception time and other related information, wherein the EPP request is a data request initiated using the EPP protocol for domain name registration, update, deletion, query and other operations. These requests contain detailed information about the required operation, such as the domain name to be registered, the registration period, the contact information of the registrant, etc. The transaction result may include successful domain name registration, i.e. successful transaction, failed registration (for example, because the domain name is already occupied or the submitted information is incomplete / inaccurate), i.e. failed transaction, and may also include error or warning information during the registration process, etc. The result reception time is the time when the domain name registration success message is sent to the transaction component.

[0088] Other relevant information may also include transaction item information, namely the registered domain name itself, transaction status or progress, transaction time, etc.

[0089] S300: construct a task object, and send the task object to the asynchronous storage component to store registration information through the asynchronous storage component.

[0090] The task object is organized by registration information, that is, the registration information is put into the distribution queue of the asynchronous storage component as a task, and the result is returned to the requester without waiting for the transaction information to complete the storage operation.

[0091] like Figure 2 , Figure 3As shown, in some embodiments, the asynchronous storage component includes a first distribution module, an execution module and a log module. The embodiment of the present application is described through the application scenario of a stand-alone system. The asynchronous storage component can be implemented in the same process as the transaction component using a memory queue and a multi-threaded model. Among them, the first distribution module and the execution module are both run by independent threads, each queue uses a non-blocking memory queue, and the storage system can use a relational database. The log module is a queue that supports data serialization, persistence, and sequential read and write. It can be MQ (Message Queue) or it can be implemented by itself.

[0092] Before storage, first obtain the status of the log module. By checking the status of the log module, you can ensure that you choose whether to record the log of the storage operation according to actual needs. The status includes enabled and disabled. If the status is enabled, control the log module to receive the task object. If the status is disabled, send the task object to the first distribution module, and then match the execution module instance through the first distribution module, and store the registration information through the execution module.

[0093] When the log module is enabled, although an intermediate processing link is added, the log module can realize persistent storage and fault-tolerant processing of data, further improving reliability and data consistency. In addition, if the log module is in an enabled state, the asynchronous storage component will send the task object to the log module instead of the first distribution module. Specifically, in some embodiments, the log module includes a first executor and a loader; the task object is serialized and sent to the log queue through the first executor; the task object is read in the log queue through the loader, and the task object is sent to the first distribution module according to the reading progress.

[0094] The loader is used to load tasks from the log queue and forward the tasks to the first distribution module according to the storage progress. The loader can adjust its reading progress as needed to reprocess data or skip certain data when necessary.

[0095] The log uses a different storage medium (server file system) than the local storage (database). The log module does not need to parse the data format. It only serializes the task when it is received and saves it to the log queue. The executor does not care about the specific format of the data and is only responsible for saving the data as is to the log. The processing performance is faster than the speed of parsing and processing the data and saving it to the database. Therefore, after the log module is enabled, the performance impact on the transaction component when the database is slow can also be avoided.

[0096] The log module can deploy the executor and loader separately to achieve read-write separation, and physically isolate the data storage and transaction components to avoid the impact of the reliability of the storage component on the transaction component. That is, the transaction component and the write function of the log module are combined into independent components, and the read and distribution module and execution module of the log module are independent components, and the two sides are no longer dependent on each other.

[0097] In some embodiments, the executor takes the task out of the task queue and writes the task into a log file. The loader is used to read the tasks from the log file and pass them to the distribution module. The distribution module receives the tasks passed from the loader and assigns them to different execution modules for processing. The process of writing the log is synchronous to ensure the security and integrity of the data. The process of reading the log can be completed asynchronously in the background, which will not affect the speed of writing the log. As an intermediate layer, the loader realizes the decoupling of reading and writing, so that the operations of writing and reading logs can be performed independently. It can effectively utilize hardware resources and improve throughput and response time. At the same time, due to the separation of read and write operations, the system bottleneck problem caused by a large number of write operations can also be reduced.

[0098] like Figure 4 As shown, the log module obtains tasks from the task queue and writes the task information into the log file. For example, the log file includes log n and log m, and the creation time of log n is earlier than the creation time of log m. The logs are saved to the log file in the order in which they are received in the queue. The log file has a size limit, that is, when log n is full, a new log m is created, and subsequent data is written to log m. In other words, the new data is written at the end of the latest log file.

[0099] The loader reads the information in order. After the content of log n is read, the content of log m is read in order. After each piece of data is read, the reading position is updated. After reading, the information is passed to the first distribution module. The distribution module receives the task information from the loader and distributes the task to the execution module. The distribution module distributes the task information to execution module 1 and execution module n.

[0100] When the log module is not enabled or the loader reads the task object in the log queue and sends the task object to the first distribution module according to the reading progress, the first distribution module receives the task object and distributes it to the appropriate execution module instance according to the distribution strategy. After receiving the task object, the execution module performs the corresponding storage operation according to the registration information in the task object.

[0101] The reading progress is the task position that the loader has read from the log queue and forwarded to the first distribution module. The loader needs to determine from which position to start reading when it starts. If it is the first startup, it can start from the head of the log queue. If it is a restart, it needs to restore the last read position. The loader continuously reads tasks from the log queue. After reading the task, it forwards it to the first distribution module and updates the reading position, where the reading position can be the file name of the next data and the displacement in the file.

[0102] If a task has been processed correctly and does not need to be processed again, the loader can be made to skip this part of the task by adjusting the loader's reading progress. For example, if the first executor reports that a task has been successfully processed, the loader can set the reading position to the next unprocessed task.

[0103] Furthermore, when the execution module cannot store data, for example, due to database connection problems, insufficient disk space, or other technical failures, the loader can be temporarily stopped to prevent the second executor from continuing to receive new tasks when it cannot store data, thereby reducing the system burden. The first executor can also continue to save logs. Even if the first executor is temporarily unable to store data, it can still continue to save tasks to the log queue, ensuring that data will not be lost even if problems occur in the second executor.

[0104] The execution of the log module converts the task object into a string or byte array. For example, using the JSON format, each attribute in the object will be converted into a key-value pair and combined into a JSON string, which is then saved to the log queue. The log queue can be a file, a database table, or part of a distributed message queue. It is understandable that no matter which form, data can be stored persistently to prevent data loss.

[0105] It is also possible to save storage space and protect data security through compression and encryption functions based on serialization. Taking compression as an example, in some embodiments, the task object is serialized into a string or a byte array, and then the serialized data is compressed using a compression algorithm. Among them, the compression algorithm may include GZIP (GNU compression), LZ4 (LZ4 compression algorithm), Snappy (Snappy compression algorithm), Brotli (Brotli compression algorithm). GZIP is suitable for various types of data, LZ4 is suitable for high-performance scenarios, and has a fast compression speed, but the compression rate is slightly lower than GZIP. Snappy has a fast compression speed and is suitable for scenarios with large amounts of data. Brotli is suitable for Web content compression and has a high compression rate.

[0106] Exemplarily, the task object is serialized into a JSON string, the JSON string is compressed using the GZIP algorithm to generate a compressed byte array, and the encrypted byte array is saved in the log queue. When reading the encrypted byte array, the compressed byte array is decompressed using GZIP and restored to a JSON string, and then the JSON string is deserialized into the original task object and sent to the distribution queue of the first distribution module.

[0107] In some embodiments, the first distribution module includes a distribution queue and a distributor, the distributor reads the message of the distribution queue, and when a new task arrives at the distribution queue, it will obtain the task object from the distribution queue. The first distribution module supports parallel processing to improve the processing capability of data storage.

[0108] After the first distribution module receives the task object in the distribution queue, the task object is obtained through the distributor, and then the command type is obtained based on the task object, where the command type includes domain name related commands and host related commands. For domain name related commands, the first keyword, that is, the domain name, is extracted from the task object. For host related commands, the second keyword, that is, the parent domain name of the host, is extracted from the task object. The extracted keywords are hashed using a hash algorithm. The hash algorithm may include MD5, SHA-1, SHA-256, etc. Through hash calculation, keywords of different lengths can be converted into hash values ​​of fixed length for easy processing and storage.

[0109] The calculated hash value is used to perform a modulo operation on the number of execution module instances, which can be recorded as hash(domainName)%n, to obtain the index number of the execution module instance, and then the task object is sent to the task queue of the execution module according to the index number. The registration information to be stored is obtained through the task object. The execution module includes a second executor, and the registration information to be stored is stored in the local storage through the second executor.

[0110] In some other embodiments, the index may be obtained by a method similar to consistent hashing, where the integer value (hash value) is modulo a fixed number m instead of the number of instances, where m is a value much larger than n, and each value of n corresponds to a numerical interval in m. The result of the modulo operation is used to obtain the corresponding instance index according to the numerical interval of m in which the result falls.

[0111] Based on the distribution rules of domain names, for domain name-related commands, the distributor performs hash calculation based on the domain name and selects the execution module according to the hash result, so that all changes to the same domain name are executed by the same execution module, avoiding the disorder problem caused by multiple execution modules executing changes to the same domain name.

[0112] Based on the distribution rules of domain names, for host-related commands, since the host is attached to the parent domain name, the distributor will perform the same hash calculation as the domain name command based on the parent domain name of the host, and select the execution module based on the hash result, so that all commands of the same host are executed by the same execution module instance, and are executed in the same execution module instance as the changes of its parent domain name, to avoid disorder when storing host commands and related domain name commands. For example, the parent domain name of the host host1.a.cn is a.cn, then the related commands of host1.a.cn will be executed in the same execution module instance as the related commands of a.cn.

[0113] Domain name related commands and / or host related commands include create commands, update commands, and delete commands. If you need to distinguish between domain name related commands and host related commands, it depends on whether the object involved in the command is the domain name or the host. However, whether it is a domain name related command or a host related command, it is necessary to perform hash calculation based on the domain name to select the execution module.

[0114] For domain name-related commands, hash calculation is performed based on the domain name name and distributed to different execution modules through load balancing to achieve parallel storage. The execution module is selected based on the hash result to ensure that all changes to the same domain name are executed by the same execution module.

[0115] For host-related commands, hash calculation is performed based on the host's parent domain name, and distributed to different execution modules through load balancing to achieve parallel storage. The execution module is selected based on the hash result to ensure that all commands of the same host are executed by the same execution module instance, and are executed in the same execution module instance as the parent domain name changes.

[0116] For the create command, which is used to create a new domain name record, when the second executor stores the registration information, if the corresponding data already exists in the local storage and the creation time of the data is earlier than the transaction success time of the create command, the old data will be deleted first, and then the new data will be created. If the corresponding data does not exist in the local storage, or the creation time of the data is later than the transaction success time of the create command, the current command will be ignored.

[0117] For the update command, which is used to update some or all fields of an existing domain name record, only the data whose last update time is earlier than the successful transaction time of the update command will be updated. If the data has never been updated, the creation time will be used as the benchmark for comparison.

[0118] For the Delete command, it is used to delete the existing domain name record. If the corresponding data exists in the local storage and the creation time of the data is earlier than the transaction success time of the delete command, the data will be deleted. If the corresponding data does not exist in the local storage, or the creation time of the data is later than the transaction success time of the delete command, the current command will be ignored.

[0119] In addition, it also includes the EPP Create command, and the transaction success result includes the transaction success (creation) time. For other commands that do not include the transaction success time, the time when the transaction component receives the transaction success result is used as the transaction success time.

[0120] like Figure 5 As shown, for complex scenarios, for example, when there are multiple instances of transaction components, different asynchronous storage components may process the same object when the above implementation is adopted. In this case, a request distributor can be added to the request end of the transaction component, and the same distribution strategy as the first distribution module of the asynchronous storage component can be adopted for load balancing.

[0121] In some embodiments, a request distributor is deployed at the request end of the transaction component, and the request distributor parses the request message.

[0122] The request dispatcher parses the request message sent by the transaction component, and obtains the command type based on the request message, wherein the command type includes a domain name-related command and a host-related command; then extracts the first keyword and / or the second keyword, wherein the first keyword is the domain name of the domain name-related command, and the second keyword is the parent domain name of the host of the host-related command; performs a hash calculation on the first keyword and / or the second keyword to obtain a hash value; performs a modulo operation on the number of execution module instances through the hash value to obtain an index number of the asynchronous storage component instance; matches the asynchronous storage component instance according to the index number; and sends the request message to the transaction component through the request dispatcher.

[0123] In other words, the request distributor distributes the request to different transaction components to achieve load balancing. After receiving the task, the asynchronous storage component instance processes the task according to the original process, including the persistent storage of the log module and the reading and distribution of the loader.

[0124] The method of using multiple transaction components to correspond to one asynchronous storage component enables the read-write separation of the log module and uses shared storage to save the log. In some embodiments, at least two transaction components share the asynchronous storage component. First, obtain a shared storage device. The shared storage device is a system or network that uses shared storage, such as NFS (Network File System), SAN (Storage Area Network), etc. to save the log, which can ensure that all transaction component instances can access the same log data.

[0125] like Figure 6 , Figure 7 As shown, if there is a shared storage device, the task object and log file of the log queue are stored in the shared storage device; if there is no shared storage device, the control distribution queue is adjusted to a remote queue to distribute the log file through the remote queue. A remote queue is a queue that stores pending tasks and is used to cache and schedule tasks, such as RabbitMQ, Kafka, etc. The first distribution module receives tasks from the remote queue and selects an execution module instance for processing based on the keyword.

[0126] like Figure 8 As shown, in order to improve the scalability, stability and efficiency of the system, in a distributed system, the first distribution module of the asynchronous storage component responsible for scheduling and allocating tasks is deployed separately from the execution module that actually executes the task, so as to facilitate their respective optimization and expansion. The distribution module and the execution module may be deployed on different machines, and may even be distributed in different network environments. In order to achieve efficient distribution and processing of tasks, remote queues are required to coordinate communication. In the scenario where the first distribution module and the execution module are decoupled and deployed separately, the queue of the execution module must be a queue that supports remote access.

[0127] In some embodiments, the registration information is sent to the remote queue by the first distribution module, and the control execution module receives the registration information from the remote queue. The first distribution module connects the transaction component and the remote queue to distribute the transaction result to the remote queue.

[0128] After the transaction is successful, the first distribution module will send the registration information to the remote queue to realize the asynchronous distribution of the registration information, so that the transaction component can return the result immediately without waiting for the storage operation to complete. The execution module receives the registration information from the remote queue. When the registration information is received, the execution module will organize it into a task object and send it to the asynchronous storage component for storage to realize asynchronous processing of the registration information and further improve the response speed and throughput.

[0129] When the first distribution module and the execution module are not deployed separately, the queue of the execution module does not need to adopt a remote queue.

[0130] The method provided by the present application provides an asynchronous storage component for the registration gateway system, which can realize the rapid storage of registration information and avoid old data overwriting new data. By adding a persistent queue log, the data can still be recorded normally in the log queue when the storage fails. After the database failure is repaired, the data can be restored from the log queue and saved in the database. Use the domain name or the host parent domain name as a keyword to load balance the registration information, and store the domain name registration information concurrently while ensuring the correctness of the business data, so as to improve the storage performance without affecting the normal business execution. When storing data, only the old data is updated based on the transaction success time to avoid erroneous modification of new data in the event of delay or response loss. The component uses a log module to ensure that data is not lost when local storage is unavailable, improve the reliability of data storage, and reduce the impact of data storage on data forwarding.

[0131] Similar parts between the embodiments provided in this application can be referenced to each other. The specific implementation methods provided above are only a few examples under the general concept of this application and do not constitute a limitation on the protection scope of this application. For those skilled in the art, any other implementation methods expanded based on the scheme of this application without creative work belong to the protection scope of this application.

Claims

1. A method for asynchronously and concurrently storing domain name registration information, characterized in that: include: Obtaining transaction results through the transaction component, wherein the transaction results include transaction success and transaction failure; If the transaction result is successful, obtaining registration information; A task object is constructed and sent to an asynchronous storage component so that the registration information is stored by the asynchronous storage component, wherein the task object is organized by the registration information.

2. The method for asynchronously and concurrently storing domain name registration information according to claim 1, characterized in that: The asynchronous storage component includes a first distribution module, an execution module and a log module; The step of constructing a task object and sending the task object to an asynchronous storage component so as to store the registration information through the asynchronous storage component includes: Obtain the status of the log module, which includes enabled and disabled; If the state is enabled, controlling the log module to receive the task object; If the state is an inactive state, sending the task object to a first distribution module; The execution module instance is matched through the first distribution module, and the registration information is stored through the execution module.

3. The method for asynchronously and concurrently storing domain name registration information according to claim 2, characterized in that: The log module includes a first executor and a loader; The sending the task object to the first distribution module includes: By means of the first executor, the task object is serialized and sent to a log queue; The loader reads the task object in the log queue, and sends the task object to the first distribution module according to the reading progress.

4. The method for asynchronously and concurrently storing domain name registration information according to claim 3, characterized in that: The first distribution module includes a distribution queue and a distributor, and the distributor reads the message of the distribution queue; The method further comprises: Receiving the task object in the distribution queue and obtaining the task object through the distributor; Acquire a command type based on the task object, where the command type includes a domain name related command and a host related command; Extracting a first keyword and / or a second keyword, wherein the first keyword is a domain name of the domain name-related command, and the second keyword is a parent domain name of a host of the host-related command; A hash calculation is performed on the first keyword and / or the second keyword to obtain a hash value.

5. The method for asynchronously and concurrently storing domain name registration information according to claim 4, characterized in that: The execution module includes a second actuator; The matching of the execution module instance by the first distribution module and storing the registration information by the execution module includes: Obtaining the index number of the execution module instance through the hash value; According to the index number, the task object is sent to the task queue of the execution module; Obtaining the registration information to be stored through the task object; The registration information to be stored is stored in a local storage through the second executor, wherein the registration information to be stored is information whose update time is earlier than the completion time of the storage operation.

6. The method for asynchronously and concurrently storing domain name registration information according to claim 5, characterized in that: The domain name related commands and / or host related commands include create commands, update commands and delete commands; After storing the registration information to be stored in the local storage, the method further includes: If the domain name related command and / or host related command is a creation command, and the stored registration information in the local storage is the same as the registration information to be stored, and the creation time of the stored registration information is earlier than the transaction success time of the storage command, then the stored registration information is deleted, and the registration information to be stored is stored in the local storage; If the domain name related command and / or the host related command is an update command, the registration information to be stored is stored in the local storage, and the registration information to be stored is information whose update time is earlier than the time when the transaction result is received as a successful transaction; If the domain name related command and / or host related command is a deletion command, and the stored registration information in the local storage is the same as the registration information to be stored, then the stored registration information is deleted, and the stored registration information is the information whose update time is earlier than the time when the transaction result is received as a successful transaction.

7. The method for asynchronously and concurrently storing domain name registration information according to claim 3, characterized in that: The first distribution module includes a distribution queue and a distributor, the distributor reads the message of the distribution queue, and at least two transaction components share the asynchronous storage component; The method further comprises: Get a shared storage device; If there is a shared storage device, storing the task object of the log queue in the shared storage device; If there is no shared storage device, the distribution queue is controlled to be adjusted to a remote queue, so as to distribute the task object through the remote queue.

8. The method for asynchronously and concurrently storing domain name registration information according to claim 3, characterized in that: The method further comprises: Obtaining the stored result of the execution module; If the storage result is a failure, the loader is controlled to stop reading the task object, and the first executor is controlled to serialize the task object and send it to the log queue.

9. The method for asynchronously and concurrently storing domain name registration information according to claim 1, characterized in that: The request end of the transaction component is deployed with a request distributor; Before sending the task object to the asynchronous storage component, the method includes: Parsing the request message sent by the transaction component through the request distributor, and acquiring a command type based on the request message, wherein the command type includes a domain name related command and a host related command; Extracting a first keyword and / or a second keyword, wherein the first keyword is a domain name of the domain name-related command, and the second keyword is a parent domain name of a host of the host-related command; Performing a hash calculation on the first keyword and / or the second keyword to obtain a hash value; Obtaining the index number of the asynchronous storage component instance through the hash value; According to the index number, matching the asynchronous storage component instance; The request message is sent to the transaction component through the request distributor.

10. The method for asynchronously and concurrently storing domain name registration information according to claim 2, characterized in that: The obtaining of registration information includes: Sending the registration information to a remote queue through the first distribution module; The control execution module receives registration information from the remote queue.

Images