Disclosure of Invention
The application provides a method for asynchronously and concurrently storing domain name registration information, which aims to solve the problem of error in storing the registration information.
The application provides a method for asynchronously and concurrently storing domain name registration information, which comprises the following steps:
obtaining a transaction result through a transaction component, wherein the transaction result comprises transaction success and transaction failure;
If the transaction result is that the transaction is successful, acquiring registration information;
And constructing 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 through the registration information.
The asynchronous storage component can decouple the data storage and the transaction component, so as to avoid influencing the transaction component, and the registration information is organized into task objects to realize asynchronous storage and improve the reliability of data storage.
In some possible embodiments, the asynchronous storage component includes a first distribution module, an execution module, and a log module;
the constructing the task object and sending the task object to an asynchronous storage component to store the registration information through the asynchronous storage component includes:
acquiring states of the log module, wherein the states comprise enabled and disabled;
if the state is an enabling state, controlling the log module to receive the task object;
If the state is not enabled, the task object is sent to a first distribution module;
And matching an execution module instance through the first distribution module, and storing the registration information through the execution module.
By means of the log module and the first distribution module, the asynchronous storage component can achieve more flexible and configurable storage operation processing flow. Whether the log module is started or not can be configured according to actual requirements. Meanwhile, the first distribution module can enable the storage operation to be distributed and executed more efficiently, and response speed and throughput are further improved.
In some possible embodiments, the log module includes a first executor and a loader;
the sending the task object to a first distribution module includes:
the task object is sent to a log queue in a serialization mode through the first executor;
And reading the task object in the log queue through the loader, and sending the task object to a first distribution module according to the reading progress.
By introducing the first executor and the loader, the log module may implement a flexible and efficient log handling mechanism. This mechanism not only ensures that log information can be recorded and processed, but also improves processing efficiency and scalability.
In some possible embodiments, the first distribution module includes a distribution queue and a distributor that reads messages of the distribution queue;
The method further comprises the steps of:
Receiving a task object in the distribution queue, and acquiring the task object through the distributor;
acquiring a command type based on the task object, wherein the command type comprises 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 father domain name of a host of the host related command;
hash computation is performed on the first key and/or the second key to obtain a hash value.
In some possible embodiments, the execution module includes a second actuator;
the matching, by the first distribution module, the execution module instance, and storing, by the execution module, the registration information includes:
acquiring an index number of the execution module instance through the hash value;
according to the index number, the task object is sent to a task queue of an execution module;
acquiring registration information to be stored through the task object;
And storing the registration information to be stored into a local storage through the second executor, wherein the registration information to be stored is information with update time earlier than the storage operation completion time.
Through the hash value, the load balance and uniform distribution of task objects can be realized, the condition that some execution modules are overloaded and other modules are idle is avoided, and the problem that the operation of related data is split into different execution examples and out-of-order execution is easier to occur is solved.
In some possible embodiments, the domain name related commands and/or host related commands include a create command, an update command, and a delete command;
after the registration information to be stored is stored in the local storage, the method further comprises:
If the domain name related command and/or the host related command is a creation command, the stored registration information in the local storage and the registration information to be stored are the same information, and the creation time of the stored registration information is earlier than the transaction success time of the storage command, deleting the stored registration information, and storing the registration information to be stored into the local storage;
If the domain name related command and/or the host related command is an update command, storing the registration information to be stored into a local storage, wherein the registration information to be stored is information with update time earlier than the time when the received transaction result is successful;
and if the domain name related command and/or the host related command is a deleting command and the stored registration information in the local storage and the registration information to be stored are the same information, deleting the stored registration information, wherein the stored registration information is information with updating time earlier than the time when the transaction result is received as the success of the transaction.
By setting command processing rules, reliability and consistency can be ensured, and the problems of disorder and the like of data in the concurrent processing process are avoided.
In some possible embodiments, at least two transaction components share the asynchronous storage component;
The method further comprises the steps of:
Acquiring a shared storage device;
if the shared storage equipment exists, storing the task object of the log queue to the shared storage equipment;
And if the shared storage equipment does not exist, controlling the dispatch queue to be adjusted to a remote queue so as to dispatch the task object through the remote queue.
If a shared storage device exists, the task object can be stored on the device, and multiple components can share data, so that the availability and consistency of the data are improved. If the system is unable to acquire the shared storage device, the task object is distributed to the remote server, and even if the local storage device has a problem, the data can be safely stored and backed up.
In some possible embodiments, the method further comprises:
obtaining a storage result of the execution module;
And if the storage result is failure, controlling the loader to stop reading the task object, controlling the first executor, and serially transmitting the task object to a log queue.
By adjusting the reading progress of the loader, secondary processing of data or skipping of data can be realized. Reliability and fault tolerance can be improved, and consistency and integrity of data when problems are encountered are ensured.
In some possible embodiments, the requesting end of the transaction component is deployed with a request distributor;
before the task object is sent to the asynchronous storage component, the method comprises the following steps:
Analyzing a request message sent by a transaction component through the request distributor, and acquiring a command type based on the request message, wherein the command type comprises 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 father domain name of a host of the host related command;
Performing hash computation on the first keyword and/or the second keyword to obtain a hash value;
Acquiring an index number of the asynchronous storage component instance through the hash value;
matching asynchronous storage component examples according to the index numbers;
And sending the request message to the transaction component through the request distributor.
In some possible embodiments;
the obtaining registration information includes:
Transmitting the registration information to a remote queue through the first distribution module;
the control execution module receives registration information from the remote queue.
Through the first distributing module and the remote queue, the transaction component can return the transaction result faster, and the executing module and the asynchronous storage component can asynchronously process the registration information in the background, so that a more efficient and flexible domain name registration information processing flow is realized.
According to the technical scheme, the method for asynchronously and concurrently storing domain name registration information comprises the steps of obtaining a transaction result through a transaction component, wherein the transaction result comprises transaction success and transaction failure, if the transaction result is the transaction success, obtaining the registration information, reconstructing 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, wherein the task object is organized through the registration information. The method provides the asynchronous storage component, the asynchronous storage component can decouple the data storage component from the transaction component, the transaction component is prevented from being influenced, the asynchronous storage is realized by organizing the registration information into the task object, and the reliability of the data storage is improved.
Detailed Description
Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The embodiments described in the examples below do not represent all embodiments consistent with the application. Merely exemplary of systems and methods consistent with aspects of the application as set forth in the claims.
In the domain name transaction process, local data storage is required to record registration information quickly without affecting the forwarding and success rate of the transaction. For domain name transaction results, the results may be stored via a database system, a local file system store, and an in-memory database store.
In some embodiments, a database is obtained, including a relational database and a non-relational database, the data table structure, field types, indexes, etc. in the database are redefined, the database, tables, indexes, etc. are created, and corresponding SQL statements or codes are written to insert, query, update, and delete data. The relational data such as MySQL, postgreSQL can build complex table structure and constraint, and the non-relational database such as MongoDB, redis is suitable for processing a large number of concurrent read-write operations.
Even if a database system is used for storing domain name registration information, the query efficiency is high, and the consistency and the integrity of data can be ensured. However, for relational databases, complex table structures and constraints may increase the difficulty of development and maintenance, and for non-relational databases, although the read-write performance is high, the data consistency guarantee is relatively weak.
A local file system is a file management system installed on a personal computer, server, or other computing device for organizing, managing, and providing access to data on non-volatile memory, such as hard drives, solid state drives, and the like. In other implementations, in response to an instruction by a user or application to save the domain name transaction results, a write request is sent to the local file system, which, upon receipt of the request, finds the appropriate storage location on disk and writes the domain name transaction results to that location. However, the concurrency processing capability of the local file system is limited, which may cause data writing conflict and data saving errors.
The memory database stores data in the memory to realize rapid data access and processing. The domain name registration information is stored in the memory, so that the read-write speed can be improved, but if the system crashes or restarts, the data can be lost.
In order to solve the problem of error in data storage, some embodiments of the present application provide a method for asynchronously and concurrently storing domain name registration information, where the method organizes the registration information into tasks, and places the tasks into a queue of an asynchronous storage component, so that asynchronous storage of the registration information can be implemented by means of the queue, and reliability of data storage can be improved.
As shown in fig. 1, the method comprises the steps of:
s100, obtaining a transaction result through a transaction component.
When domain name registration is performed, in some embodiments, before a transaction result is obtained, in response to a request initiated by a user, a registrar submits the request to a registry, the registry processes the request after receiving the request, and feeds back a processing result to the registrar, and the registrar notifies the user of the processing result, wherein the processing result is the transaction result. There are certain situations where it is necessary to conduct a transit through a gateway authorized by the registry when the registrar cannot directly transact with the registry. The transaction component is located in a gateway component between the registrar and the registration office and is used for processing user requests, sending the requests to the registration office and feeding back response results to the user.
The transaction results comprise transaction success and transaction failure, if the transaction results are transaction failure, error processing can be carried out or a user can be notified, and if the transaction results are transaction success, registration information is obtained, namely, when the transaction component receives the domain name transaction success results fed back by the registry, the registration information is obtained.
S200, if the transaction result is that the transaction is successful, acquiring registration information.
The registration information comprises an EPP request, a transaction result, a result receiving time and other relevant information, wherein the EPP request is a data request initiated by using an EPP protocol and used for domain name registration, updating, deleting, inquiring and other operations. These requests contain detailed information about the required operations, such as domain name to be registered, registration deadline, contact information of the registrant, etc. The transaction results may include successful registration of the domain name, i.e., successful transaction, failed registration (e.g., because the domain name has been occupied or submitted with incomplete/inaccurate information), i.e., failed transaction, error or warning information during registration, etc. The resulting receipt time is the time that the domain name registration success message was sent to the transaction component.
For other relevant information, transaction item information, namely registered domain name itself, transaction status or progress, transaction time, etc. may also be included.
S300, constructing a task object and sending the task object to the asynchronous storage component to store registration information through the asynchronous storage component.
The task objects are organized by registration information, that is, the registration information is placed as a task in the dispatch queue of the asynchronous storage component, and the result is returned to the requestor without waiting for the transaction information to complete the storage operation.
As shown in fig. 2 and fig. 3, in some embodiments, the asynchronous storage component includes a first distribution module, an execution module, and a log module, and in embodiments of the present application, by an application scenario description of a stand-alone system, the asynchronous storage component and the transaction component may be implemented in the same process, using a memory queue and a multithreading model. The first distributing module and the executing module are operated by independent threads, each queue uses a non-blocking memory queue, and the storage system can adopt a relational database. The log module is a Queue supporting data serialization, persistence and sequence reading and writing, and can be an MQ (Message Queue) or can be realized by itself.
Before storage, the state of the log module is acquired firstly, whether the log of the storage operation is recorded or not can be ensured to be selected according to actual requirements by checking the state of the log module, wherein the state comprises enabling and non-enabling, if the state is the enabling state, the log module is controlled to receive the task object, if the state is the non-enabling state, the task object is sent to the first distribution module, then the first distribution module is matched with an execution module instance, and registration information is stored through the execution module.
Under the condition that the log module is started, although an intermediate processing link is added, the log module can be used for realizing the persistent storage and fault-tolerant processing of data, so that the reliability and the consistency of the data are further improved. And if the state of the log module is the enabled state, the asynchronous storage component sends the task object to the log module instead of the first distribution module, and in particular, in some embodiments, the log module includes a first executor and a loader, the task object is sent to the log queue in a serialized manner 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.
The loader is used for loading tasks from the log queue and forwarding the tasks to the first distribution module according to the storage progress, and the loader can adjust the reading progress of the tasks according to the requirement so as to reprocess data or skip certain data when necessary.
The log uses a storage medium (server file system) different from the local storage (database), the log module does not need to analyze the data format, but only sequences the task when receiving the task and stores the task in a log queue, and an executor is not concerned about the specific format of the data and only takes charge of storing the data in the log as it is. The processing performance is faster than the data analysis processing is saved to the database, so that the performance influence on the transaction component when the database is slow can be avoided after the log module is started.
The log module can separate the executor and the loader to realize read-write separation, and physically isolate the data storage and the transaction assembly, so that the influence of the reliability of the storage assembly on the transaction assembly is avoided, namely, the transaction assembly and the writing function of the log module are combined into independent components, and the read-write module and the execution module of the log module are independent components, so that the two components are not mutually dependent.
In some embodiments, the executor fetches tasks from the task queue and writes the tasks to the log file. The loader is used for reading tasks from the log file and transmitting the tasks to the distribution module, and the distribution module receives the tasks transmitted from the loader and distributes the tasks to different execution modules for processing. The process of writing the log is synchronous, and the safety and the integrity of the data are ensured. The process of reading the log can be completed asynchronously in the background, so that the speed of writing the log is not affected. The loader is used as an intermediate layer to realize decoupling of reading and writing, so that operations of writing the log and reading the log can be independently carried out. Hardware resources can be effectively utilized, and throughput and response time are improved. Meanwhile, due to separation of read-write operation, system bottleneck problem caused by a large number of write operations can be reduced.
As shown in fig. 4, the log module obtains a task from a task queue and writes task information into a log file, where the log file includes a log n and a log m, and the time for creating the log n is earlier than the time for creating the log m, for example, the log is sequentially stored into the log file according to the receiving order in the queue, and the log file has a size limitation, that is, when the log n is full, the log m is newly created, and the subsequent data is written into the log m. That is, new data is written at the end of the latest log file.
The loader reads the information according to the sequence, the content of the log n is read completely, the content of the log m is read sequentially, and the reading position is updated after each piece of data is read completely. After reading, this information is passed to the first distribution module. The distributing module receives the task information from the loader and distributes the task to the executing module, and the distributing module distributes the task information to the executing module 1 and the executing module n.
When the log module is in an inactive state 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 the task object to an appropriate execution module instance according to a distribution strategy. After receiving the task object, the execution module executes corresponding storage operation according to the registration information in the task object.
The read progress is the task location that the loader has read from the log queue and forwarded to the first dispatch module. The loader needs to determine from which location to start reading at start-up. If the start is the first time, the start can be started from the head of the log queue, and if the start is the restart, the last reading position needs to be recovered. The loader continuously reads the task from the log queue, forwards the task to the first distribution module after reading the task, and updates the reading position, wherein the reading position can be the file name of the next piece of data and the displacement in the file.
If a task has been processed correctly and there is no need to repeat processing the task, the loader can skip the task by adjusting the read progress of the loader. For example, if a first executor reports that a task has been successfully processed, the loader may set the read location to the next unprocessed task.
In addition, when the execution module cannot store data, for example, because of a database connection problem, insufficient disk space or other technical faults, the operation of the loader can be temporarily stopped, and the condition that the second executor continues to receive a new task under the condition that the data cannot be stored can be avoided, so that the burden of a system is reduced. The first executor can further keep the log, and even if the first executor cannot store data temporarily, the first executor can still keep the task in the log queue, so that the data cannot be lost even if a problem occurs in the second executor.
Execution of the log module converts the task object into a string or byte array, e.g., using JSON format, each attribute in the object is converted into a key-value pair form, combined into a JSON string, and saved to the log queue. The log queue may be a file, a database table, or a part of a distributed message queue. It will be appreciated that in either form, data can be persisted to prevent loss of data.
And on the basis of serialization, the storage space can be saved and the data security can be protected through the compression and encryption functions. Taking compression as an example, in some embodiments, task objects are serialized into strings or byte arrays, and the serialized data is compressed using a compression algorithm. The compression algorithm may include GZIP (GNU compression), LZ4 (LZ 4 compression algorithm), snapy (snapy compression algorithm), brotli (Brotli compression algorithm), where GZIP is applicable to various types of data, LZ4 is applicable to high performance scenes, the compression rate is fast, but the compression rate is slightly lower than GZIP, snapy compression rate is fast, applicable to scenes with large data volume, brotli is applicable to Web content compression, and the compression rate is higher.
Illustratively, the task object is serialized into a JSON string, the JSON string is compressed using a GZIP algorithm, a compressed byte array is generated, and the encrypted byte array is saved in a log queue. When the encrypted byte array is read, the compressed byte array is decompressed by using the GZIP, restored into a JSON character string, and then the JSON character string is inversely sequenced into an original task object and sent to a distribution queue of the first distribution module.
In some embodiments, the first distributing module includes a distributing queue and a distributor, the distributor reads a message of the distributing queue, and when a new task arrives at the distributing queue, a task object is acquired from the distributing queue. The first distribution module supports parallel processing and improves the processing capacity of data storage.
After the first distributing module receives the task object in the distributing queue, the task object is obtained through the distributor, and then the command type is obtained based on the task object, wherein the command type comprises a domain name related command and a host computer related command, for the domain name related command, a first keyword, namely a domain name, is extracted from the task object, for the host computer related command, a second keyword, namely a parent domain name of the host computer, is extracted from the task object, a hash algorithm is used for carrying out hash calculation on the extracted keywords, the hash algorithm can comprise MD5, SHA-1, SHA-256 and the like, and keywords with different lengths can be converted into hash values with fixed lengths through the hash calculation, so that the processing and the storage are convenient.
And executing remainder taking operation on the number of the execution module examples through the calculated hash value, wherein the number can be hash (domainName)% n, obtaining an index number of the execution module examples, sending a task object to a task queue of the execution module according to the index number, and acquiring registration information to be stored through the task object, wherein the execution module comprises a second executor, and storing the registration information to be stored to a local storage through the second executor.
In other embodiments, the index may be obtained by a similar way of consistent hashing, where the integer value (hash value) is used to remainder the fixed number m instead of the instance number, where m is a value much greater than n, and each value of n corresponds to a value interval in m. And obtaining a corresponding instance index according to the value interval of m in which the remainder is obtained.
Based on a distribution rule of the domain name, for the domain name related command, the distributor performs hash calculation based on the domain name, and selects an execution module according to a hash result, so that all changes of the same domain name are executed by the same execution module, and the problem of disorder caused by the fact that a plurality of execution modules execute the changes of the same domain name is avoided.
Based on the distribution rule of the domain name, for the command related to the host, because the host is attached to the parent domain name, the distributor can perform hash calculation similar to the domain name command based on the parent domain name of the host, select an execution module according to 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 change of the parent domain name, thereby avoiding disorder when the host command and related domain name command are stored. For example, if the parent domain name of host host1.A.cn is a.cn, then the command associated with host1.A.cn will be executed in the same execution module instance as the command associated with a.cn.
The domain name related commands and/or host related commands include create (create) commands, update (update) commands, and delete (delete) commands, as needed to distinguish between domain name related commands and host related commands, depending on whether the object to which the command relates is a domain name or host. However, both domain name related commands and host related commands require hash computations based on domain name to select an execution module.
And for the command related to the domain name, carrying out hash calculation based on the domain name, distributing to different execution modules through load balancing, realizing parallel storage, selecting the execution modules according to the hash result, and ensuring that all changes of the same domain name are executed by the same execution module.
And for the command related to the host, hash calculation is performed based on the name of the parent domain name of the host, and the command is distributed to different execution modules through load balancing, so that parallel storage is realized. And selecting an execution module according to the hash result, and ensuring that all commands of the same host are executed by the same execution module instance and are executed in the same execution module instance with the change of the parent domain name.
For the create command, a new domain name record is created, when the second executor stores the registration information, if 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 is deleted first, and then the new data is created. If the corresponding data does not exist in the local storage or the creation time of the data is later than the successful transaction time of the create command, the current command is ignored.
For the update command, a part or all of the fields of the existing domain name record are updated, only the data whose last update time is earlier than the transaction success time of the update command is updated, and if the data is never updated, the creation time is used as a reference for comparison.
For Delete command, delete is used to Delete the existing domain name record. If there is corresponding data in the local store and the creation time of the data is earlier than the transaction success time of the delete command, the data is deleted. If there is no corresponding data in the local store, or the creation time of the data is later than the transaction success time of the delete command, the current command is ignored.
In addition, EPP CREATE commands are included, and the successful results of the transaction include the time of the transaction success (creation). Other commands that do not include a transaction success time include the time the transaction component receives the transaction success result as the transaction success time.
As shown in fig. 5, for complex scenarios, for example, when there are instances of multiple transaction components, there may be instances where different asynchronous storage components handle the same object when employing the above-described implementations. For this case, load balancing can be performed by adding a request distributor to the request end of the transaction component and adopting the same distribution strategy as that of the first distribution module of the asynchronous storage component.
In some embodiments, a request distributor is deployed on the request end of the transaction component, and the request distributor parses the request message.
The method comprises the steps of analyzing a request message sent by a transaction component through a request distributor, acquiring a command type based on the request message, extracting a first keyword and/or a second keyword, wherein the command type comprises a domain name related command and a host related command, the first keyword is a domain name of the domain name related command, the second keyword is a father domain name of a host of the host related command, hash calculation is performed on the first keyword and/or the second keyword to obtain a hash value, surplus operation is performed on the number of execution module examples through the hash value to obtain an index number of an asynchronous storage component example, the asynchronous storage component example is matched according to the index number, and the request message is sent to the transaction component through the request distributor.
That is, the request distributor distributes requests to different transaction components, enabling load balancing. After the asynchronous storage component instance receives the task, the task is processed according to the original flow, including the persistent storage of the log module and the reading and distributing of the loader.
The read-write separation of the log module is enabled by using a mode that a plurality of transaction components correspond to one asynchronous storage component, and the log is saved by using shared storage. In some embodiments, at least two transaction components share an asynchronous storage component. The shared storage device is first acquired, and the shared storage device uses shared storage, such as NFS (Network FILE SYSTEM ), SAN (Storage Area Network, storage area Network) or the like, to save the log system or Network, so that all transaction component instances can access the same log data.
As shown in fig. 6 and 7, if the shared storage device exists, the task object and the log file of the log queue are stored in the shared storage device, and if the shared storage device does not exist, the distribution queue is controlled to be adjusted to be a remote queue so as to distribute the log file through the remote queue. The remote queue is a queue that stores tasks to be processed for caching and scheduling tasks, e.g., rabbitMQ, kafka, etc. The first distribution module receives tasks from the remote queue and selects execution module instances for processing according to the keywords.
As shown in fig. 8, in order to improve the scalability, stability and efficiency of the system, in the distributed system, a first distribution module of an asynchronous storage component responsible for scheduling and distributing tasks is deployed separately from an execution module actually executing the tasks, so as to facilitate respective optimization and expansion. The distribution module and the execution module may be deployed on different machines or even distributed across different network environments. To achieve efficient distribution and processing of tasks, remote queues are required to coordinate communications. In the scenario where the first dispatch module and the execution module are decoupled and deployed separately, the queue of the execution module must be a queue supporting remote access.
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 distributing module is used for distributing the transaction result to a remote queue and connecting the transaction component and the remote queue.
After the transaction is successful, the first distribution module sends the registration information to the remote queue to realize asynchronous distribution of the registration information, so that the transaction component can immediately return the result without waiting for the completion of the storage operation, the execution module receives the registration information from the remote queue, and when the registration information is received, the execution module organizes the registration information into a task object and sends the task object to the asynchronous storage component for storage, thereby realizing asynchronous processing of the registration information and further improving the response speed and throughput.
When the first distributing module and the executing module are not deployed separately, the queue of the executing module does not need to adopt a remote queue.
The method provided by the application provides an asynchronous storage component for the registration gateway system, can realize quick storage of registration information, avoids old data from covering new data, can normally record data into a queue of the log by adding a sustainable queue log when storage fails, and can recover data from the queue of the log and store the data into a database after the database fails to repair. The method uses the name based on the domain name or the parent domain name of the host as a keyword to load balance the registration information, and on the premise of ensuring the correctness of service data, the domain name registration information is stored concurrently, and on the premise of not influencing normal service execution, the storage performance is improved. When the data is stored, only the old data is updated based on the successful time of the transaction, so that the new data is prevented from being modified by mistake under the condition of delay or response loss. The log module is used by the component to ensure that data is not lost when the local storage is unavailable, so that the reliability of the data storage is improved, and the possible influence of the data storage on data forwarding is reduced.
The above-provided detailed description is merely a few examples under the general inventive concept and does not limit the scope of the present application. Any other embodiments which are extended according to the solution of the application without inventive effort fall within the scope of protection of the application for a person skilled in the art.