Voiceprint recognition system and method based on distributed consistency protocol

Abstract

The invention provides a voiceprint recognition system and method based on a distributed consistency protocol, and belongs to the technical field of biological feature recognition, and the system comprises a message queue module which is used for receiving, storing and buffering a voiceprint recognition or registration request from the outside; the distributed processing cluster module is composed of a plurality of service nodes, and each service node runs a voiceprint recognition engine and a state machine copy of a distributed consistency protocol and is used for processing a request from the message queue module and maintaining the consistency of a cluster state through the distributed consistency protocol; and the distributed database module is used for persistently storing voiceprint feature data and identifying historical records. The maintainability, the expandability and the state consistency of the system are improved.

Description

A Voiceprint Recognition System and Method Based on Distributed Consensus Protocol Technical Field

[0001] This invention relates to the field of biometric recognition technology, specifically to a voiceprint recognition system and method based on a distributed consensus protocol. Background Technology

[0002] Voiceprint recognition, as a biometric identification technology, authenticates individuals by analyzing the unique acoustic features in their speech. In recent years, it has been widely applied in areas such as financial payments, security access control, and smart device unlocking. With the continuous expansion of application scenarios and the sustained growth of the user base, voiceprint recognition systems need to handle high-concurrency requests, ensure continuous service availability, and place higher demands on recognition accuracy and data consistency. Against this backdrop, the system architecture supporting voiceprint recognition services has become a key factor affecting its performance, reliability, and scalability.

[0003] Currently, common voiceprint recognition systems mainly adopt the following architecture patterns: First, a centralized architecture, which relies on a single server or server cluster to handle all requests. This approach is prone to response delays in high-concurrency scenarios and has the risk of single point of failure. Once the main server fails, the service will be completely interrupted. Second, a master-slave architecture, which improves redundancy by adding backup servers. However, during the master-slave switchover process, there are problems such as long service interruption time, data synchronization lag, and low resource utilization of backup servers. It is also difficult to cope with complex scenarios where multiple nodes fail simultaneously.

[0004] In summary, existing voiceprint recognition systems, when facing the demands of high concurrency, large scale, and high availability applications, generally suffer from several shortcomings, including insufficient service continuity, uneven load distribution, difficulty in ensuring data consistency, inflexible system expansion, and reliance on manual fault recovery. Therefore, how to construct a voiceprint recognition system that simultaneously possesses high availability, strong consistency, elastic scalability, and efficient load balancing capabilities has become a pressing technical problem to be solved in this field. Summary of the Invention

[0005] In view of this, it is necessary to provide a voiceprint recognition system and method based on a distributed consensus protocol to solve the technical problems of existing voiceprint recognition systems, such as insufficient service continuity, uneven load distribution, difficulty in ensuring data consistency, inflexible system expansion, reliance on manual fault recovery leading to poor system load capacity, and difficulty in ensuring data consistency.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a voiceprint recognition system based on a distributed consensus protocol, comprising: a message queue module for receiving, storing, and buffering voiceprint recognition or registration requests from external sources; a distributed processing cluster module composed of multiple service nodes, each service node running a voiceprint recognition engine and a state machine copy of the distributed consensus protocol, for processing requests from the message queue module and maintaining cluster state consistency through the distributed consensus protocol; and a distributed database module for persistently storing voiceprint feature data and recognition history records; wherein the message queue module, the distributed processing cluster module, and the distributed database module are sequentially connected.

[0007] In one possible implementation, the distributed consensus protocol is the Raft protocol; multiple service nodes in the distributed processing cluster module constitute a Raft cluster, and leader election, log replication, and state synchronization are performed through the Raft protocol.

[0008] In one possible implementation, the Leader node in the distributed processing cluster module is configured to: pull requests from the message queue module; determine whether the voiceprint recognition task should be performed by the current node or a Follower node according to a preset load balancing strategy; encapsulate the voiceprint registration, model update, or recognition record operations into log entries, and submit them for effectiveness after synchronizing them to a majority of nodes in the cluster via the Raft protocol.

[0009] In one possible implementation, when the Leader node decides to distribute the identification task to the Follower node for execution, the task information is bound with the latest log index that the Leader node has committed when the task is distributed; the Follower node is configured to execute the identification task only after applying the bound log index to its local state machine.

[0010] In one possible implementation, the voiceprint recognition system based on a distributed consensus protocol includes a load monitoring module for periodically collecting the CPU utilization, memory utilization, and task queue length of each node; the load balancing strategy is as follows: when the load index of the Leader node itself exceeds a preset threshold, the weight is calculated based on the load index of each Follower node, and the task is distributed to the Follower node with a lower load based on a weighted round-robin algorithm.

[0011] In one possible implementation, the voiceprint recognition system based on the distributed consensus protocol supports the dynamic addition and removal of nodes; the addition or removal of nodes is achieved through the Raft protocol's member change configuration log, and newly added nodes synchronize data by receiving cluster snapshots and catch-up logs.

[0012] In one possible implementation, the distributed database module is a distributed key-value database that achieves data consistency based on the Raft protocol; the voiceprint recognition system based on the distributed consistency protocol adopts a dual persistence mechanism through the Raft logs of the distributed processing cluster module and the distributed database module.

[0013] On the other hand, the present invention also provides a voiceprint recognition method based on a distributed consensus protocol, applied to the aforementioned voiceprint recognition system based on a distributed consensus protocol, comprising: receiving a voiceprint processing request sent by a client and asynchronously writing the request to a message queue; having a Leader node in a distributed processing cluster retrieve the request from the message queue; having the Leader node or a Follower node designated by the Leader node perform voiceprint recognition or registration processing to obtain a processing result; synchronizing the processing result and the corresponding operation log to a majority of nodes in the cluster through a distributed consensus protocol; returning the final processing result to the client and persisting the relevant data to a distributed database.

[0014] In one possible implementation, the voiceprint recognition or registration process performed by the Leader node or a Follower node designated by the Leader node, and the resulting processing, includes: the Leader node selecting a Follower node whose load meets the conditions as the execution node based on the real-time load status of the cluster nodes; sending the recognition task data along with the currently submitted log index to the selected execution node; and the execution node performing the recognition calculation and returning the result to the Leader node after confirming that its local status has been synchronized with the log index.

[0015] In one possible implementation, the voiceprint recognition method based on the distributed consensus protocol includes an automatic fault recovery process, which includes: when a follower node does not receive a heartbeat from the leader node within a preset time, a new round of leader election is triggered; the newly elected leader node takes over the pending requests in the message queue and continues to provide services; after the faulty node recovers, it automatically synchronizes the missing log data from the cluster and rejoins the cluster.

[0016] The beneficial effects of this invention are as follows: The voiceprint recognition system based on a distributed consensus protocol provided by this invention receives, stores, and buffers voiceprint recognition or registration requests from external sources through a message queue module; the distributed processing cluster module consists of multiple service nodes, each of which runs a state machine copy of the voiceprint recognition engine and the distributed consensus protocol to process requests from the message queue module, thereby separating request access, business processing, and data storage, which is beneficial to improving the maintainability and scalability of the system. The modular design reduces the system complexity, and the distributed consensus protocol maintains the consistency of the cluster state, thus ensuring high consistency among different nodes and avoiding voiceprint errors caused by data synchronization errors, which is beneficial to improving recognition accuracy. At the same time, the use of a distributed database module for persistent storage of voiceprint feature data and recognition history improves the recognition speed of the system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 is a schematic diagram of an embodiment of the voiceprint recognition system based on a distributed consensus protocol provided by the present invention; Figure 2 is a schematic diagram of the structure of a Raft cluster node in an embodiment of the present invention; Figure 3 is a timing diagram of Leader election in an embodiment of the present invention; Figure 4 is a flowchart of an embodiment of the voiceprint recognition method based on a distributed consensus protocol provided by the present invention; Figure 5 is a flowchart of another embodiment of S403 in Figure 4 of the present invention; Figure 6 is a flowchart of another embodiment of the voiceprint recognition method based on a distributed consensus protocol provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0020] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] This invention provides a voiceprint recognition system and method based on a distributed consensus protocol. The technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0024] Figure 1 is a schematic diagram of an embodiment of the voiceprint recognition system based on a distributed consensus protocol provided by the present invention. As shown in Figure 1, the voiceprint recognition system based on a distributed consensus protocol includes a message queue module 101, a distributed processing cluster module 102, and a distributed database module 103. The message queue module 101, the distributed processing cluster module 102, and the distributed database module 103 are communicatively connected. The message queue module 101 is used to receive, store, and buffer voiceprint recognition or registration requests from external sources. The distributed processing cluster module 102 consists of multiple service nodes, each of which runs a voiceprint recognition engine and a state machine copy of the distributed consensus protocol to process requests from the message queue module 101 and maintain the consistency of the cluster state through the distributed consensus protocol. The distributed database module 103 is used to persistently store voiceprint feature data and recognition history records.

[0025] Specifically, the system architecture adopts a layered and decoupled design. The message queue module 101 serves as the unified entry point of the system, receiving voiceprint registration or recognition requests from various clients (such as web applications and mobile apps) and providing persistent buffering. This module supports priority queues and delayed queues; for example, real-time payment authentication requests can be set to high priority, while batch historical data migration requests can be set to low priority. The leader node prioritizes pulling high-priority messages for processing.

[0026] In this embodiment, the message queue module 101 employs a message middleware to receive, store, queue, and distribute client requests. The message queue module 101 supports persistent storage to ensure that messages are not lost.

[0027] In this embodiment, the distributed processing cluster module 102 consists of at least three (preferably an odd number, such as 3, 5, or 7) service nodes forming a Raft cluster. As shown in Figure 2, each Raft node includes a Raft state machine, a voiceprint recognition engine, a message queue consumer, and a data synchronization component. As a preferred embodiment, the Raft node also includes a monitoring component.

[0028] The Raft state machine is used to maintain state information such as the current term number, log entries, and node roles (Leader / Follower / Candidate).

[0029] The voiceprint recognition engine includes functions such as audio preprocessing, feature extraction (such as MFCC, i-vector, x-vector), voiceprint model matching, and similarity calculation.

[0030] The message queue consumer is used to pull identification tasks from the message queue.

[0031] The data synchronization component is responsible for synchronizing Raft logs with other nodes and ensuring data consistency.

[0032] The monitoring component is used to monitor the health status of nodes, resource usage, etc.

[0033] It has the dual identity of a computing node and a replica of the Raft state machine, and runs a complete voiceprint recognition engine (including audio preprocessing, feature extraction, model matching and other functions) and Raft protocol components internally.

[0034] The distributed database module 103 is an independent distributed key-value database (such as TiKV) used for persistent storage of voiceprint feature models and business records. Its data access method is as follows: all nodes in the cluster can read voiceprint feature data from this database for identification and matching.

[0035] The modules are connected sequentially: the output of the message queue module 101 is connected to the input of the distributed processing cluster module 102; the cluster module interacts with the distributed database module 103 for data read and write during processing. This architecture separates request access, business processing, and data storage, which helps improve the maintainability and scalability of the system, and reduces system complexity through modular design.

[0036] In some embodiments of the present invention, the distributed consensus protocol is the Raft protocol; multiple service nodes in the distributed processing cluster module 102 constitute a Raft cluster, and leader election, log replication and state synchronization are performed through the Raft protocol.

[0037] This embodiment uses the Raft protocol as the specific consistency protocol implementation.

[0038] Multiple service nodes in the distributed processing cluster module 102 are organized into a Raft cluster. Each node plays the role of leader, follower, or candidate in the Raft protocol.

[0039] When the cluster starts, all nodes initialize to the Follower state and wait for the Leader's heartbeat. If a Follower does not receive the Leader's heartbeat within the random election timeout period (e.g., 150-300ms), it becomes a Candidate and initiates a leader election. The node that receives more than half of the votes becomes the Leader.

[0040] The leader is responsible for coordinating all client requests and encapsulating all state change operations (such as voiceprint registration, model updates, and configuration changes) into log entries, which are then synchronized to all follower nodes via the log replication mechanism (AppendEntries RPC). A log entry is considered committed and applied to the local state machine of each node only after it has been persisted by more than half of the nodes in the cluster, thus ensuring strong consistency of the cluster state.

[0041] In a specific example, as shown in Figure 3, which is a sequence diagram of Leader election, the specific process includes: First step, when the cluster starts, all nodes are initially in the Follower state and wait for the Leader's heartbeat.

[0042] The second step is that if the Follower does not receive a heartbeat from the Leader within the election timeout period (e.g., a random value of 150-300ms), it will switch to the Candidate state.

[0043] The third step is for the Candidate node to increment its current term number and send a vote request (RequestVote RPC) to all other nodes.

[0044] The fourth step is that after other nodes receive the voting request, if the Candidate's log is at least as new as their own and they have not voted in the current term, then they vote for the Candidate.

[0045] The fifth step is that if the Candidate receives a majority of votes (more than half), it becomes the new Leader and begins sending heartbeats and log synchronization messages to the Followers.

[0046] The sixth step is for the new Leader to begin processing tasks in the message queue and coordinating cluster operations.

[0047] This embodiment uses the Raft protocol to implement cluster management. Compared with uncoordinated distributed deployment, it effectively solves the data inconsistency problem and provides the system with clear fault switching logic, thereby improving the maintainability of the system.

[0048] In some embodiments of the present invention, the Leader node in the distributed processing cluster module 102 is configured to: pull requests from the message queue module 101; determine whether the voiceprint recognition task should be performed by the local node or the Follower node according to a preset load balancing strategy; encapsulate the voiceprint registration, model update or recognition record operation into log entries, and submit them for effectiveness after synchronizing them to a majority of nodes in the cluster via the Raft protocol.

[0049] Specifically, in a Raft cluster, the elected leader node assumes the core coordination function.

[0050] First, the leader node, as a consumer of the message queue, actively pulls voiceprint requests to be processed from the message queue module 101, supporting batch retrieval to improve efficiency.

[0051] Secondly, the leader node makes a decision based on its built-in load balancing strategy, determining whether the current request should be processed locally or distributed to a follower node for execution.

[0052] Finally, for all operations that cause a change in system state (such as successfully registering a new voiceprint or updating system configuration), the leader node encapsulates it into a canonical log entry and replicates it to all follower nodes via the Raft protocol's AppendEntriesRPC call. The leader will wait until it receives successful confirmation from a majority of nodes before committing the log entry locally to make the operation effective.

[0053] In a specific example, the voiceprint recognition request processing flow includes: First step, the client sends a recognition request to the message queue. The request message includes: request ID, user identifier, audio data (or audio file path), recognition type (1:1 verification or 1:N recognition), and other information.

[0054] The second step involves the message queue receiving the request, persisting it, and returning an acknowledgment message to the client.

[0055] The third step is for the Leader node to pull request messages from the message queue (batch pulling is supported to improve efficiency).

[0056] The fourth step is for the Leader node to perform voiceprint recognition processing and obtain the recognition result. The fifth step is for the Leader node to write the recognition result and operation log into the Raft log, including: appending the operation record to the local log; sending AppendEntries RPC to all Follower nodes in parallel to copy the log entry; and submitting the log entry after waiting for confirmation from a majority of nodes, and the recognition result becomes effective.

[0057] In the sixth step, the Leader node writes the identification results to the distributed database and returns the results to the client (through a callback interface or message queue).

[0058] In a specific example, the voiceprint registration process includes: First, after the client sends a registration request to the message queue, the Leader node retrieves the registration request from the message queue, extracts voiceprint features, and generates a voiceprint model. The registration request includes information such as user ID and registration audio data.

[0059] The second step involves the Leader node writing the voiceprint model and user information into the Raft log, which is then synchronized to all nodes via log replication.

[0060] The third step, after confirmation by a majority of nodes, is to store the voiceprint model in a distributed database.

[0061] The fourth step is to return a successful registration result to the client.

[0062] The Leader node configuration used in this embodiment clarifies the core responsibilities of the leader and unifies request distribution and state synchronization under the consistency protocol framework, which not only ensures system throughput but also guarantees the consistency and reliability of the state evolution of all nodes.

[0063] In some embodiments of the present invention, when the Leader node decides to distribute the identification task to the Follower node for execution, the task information is bound with the latest log index that the Leader node has committed when the task is issued; the Follower node is configured to execute the identification task only after applying a log index at least as low as the bound log index in its local state machine.

[0064] This embodiment details the key mechanisms for ensuring data consistency when Follower nodes process tasks.

[0065] Specifically, when a leader node decides to distribute a voiceprint recognition task to a follower node for execution, in order to ensure that the voiceprint model data used by the follower during processing is up-to-date and consistent, a key parameter will be attached to the task assignment message: the latest log index committed by the leader node at the time of task assignment, i.e., committedIndex.

[0066] Upon receiving a task, a Follower node does not execute it immediately. Instead, it first checks its own state machine's applied index (appliedIndex). If the local applied index is less than the received committedIndex, it indicates that the local state machine has not yet been updated to the latest committed state of the leader, and there may be unapplied latest voiceprint registrations or update logs. In this case, the Follower node will pause the identification task and wait for the local log application process to catch up until the appliedIndex reaches or exceeds the committedIndex.

[0067] Once a consensus is reached, the Follower node uses the Key-Value index table of the voiceprint model in its local state machine, and combines it with detailed model data read from a distributed database (such as TiKV), to independently execute the complete process of audio preprocessing, feature extraction, model matching, and similarity calculation.

[0068] The mechanism adopted in this embodiment forces the Follower to perform read operations under a consistent state snapshot, thereby strictly ensuring linear consistency while allowing read request load balancing, and effectively avoiding the problem of identification result deviation due to data latency.

[0069] In some embodiments of the present invention, the voiceprint recognition system based on a distributed consensus protocol includes a load monitoring module for periodically collecting the CPU utilization, memory utilization, and task queue length of each node; the load balancing strategy is as follows: when the load index of the Leader node itself exceeds a preset threshold, the weight is calculated according to the load index of each Follower node, and the task is distributed to the Follower node with a lower load based on a weighted round-robin algorithm.

[0070] As a preferred approach, the voiceprint recognition system based on a distributed consensus protocol includes a load monitoring module that periodically collects real-time load metrics of each node in the cluster at a fixed frequency (e.g., every 10 seconds).

[0071] Real-time load metrics include, but are not limited to: CPU utilization, memory utilization, network I / O utilization, current queue length of pending tasks, and task processing speed.

[0072] In this embodiment, the specific execution logic of the load balancing strategy is as follows: The leader node continuously monitors its own load. When any core indicator exceeds a preset threshold (e.g., CPU utilization consistently above 80%, memory utilization above 85%, or task queue length exceeding 100), task distribution is triggered. During distribution, the leader calculates a dynamic weight for each follower based on the load data of each follower node obtained from the monitoring module using a weighted round-robin algorithm. The weight calculation comprehensively considers various indicators, for example, assigning higher weights to nodes with lower loads. Subsequently, the leader prioritizes allocating newly arrived requests to the follower node with the highest current weight.

[0073] This embodiment achieves intelligent scheduling of computing resources by introducing real-time load monitoring and dynamic weight allocation, which can effectively avoid overload of a single node, improve the overall throughput and resource utilization of the cluster, and make the system response time more stable.

[0074] In some embodiments of the present invention, the voiceprint recognition system based on the distributed consensus protocol supports the dynamic addition and removal of nodes; the addition or removal of nodes is achieved through the Raft protocol member change configuration log, and newly added nodes synchronize data by receiving cluster snapshots and catch-up logs.

[0075] This embodiment details the mechanism for dynamically adding and removing cluster nodes. This voiceprint recognition system, based on a distributed consensus protocol, supports dynamic adjustment of the cluster size without downtime, achieving elastic scaling.

[0076] When a new node needs to be added, the administrator starts the new node and configures it with the existing cluster address. The new node sends a join request to the current leader, which encapsulates this membership change operation into a special configuration change log entry (ConfChange) and submits it to a majority of nodes in the cluster via the Raft protocol. Once the change takes effect, the new node becomes an official member.

[0077] Subsequently, the new node synchronizes data using a hybrid approach of snapshots and log catching up: first, it receives the latest state snapshot (containing all committed state data) from the Leader or a Follower, completing a full synchronization; then, starting from the log index corresponding to the snapshot, it catches up with all subsequent log entries through the log replication channel until it is completely consistent with the leader's log. After synchronization is complete, the new node becomes a Follower and begins providing services.

[0078] When a node needs to be removed, the node to be removed or the administrator initiates a removal request to the leader. The leader also generates and commits a configuration change log for removing the node. Before the configuration change is committed, the system checks to ensure that all committed data on the node to be removed has been replicated by other nodes (confirmed by comparing the committed log indices of each node). After data synchronization is confirmed, the node is safely removed from the cluster configuration.

[0079] In a specific example, the dynamic addition of a node includes the following process: First, the new node starts up, configures the cluster node list, and sends a join request to the existing nodes.

[0080] The second step is that after receiving the request, the Leader node adds the new node to the cluster configuration and synchronizes the configuration change to all nodes through the Raft protocol.

[0081] The third step is for the new node to synchronize historical logs and data from the Leader or other Follower nodes.

[0082] The fourth step is to synchronize the new node, which then becomes a Follower and begins participating in cluster operations.

[0083] The dynamic addition and removal mechanism of nodes adopted in this embodiment enables the system to scale elastically according to the business load, achieving smooth horizontal expansion and contraction, significantly improving the flexibility of resource utilization and reducing operation and maintenance costs.

[0084] In some embodiments of the present invention, the distributed database module 103 is a distributed key-value database that achieves data consistency based on the Raft protocol; the voiceprint recognition system based on the distributed consistency protocol adopts a dual persistence mechanism through the Raft logs of the distributed processing cluster module 102 and the distributed database module 103.

[0085] This embodiment elaborates on the dual persistence mechanism of the voiceprint recognition system based on a distributed consensus protocol to ensure data reliability.

[0086] Specifically, the voiceprint recognition system based on a distributed consensus protocol employs a two-layer progressive persistence strategy to ensure that data is not lost.

[0087] The first layer is Raft log persistence, where each node in the cluster persists all received state change log entries to its local disk. This ensures that the state can be recovered by replaying the logs after a single node restarts.

[0088] It should be noted that, as a preferred approach, when the logs become too large, this voiceprint recognition system based on a distributed consensus protocol also employs a snapshot mechanism to periodically compress historical logs, thereby improving recovery efficiency.

[0089] The second layer is distributed database persistence. After the final business data (such as voiceprint feature vectors, user information, and identification history) is consistently committed by the Raft cluster, the leader node writes it to a distributed key-value database like TiKV, which is based on the Raft protocol. TiKV completes multi-replica replication and persistent storage of the data within its internal Raft cluster.

[0090] Furthermore, as some preferred embodiments of this embodiment, batch processing, asynchronous processing, caching mechanisms, and load monitoring are also employed to optimize system performance.

[0091] Batch processing refers to the Leader node pulling requests from the message queue in batches and performing batch identification and processing to improve throughput.

[0092] Asynchronous processing refers to writing the recognition results and client callbacks asynchronously, without blocking the main process.

[0093] The caching mechanism reduces the number of database queries by caching commonly used voiceprint models in memory.

[0094] Load monitoring involves monitoring the load of each node in real time and dynamically adjusting the task allocation strategy.

[0095] The dual Raft persistence architecture adopted in this embodiment reliably stores the consistent state in memory as multiple replicas of persistent storage. Even if the entire voiceprint recognition cluster is completely rebuilt, complete business data can be recovered from the distributed database, which greatly improves the reliability of data and disaster recovery capabilities.

[0096] Figure 4 is a schematic flowchart of an embodiment of the voiceprint recognition method based on a distributed consensus protocol provided by the present invention. As shown in Figure 4, the voiceprint recognition method based on a distributed consensus protocol is applied to the aforementioned voiceprint recognition system based on a distributed consensus protocol, including: S401, receiving a voiceprint processing request sent by a client and asynchronously writing the request to a message queue; S402, the Leader node in the distributed processing cluster retrieves the request from the message queue; S403, the Leader node or a Follower node specified by the Leader node performs voiceprint recognition or registration processing to obtain the processing result; S404, the processing result and the corresponding operation log are synchronized to a majority of nodes in the cluster through a distributed consensus protocol; S405, the final processing result is returned to the client, and the relevant data is persisted to a distributed database.

[0097] Specifically, in this embodiment, after receiving a voiceprint processing request (which includes Base64-encoded audio, user identifier, etc.) from the client, the request is asynchronously written to a message queue for buffering. The message queue returns an acknowledgment to ensure that the request is not lost. Next, the leader node in the distributed processing cluster retrieves the request from the message queue. Then, the leader node itself, or a follower node designated according to a policy, performs the actual voiceprint recognition or registration processing and obtains the processing result. Subsequently, the processing result and the corresponding operation log must be synchronized to a majority of nodes in the cluster and committed via the distributed consensus protocol (Raft) to ensure state consistency. Finally, the leader node returns the final processing result to the client via an HTTP callback or message queue, and simultaneously persists the relevant records of this recognition to a distributed database.

[0098] This embodiment combines asynchronous processing, consistent synchronization, and result persistence to improve the system's concurrent processing capabilities while fully ensuring the reliability, consistency, and traceability of business states.

[0099] In some embodiments of the present invention, as shown in FIG5, step S403 is performed by the Leader node or a Follower node designated by the Leader node to perform voiceprint recognition or registration processing, and the processing result includes: S501, the Leader node selects a Follower node whose load meets the conditions as the execution node according to the real-time load status of the cluster nodes; S502, the recognition task data and the currently submitted log index are sent to the selected execution node; S503, after confirming that the local status has been synchronized to the log index, the execution node performs recognition calculation and returns the result to the Leader node.

[0100] This embodiment describes in detail the specific interaction steps for the Follower node to perform the recognition task.

[0101] Specifically, when the leader node decides to distribute a task to a follower based on a load balancing strategy, it first selects a follower node with a relatively light load based on real-time load monitoring data. Then, the leader encapsulates the audio data to be identified, the user identifier, the task ID, and, crucially, the current committedIndex, and sends it to the target follower node via RPC. Upon receiving the task packet, the follower node performs a critical consistency check: confirming that its local state machine's appliedIndex has reached or exceeded the committedIndex carried by the task. After confirming consistency, the follower node invokes its local voiceprint recognition engine to independently complete the entire process, including feature extraction, model matching, and similarity calculation. After calculation, the follower returns the recognition result, including the task ID, matching result, similarity score, and processing time, to the leader node via RPC. The leader node verifies the result from the follower before applying the final result and returning it to the client.

[0102] The specific voiceprint recognition or registration process in this embodiment can be referred to the description in the foregoing embodiments. To avoid repetition, it will not be repeated here.

[0103] This embodiment clarifies the specific division of labor and cooperation methods in distributed computing, enabling the computing power of Follower nodes to be fully utilized and jointly bear the pressure of high concurrency, thereby significantly improving the overall processing capacity and performance of the system.

[0104] In some embodiments of the present invention, as shown in FIG6, the voiceprint recognition method based on the distributed consensus protocol includes an automatic fault recovery process, which includes: S601, when a Follower node does not receive a heartbeat from the Leader node within a preset time, a new round of Leader election is triggered; S602, the newly elected Leader node takes over the pending requests in the message queue and continues to provide services; S603, after the faulty node recovers, it automatically synchronizes the missing log data from the cluster and rejoins the cluster.

[0105] This embodiment uses a periodic heartbeat mechanism to achieve fault detection.

[0106] Specifically, follower nodes maintain a random election timeout timer. If no heartbeat from the leader is received within the timeout period, it is determined that the leader may have failed, and the node automatically transitions to a candidate state, initiating a new round of leader election.

[0107] The election process follows the Raft protocol, with the candidate receiving the votes of a majority of nodes in the cluster becoming the new leader. Once the new leader is elected, it immediately begins sending heartbeats and takes over processing the backlog of pending requests in the message queue, continuing to provide services and achieving rapid failover. The entire process is transparent to the clients.

[0108] For old nodes (original leaders or followers) that recover after a failure, when they come back online and find that the cluster has a new leader with a higher term, they will automatically switch roles to followers and automatically synchronize all the log data lost during the failure through the Raft log replication mechanism. Once their status catches up with the cluster's progress, they will rejoin the service.

[0109] In a specific example, the automatic fault recovery process includes: First, the Follower node detects a Leader failure through a heartbeat timeout (e.g., not receiving a heartbeat after the election timeout period).

[0110] The second step is for Follower nodes to become Candidates and initiate a new round of elections.

[0111] The third step is to elect a new leader. After the new leader is elected, it checks the integrity of its own logs and synchronizes them from other nodes if any are missing.

[0112] In the fourth step, the new Leader continues to process tasks in the message queue, achieving a seamless switchover.

[0113] The fifth step is that after the faulty node recovers, it sends a join request to the cluster. The new leader synchronizes the missing log entries to it, and the recovered node becomes a follower again.

[0114] In this embodiment, the entire fault repair process requires no manual intervention, enabling the system to quickly heal itself from node failures. This reduces service interruption time from minutes in the traditional master-slave architecture to seconds, significantly improving system availability and the level of operational automation.

[0115] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0116] The above provides a detailed description of the voiceprint recognition system and method based on a distributed consensus protocol provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A voiceprint recognition system based on a distributed consensus protocol, characterized in that, The system includes a message queue module, a distributed processing cluster module, and a distributed database module, which are interconnected. The message queue module receives, stores, and buffers voiceprint recognition or registration requests from external sources. The distributed processing cluster module consists of multiple service nodes, each of which runs a state machine copy of the voiceprint recognition engine and a distributed consistency protocol to process requests from the message queue module and maintain the consistency of the cluster state through the distributed consistency protocol. The distributed database module is used to persistently store voiceprint feature data and recognition history.

2. The voiceprint recognition system based on a distributed consensus protocol according to claim 1, characterized in that, The distributed consensus protocol is the Raft protocol; the multiple service nodes in the distributed processing cluster module constitute a Raft cluster, and leader election, log replication and state synchronization are performed through the Raft protocol.

3. The voiceprint recognition system based on a distributed consensus protocol according to claim 2, characterized in that, The Leader node in the distributed processing cluster module is configured to: pull requests from the message queue module; determine whether the voiceprint recognition task should be performed by the current node or a Follower node according to a preset load balancing strategy; encapsulate voiceprint registration, model update, or recognition record operations into log entries, and submit them for effectiveness after synchronizing them to a majority of nodes in the cluster via the Raft protocol.

4. The voiceprint recognition system based on a distributed consensus protocol according to claim 3, characterized in that, When the Leader node decides to distribute the identification task to the Follower node for execution, the task information is bound with the latest log index that the Leader node has committed when the task is issued; the Follower node is configured to execute the identification task only after applying a log index at least as low as the bound log index to its local state machine.

5. The voiceprint recognition system based on a distributed consensus protocol according to claim 3, characterized in that, The voiceprint recognition system based on the distributed consensus protocol includes a load monitoring module, which is used to periodically collect the CPU utilization, memory utilization and task queue length of each node; the load balancing strategy is as follows: when the load index of the Leader node itself exceeds the preset threshold, the weight is calculated according to the load index of each Follower node, and the task is distributed to the Follower node with lower load based on the weighted round-robin algorithm.

6. The voiceprint recognition system based on a distributed consensus protocol according to claim 2, characterized in that, The voiceprint recognition system based on the distributed consensus protocol supports the dynamic addition and removal of nodes; the addition or removal of nodes is achieved through the Raft protocol's member change configuration log, and newly added nodes synchronize data by receiving cluster snapshots and catch-up logs.

7. The voiceprint recognition system based on a distributed consensus protocol according to claim 1, characterized in that, The distributed database module is a distributed key-value database that achieves data consistency based on the Raft protocol; the voiceprint recognition system based on the distributed consistency protocol adopts a dual persistence mechanism through the Raft logs of the distributed processing cluster module and the distributed database module.

8. A voiceprint recognition method based on a distributed consensus protocol, characterized in that, The voiceprint recognition system based on a distributed consensus protocol, as described in any one of claims 1 to 7, comprises: receiving a voiceprint processing request sent by a client and asynchronously writing the voiceprint processing request into a message queue; having a Leader node in a distributed processing cluster retrieve the request from the message queue; having the Leader node or a Follower node designated by the Leader node perform voiceprint recognition or registration processing to obtain a processing result; synchronizing the processing result and the corresponding operation log to a majority of nodes in the cluster through a distributed consensus protocol; returning the final processing result to the client and persisting the relevant data to a distributed database.

9. The voiceprint recognition method based on a distributed consensus protocol according to claim 8, characterized in that, The voiceprint recognition or registration process performed by the Leader node or a Follower node designated by the Leader node yields the following results: the Leader node selects a Follower node whose load meets the requirements as the execution node based on the real-time load status of the cluster nodes; the recognition task data is sent to the selected execution node along with the currently submitted log index; after confirming that its local status has been synchronized with the log index, the execution node performs the recognition calculation and returns the result to the Leader node.

10. The voiceprint recognition method based on a distributed consensus protocol according to claim 8, characterized in that, The voiceprint recognition method based on the distributed consensus protocol includes an automatic fault recovery process, which includes: when a follower node does not receive a heartbeat from the leader node within a preset time, a new round of leader election is triggered; the newly elected leader node takes over the pending requests in the message queue and continues to provide services; after the faulty node recovers, it automatically synchronizes the missing log data from the cluster and rejoins the cluster.

Images