A gateway migration system and method

Abstract

Embodiments of the present application disclose a gateway migration system and method. The system comprises a smart device, a storage system, a first gateway in long connection with the smart device, and a second gateway in an available state. After receiving a restart instruction, the first gateway finds and determines a corresponding active long voice session and session corresponding session state information, writes the session state information into the storage system, and sends a chain-kicking instruction to the smart device corresponding to the active long voice session. In response to receiving the chain-kicking instruction, the smart device disconnects the long connection with the first gateway and sends a chain-building request to the second gateway. In response to receiving the chain-building request, the second gateway reads corresponding session state information from the storage system according to the session identifier carried by the request and establishes a long connection with the smart device. The system guides the smart device to actively disconnect the connection with the first gateway and seamlessly reconnects the second gateway based on the session state information, thereby maintaining the continuity of long voice interaction during batch release.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of digital communication connection management, and in particular, to a gateway migration system and method. BACKGROUND

[0002] With the rapid development of intelligent voice interaction devices (such as smart speakers, smart wearable devices), more and more application scenarios need to support long-time voice interaction. For example, a smart speaker needs to be able to process long-time voice instructions from a user, a smart wearable device needs to be able to record long-time meeting minutes, a real-time translation application needs to support long-time voice input, etc. However, when a traditional long connection gateway is released in batches, it usually causes some connections to be interrupted, thereby affecting the continuity of voice interaction. Users may encounter problems such as voice input interruption, translation failure, etc., which seriously affects the user experience.

[0003] Therefore, how to guarantee the continuity of long-time voice interaction during the batch release of a long connection gateway has become a problem to be solved. SUMMARY

[0004] Therefore, the embodiments of the present application provide a gateway migration system and method to realize the non-perception migration of intelligent devices during the batch release of a long connection gateway by introducing a self-defined kick chain protocol, a session state persistence mechanism, a breakpoint resume mechanism and a Redis publish / subscribe loopback mechanism, and to guarantee the continuity of long-time voice sessions.

[0005] In a first aspect, a gateway migration system is provided, and the system comprises:

[0006] an intelligent device;

[0007] a storage system;

[0008] a plurality of gateways, the plurality of gateways comprising a first gateway maintaining a long connection with the intelligent device and a second gateway in an available state;

[0009] The first gateway is configured to, in response to receiving a restart instruction, find and determine an active long-time voice session corresponding to the first gateway and session state information corresponding to the active long-time voice session, write the session state information into the storage system, and send a kick chain instruction to the intelligent device corresponding to the active long-time voice session.

[0010] The intelligent device is configured to, in response to receiving the kick chain instruction, disconnect the long connection with the first gateway, and send a chain building request to the second gateway, the chain building request comprising a session identifier.

[0011] The second gateway is configured to read corresponding session state information from the storage system according to the session identifier in response to receiving the link establishment request, and send a link establishment success notification to the smart device.

[0012] In a second aspect, a gateway migration method is provided, which is suitable for a smart device, and the method comprises:

[0013] Continuously obtaining user voice data;

[0014] Sending the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to a task server;

[0015] In response to receiving a link kicking instruction sent by the first gateway, disconnecting the long connection with the first gateway;

[0016] Generating a corresponding link establishment request, the link establishment request comprising a session identifier;

[0017] Sending the link establishment request to a second gateway, so that the second gateway reads corresponding session state information from a storage system according to the session identifier;

[0018] In response to receiving the link establishment success notification, continuing to send the user voice data to the second gateway.

[0019] In a third aspect, a gateway migration method is provided, which is suitable for a gateway, and the method comprises:

[0020] In response to receiving a restart instruction, finding and determining an active long voice session corresponding to a first gateway;

[0021] Determining session state information corresponding to the active long voice session;

[0022] Writing the session state information into a storage system;

[0023] Sending a link kicking instruction to a smart device corresponding to the active long voice session, so that the smart device actively disconnects the long connection with the first gateway and establishes a long connection with a second gateway.

[0024] In a fourth aspect, a gateway migration method is provided, which is suitable for a gateway, and the method comprises:

[0025] In response to receiving a link establishment request sent by a smart device, reading corresponding session state information from a storage system according to a session identifier carried by the link establishment request, the session state information comprising a channel identifier;

[0026] Subscribing to a specified channel according to the channel identifier, the specified channel being a channel provided in the storage system for the first gateway to publish and subscribe to user voice data;

[0027] sending a link establishment success notification to the intelligent device;

[0028] publishing the user voice data to the designated channel in response to receiving the user voice data sent by the intelligent device.

[0029] In a fifth aspect, a gateway migration apparatus is provided, and the apparatus comprises:

[0030] a first acquisition module configured to continuously acquire user voice data;

[0031] a first sending module configured to send the user voice data to a first gateway that maintains a long connection with the intelligent device, so that the first gateway forwards the user voice data to a task server;

[0032] a disconnection module configured to disconnect the long connection with the first gateway in response to receiving a kick link instruction sent by the first gateway;

[0033] a generation module configured to generate a corresponding link establishment request, the link establishment request comprising a session identifier;

[0034] a second sending module configured to send the link establishment request to a second gateway, so that the second gateway reads corresponding session state information from a storage system according to the session identifier;

[0035] a third sending module configured to continue sending the user voice data to the second gateway in response to receiving the link establishment success notification.

[0036] In a sixth aspect, a gateway migration apparatus is provided, and the apparatus comprises:

[0037] a search module configured to search for and determine an active long voice session corresponding to a first gateway in response to receiving a restart instruction;

[0038] a first determination module configured to determine session state information corresponding to the active long voice session;

[0039] a writing module configured to write the session state information into a storage system;

[0040] a fourth sending module configured to send a kick link instruction to an intelligent device corresponding to the active long voice session, so that the intelligent device actively disconnects the long connection with the first gateway and establishes a long connection with a second gateway.

[0041] In a seventh aspect, a gateway migration apparatus is provided, and the apparatus comprises:

[0042] read a corresponding session state information from the storage system according to a session identifier carried in the link establishment request in response to receiving the link establishment request sent by the intelligent device, the session state information including a channel identifier;

[0043] subscribe to a specified channel according to the channel identifier, the specified channel being a channel provided in the storage system for the first gateway to publish and subscribe to user voice data;

[0044] the fifth sending module is configured to send a link establishment success notification to the intelligent device;

[0045] the publishing module is configured to publish the user voice data to the specified channel in response to receiving the user voice data sent by the intelligent device.

[0046] The gateway migration system of the embodiment of the application includes an intelligent device, a storage system and a plurality of gateways, the plurality of gateways including a first gateway maintaining a long connection with the intelligent device and a second gateway in an available state, the first gateway being configured to, in response to receiving a restart instruction, find and determine an active long voice session corresponding to the first gateway and session state information corresponding to the active long voice session, write the session state information into the storage system, and send a kick link instruction to the intelligent device corresponding to the active long voice session, the intelligent device being configured to, in response to receiving the kick link instruction, disconnect the long connection with the first gateway and send a link establishment request to the second gateway, the link establishment request including a session identifier, the second gateway being configured to, in response to receiving the link establishment request, read the corresponding session state information from the storage system according to the session identifier and send a link establishment success notification to the intelligent device. The system guides the intelligent device to actively disconnect the connection with the first gateway and seamlessly reconnect the second gateway based on the session state information persisted in the storage system, thereby maintaining the continuity of long voice interaction during batch publishing. BRIEF DESCRIPTION OF DRAWINGS

[0047] The above and other objects, features and advantages of the application will be more clearly understood from the following description of the embodiments of the application with reference to the drawings, in which:

[0048] Figure 1 a schematic diagram of the gateway migration system of the embodiment of the application;

[0049] Figure 2 a long voice interaction flowchart of the embodiment of the application;

[0050] Figure 3 a gateway migration interaction flowchart of the embodiment of the application;

[0051] Figure 4 a flowchart of the gateway migration method suitable for the intelligent device of the embodiment of the application;

[0052] Figure 5 Flow chart of a gateway migration method for a gateway according to an embodiment of the application;

[0053] Figure 6 Flow chart of a gateway migration method for a gateway according to an embodiment of the application;

[0054] Figure 7 Schematic diagram of a gateway migration device according to an embodiment of the application;

[0055] Figure 8 Schematic diagram of a gateway migration device according to an embodiment of the application;

[0056] Figure 9 Schematic diagram of a gateway migration device according to an embodiment of the application. DETAILED DESCRIPTION

[0057] The present application is described below based on embodiments, but the present application is not limited to these embodiments only. In the following detailed description of the present application, some specific details are described in detail. The present application can also be fully understood without the description of these details by those skilled in the art. In order to avoid confusion of the essence of the present application, well-known methods, processes, flows, elements and circuits are not described in detail.

[0058] In addition, those skilled in the art should understand that the drawings provided herein are for illustrative purposes only, and the drawings are not necessarily drawn to scale.

[0059] Unless the context clearly requires otherwise, throughout the description, the words "comprise", "comprising", and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

[0060] In the description of the present application, it should be understood that the terms "first", "second", etc. are only for the purpose of description, and cannot be understood as indicating or implying relative importance. In addition, in the description of the present application, unless otherwise stated, the meaning of "multiple" is two or more.

[0061] The solutions described in the specification and embodiments, if related to personal information processing, will be processed on the premise of legality (for example, obtaining the consent of the subject of personal information, or being necessary for the performance of a contract, etc.), and only within the prescribed or agreed range. Users refuse to process personal information other than the necessary information required for basic functions, which will not affect the user's use of basic functions.

[0062] Figure 1 Schematic diagram of a gateway migration system according to an embodiment of the application. As shown in Figure 1As shown, the gateway migration system includes an intelligent device 110, a storage system 120, and a plurality of gateways, including a first gateway 130 in a long connection with the intelligent device 110 and a second gateway 140 in an available state.

[0063] The gateway migration system of the present embodiment supports a custom kick-chain protocol. The kick-chain protocol is a lightweight bidirectional control protocol designed specifically for long connection scenarios, used by the server (i.e., the first gateway 130) to actively guide the client (i.e., the intelligent device 110) to smoothly disconnect the current connection and reconnect to the new server node (the second gateway 140) during gateway batch release, fault migration, or gray upgrade, thereby ensuring zero interruption, zero packet loss, and zero repeated processing of long voice sessions.

[0064] Further, the intelligent device 110 refers to a terminal hardware with network communication capability, capable of collecting and / or playing voice, and continuously interacting with the gateway through a long connection. The device form of the intelligent device 110 includes but is not limited to a smart speaker, a smart earphone, a translation stick, a car-mounted voice box, a conference recording pen, a wearable wrist computer, etc.

[0065] Further, the intelligent device 110 includes a voice pickup component, a network communication component, a disconnection-reconnection component, and a data cache component.

[0066] The voice pickup component includes a microphone array and a loudspeaker, etc., configured to continuously collect user voice data and / or play the results.

[0067] The network communication component is configured to establish a long connection with the first gateway 130, and send the collected user voice data to the first gateway 130 based on the long connection, and receive the voice processing results returned by the first gateway 130. Specifically, it supports WebSocket, MQTT, or custom binary long connection based on the TCP / IP protocol stack.

[0068] The disconnection-reconnection component has built-in KICK / ACK_KICK frame analysis and execution logic, configured to execute the kick-chain protocol to achieve millisecond-level disconnection-reconnection. Specifically, after receiving the kick-chain instruction sent by the first gateway 130, it actively disconnects the connection with the first gateway 130, and actively connects the second gateway 140.

[0069] The data cache component is configured to cache unconfirmed voice frames for a short time, and cooperate with the retry strategy to prevent packet loss.

[0070] In the present embodiment, the intelligent device 110 is both the source of user voice data and the final executor of the kick-chain protocol, and its reconnection behavior determines whether the system can achieve the goal of "zero interruption".

[0071] The storage system 120 can be a Remote Dictionary Server (Redis), which is an open source, in-memory, high-performance key-value store supporting multiple data structures (such as String, Hash, List, Set, SortedSet, Stream, Pub / Sub, etc.) and providing persistence and replication mechanisms. In this embodiment, Redis simultaneously assumes the dual roles of a "real-time message bus" and a "session state repository". The real-time message bus refers to the publish / subscribe (Pub / Sub) communication mechanism provided by Redis, which allows publishers to send messages and subscribers to receive messages. The session state repository (key-value + TTL) refers to the storage of session states in a key-value cache manner. Redis Pub / Sub is used to decouple the producers and consumers of voice data, thereby constructing a long voice interaction data channel with high stability and low latency, and effectively avoiding data loss.

[0072] The first gateway 130 and the second gateway 140 are both long-connection gateways. A long-connection gateway is a network access and session scheduling node deployed in the cloud or at the edge, which is responsible for maintaining one or more TCP / WebSocket long connections with a large number of intelligent devices 110 and performing data transmission and reception, protocol conversion, traffic routing, state maintenance, fault migration, etc. during the entire connection life cycle. In this embodiment, the long-connection gateway is a "full-duplex voice channel + session router" between the intelligent device 110 and the task server in the cloud, which is responsible for routing, authentication, load balancing, etc.

[0073] In a possible implementation, the system further includes a task server 150. The task server 150 refers to a general-purpose data processing device that can provide computing or application services for long voice interaction tasks, which can be a single computer, a cluster of multiple computers, or a cloud server that can elastically adjust computing resources through cloud technology. In this embodiment, the task server 150 is configured to process the user voice data and return the voice processing result to the gateway. Specifically, its role is to convert the user voice data sent by the gateway into understandable, interactive, and storable task results through voice recognition, semantic understanding, and voice synthesis, and then return the results to the intelligent device 110 through the gateway, and further feed back the results to the user. This embodiment does not describe and limit the process of the task server 150 processing user voice data and generating results in detail, and it should be understood that this process can be implemented by using any existing voice processing technology.

[0074] Further, the first gateway 130 is configured to, in response to receiving the restart instruction, find and determine the active long voice session corresponding to the first gateway 130 and the session state information corresponding to the active long voice session, write the session state information into the storage system 120, and send a kick-off instruction to the intelligent device 110 corresponding to the active long voice session.

[0075] wherein the restart instruction is an instruction for triggering the gateway to enter a restart process, the active long voice session refers to a long voice session that is currently being interacted, and the session state information is used to indicate basic information of the current session, such as a session identifier, an intelligent device identifier, a received voice duration, a transmitted byte offset, a processed event instruction sequence (such as WAKEUP, ASR_PARTIAL, ASR_FINAL…), a last update timestamp, a Redis Pub / Sub channel name (fixed as voice:stream), a sampling rate, an encoding format, a language, a task context, and the like.

[0076] Further, the intelligent device 110 is configured to, in response to receiving the kick-off instruction, disconnect the long connection with the first gateway 130, and send a chain establishment request to the second gateway 140, the chain establishment request including a session identifier.

[0077] In addition, the chain establishment request can further include an intelligent device identifier, a transmitted voice byte offset, and the like.

[0078] Further, the second gateway 140 is configured to, in response to receiving the chain establishment request, read the corresponding session state information from the storage system 120 according to the session identifier, and send a chain establishment success notification to the intelligent device 110.

[0079] Further, the session state information includes a session identifier, an intelligent device identifier, a transmitted voice byte offset, and a processed event instruction sequence, wherein the session identifier is used to identify the corresponding session (i.e., long voice interaction). The processed event instruction sequence refers to a list of events that have been completely processed and will not be repeated in this long voice interaction, arranged in chronological order. Each item is an instruction or result that cannot be replayed, and the new gateway (the second gateway 140) must skip these events when continuing, starting from the next unprocessed event, to avoid repeated recognition, repeated translation, or repeated broadcast.

[0080] The second gateway 140 is configured to verify the link establishment request according to the device identifier, and in response to the smart device identifier in the link establishment request matching the smart device identifier in the session state information, indicating that the verification is successful, the second gateway 140 sends a link establishment success notification carrying the transmitted voice byte offset to the smart device 110, and in response to receiving the user voice data uploaded by the smart device 110, processes the user voice data according to the processed event instruction sequence. The smart device 110 is also configured to continue uploading the user voice data from the transmitted voice byte offset after receiving the link establishment success notification. The transmitted voice byte offset is used to prompt the second gateway 140 to continue receiving voice from which byte, so as to avoid repeated identification of the same audio. According to the transmitted voice byte offset, the voice stream is continued, data retransmission is avoided, and unnecessary data transmission during gateway migration is reduced as much as possible.

[0081] Further, each of the gateways (the first gateway 130 and the second gateway 140) is configured to send the user voice data uploaded by the smart device 110 in a long connection with the gateway to the task server 150 in response to receiving the user voice data.

[0082] Further, the first gateway 130 is also configured to send the user voice data uploaded by the smart device 110 to a designated channel of the storage system 120, and subscribe to the designated channel to obtain and send the user voice data to the task server.

[0083] The designated channel specifically refers to a Pub / Sub channel name previously agreed upon and commonly used by all gateways, for example, voice:stream. It is not a channel created separately for each session or each device, but a globally unique broadcast channel. All voice frames are sent to this channel, and the message body is used to distinguish different interactive sessions. The channel name is written as a constant in the gateway configuration, and can be dynamically adjusted through environment variables or a configuration center to achieve unified management and horizontal expansion.

[0084] Notably, the publishing and the subscribing correspond to the same specified channel, and the two form a "self-publishing-self-subscribing" loop within the gateway process, which is used to zero-copy the user voice data from the receiving thread to the processing thread, and then forward it to the task server. The "self-publishing-self-subscribing" refers to the "publisher" and the "subscriber" in the same gateway sharing a Redis Pub / Sub channel, forming an in-process or same-host data loop path. After the voice data comes in from the network card, it does not pass through a cross-process queue or a disk, but directly completes a "publish-subscribe" closed loop in milliseconds through the Redis local loop address, so as to change "real-time voice continuously flowing in a long connection" into "an independent message stream that can be horizontally scaled, fault-tolerant, and restarted at will during gray release", without loss, disorder, or blocking.

[0085] Further, the "self-publishing-self-subscribing" can decouple the network thread and the task thread, and the network thread is only responsible for packet receiving and Redis channel writing; and the task thread is only responsible for channel reading, voice recognition, and packet sending. In this way, even if the task thread is suspended due to algorithm upgrade, GC, or restart, the network thread can still "throw the user voice data into the channel" first, without blocking the sending window of the intelligent device 110.

[0086] Further, the "self-publishing-self-subscribing" makes Redis become a migration anchor. When the gateway (here, the first gateway 130) needs to be restarted, the network thread stops first, and the task thread also stops, but the data in the Redis channel still exists. After the new gateway (here, the second gateway 140) is started, as long as the same channel is subscribed again, the old data can be processed, and "breakpoint continuation" is realized.

[0087] Further, the "self-publishing-self-subscribing" also facilitates horizontal scaling / gray release. Specifically, the same channel can be subscribed by multiple new gateways in parallel (broadcast mode), for A / B testing or traffic mirroring, without the need to change the device SDK.

[0088] Further, the "self-publishing-self-subscribing" also avoids in-process queue crashes. If a local memory queue is used, the queue disappears after the gateway is restarted. The Redis channel externalizes the queue, which is naturally persistent or at least has a TTL, and does not lose data after a restart.

[0089] The Redis loop of the "self-publishing-self-subscribing" essentially changes the user voice data from a real-time voice stream into a migratable, cacheable, and replayable message stream, so that the gateway can be restarted at will, and the intelligent device 110 has no perception.

[0090] Further, the first gateway 130 is further configured to subscribe to the specified Redis channel in the same process or the same host to obtain the voice data and forward to the task server. Wherein, the same process refers to two pieces of code in this process: one is responsible for publishing the received voice package to the specified channel; the other is responsible for subscribing to the same specified channel, and sending the voice package to the task thread after obtaining the voice package. The two pieces of code are in the same process address space and share the same memory. The same host refers to the same physical machine or container. Sometimes, two processes are started for high availability: process A only does network I / O (packet receiving->publishing), and process B only does task logic (subscription->algorithm calling->packet returning). Although they are not in the same process, they run on the same host and communicate through the Redis native loopback address, with a delay of <0.1 ms, which is also included in the same host range.

[0091] Further, the first gateway 130 is further configured to, in response to the user voice data sending or processing failure, write the failure record back to the failure queue of the storage system 120 to wait for the compensation thread of the first gateway 130 or the second gateway 140 to replay or reply according to the retry strategy. Specifically, after the gateway receives the voice data through Redis subscription, if failure occurs (network timeout, task server exception, parsing error, etc.) during forwarding or processing to the task server, the gateway needs to perform fault tolerance processing: send the voice data to the task server again according to the exponential backoff strategy to realize retry. If the retry still fails, the failure record (including voice data, session ID, failure reason) is written to the failure queue or Stream (such as voice: fail) of Redis to write back to Redis. Another gateway or compensation thread will periodically read the failure record from the queue to replay or reply, ensuring that the voice data is finally processed correctly and avoiding user session interruption or data loss.

[0092] Further, the first gateway 130 is further configured to perform a complete gateway migration process of weight zero, active session detection, kick chain instruction issuing, and session state writing back to Redis before the corresponding gateway enters the restart process.

[0093] Further, the weight zeroing refers to that the first gateway 130 is further configured to invoke a virtual server to adjust the weight corresponding to the first gateway 130 to a predetermined value and remove the traffic of the first gateway 130. The predetermined value can be 0. The virtual server (Vip Server) is used to receive client requests and forward the requests to real servers in the back end. It is used to realize load balancing and high availability. In this embodiment, the virtual server is configured to adjust the weight of the first gateway 130 to 0 under the control of the first gateway 130 and remove the traffic of the first gateway 130. Specifically, the first gateway 130 actively invokes the weight adjustment API provided by the virtual server to control the weight adjustment. When the first gateway 130 needs to be restarted, the weight is dynamically adjusted to 0 to realize accurate traffic removal. By adjusting the weight, new long language interaction requests can no longer fall on the first gateway 130 which is about to be restarted, thereby avoiding the chaotic traffic of "half old and half new" in the chain kicking migration process and ensuring zero interruption in batch release.

[0094] Further, the active session detection refers to that the first gateway 130 is specifically configured to scan all the long connections of the first gateway 130 currently in a device dimension one by one to identify active long voice sessions in a connection multiplexing state, and generate an active long voice session table according to the identification result. The active long voice session table includes at least one intelligent device 110 which needs to execute a chain kicking instruction.

[0095] The scanning of the long connection in the device dimension can minimize the session attribution granularity. Specifically, only one TCP long connection is established between each intelligent device 110 and the gateway, but multiple event instructions such as wake-up, ASR segment, semantic result, etc. can be concurrently performed in the connection. It can also avoid false kicking. If the connection or session is scanned as the granularity, the same device can be repeatedly counted. The device dimension can ensure that "only one entry appears for one device", thereby accurately generating a target intelligent device set. In addition, it can also ensure state consistency. Specifically, when the gateway is restarted, the whole intelligent device 110 must be reconnected to the new node, rather than letting different sessions of the intelligent device 110 be scattered to multiple gateways, otherwise, it will appear that the sentence is broken, out of order or repeatedly identified.

[0096] Further, the chain kicking instruction issuing refers to that the first gateway 130 is configured to send a chain kicking instruction to the intelligent device 110 corresponding to the active long voice session. Details are not repeated here.

[0097] Further, the session state write-back Redis refers to that the first gateway 130 is configured to generate session state information corresponding to the active long voice session and write the session state information into the storage system 120. Details are not repeated here.

[0098] Further, the first gateway 130 is further configured to set a time to live corresponding to the session state information.

[0099] The TTL can protect memory, consistency boundary and simplify cleanup logic. Specifically, the peak of long voice session can reach hundreds of thousands, the TTL ensures that the expired data is released in time to prevent Redis OOM. 30 seconds is enough to complete the kick chain-reconnect-continue transmission; more than that is considered an abnormal scene, avoiding old snapshots interfering with new sessions. There is no need for additional background tasks to scan expired keys, Redis automatically deletes, reducing system complexity.

[0100] In one possible implementation, the key name is first constructed using a three-part naming structure of migration:{gatewayId}:{deviceId}:{sessionId}, which ensures global uniqueness and quick positioning. Then the value object is assembled and written into the command, such as using atomic commands. If the write fails, retry with exponential backoff, if the retry fails for 3 times, write into the migration:fail:{gatewayId} Stream for compensation thread processing. Finally, set the time to live (TTL), which can be dynamically adjusted through the configuration center, with a default value of 30 seconds. After TTL is written, the countdown starts, and Redis automatically deletes the key when it expires.

[0101] Writing session state information back to Redis can achieve cross-process sharing, state migration, fault self-healing, and gray / rollback support. Specifically, after the first gateway 130 restarts, the process disappears, and the second gateway 140 needs to obtain the session context as a new process. Redis can provide out-of-process shared storage. Through unified key naming, any new gateway can continue transmission by GET migration:{gatewayId}:{deviceId}:{sessionId}, without the need to modify the device side. If the smart device 110 does not reconnect within the TTL, the key will automatically expire, and the system will handle the session timeout, avoiding the accumulation of zombie sessions. The operation and maintenance personnel can read the session snapshot in Redis at any time to evaluate the migration progress or rollback to the old gateway.

[0102] Further, the kick chain instruction further includes a transmitted voice byte offset and a corresponding timestamp, and the smart device 110 is further configured to continue uploading the user voice data from the byte offset after receiving the build chain success notification.

[0103] Further, the session state information includes a channel identifier, and the second gateway 140 is configured to subscribe to the specified channel according to the channel identifier.

[0104] Further, the first gateway 130 is further configured to, in response to detecting that there is an active long voice conversation, detect and wait for a single event instruction processing of all active long voice conversations to be completed, and determine conversation state information corresponding to the active long voice conversation.

[0105] In a possible implementation, the first gateway 130 can determine whether the currently active long voice interaction has completed single processing according to characteristics of the event instruction. The event instruction can be translation, dialogue, etc. If the event instruction is translation, the single processing is that a complete sentence is translated. If the event instruction is dialogue, the single processing is that a question of the user is answered or a complete sentence is generated, etc. The definition of word processing can be determined according to actual conditions, and the gateway is migrated after the word processing is determined to be completed, which can improve the experience of the user and avoid that the user perceives obvious pauses during voice interaction.

[0106] The gateway migration system of the embodiment of the application includes an intelligent device, a storage system and a plurality of gateways, the plurality of gateways include a first gateway in a long connection with the intelligent device and a second gateway in an available state, the first gateway is configured to, in response to receiving a restart instruction, find and determine an active long voice conversation corresponding to the first gateway and conversation state information corresponding to the active long voice conversation, write the conversation state information into the storage system, and send a chain-kicking instruction to the intelligent device corresponding to the active long voice conversation, the intelligent device is configured to, in response to receiving the chain-kicking instruction, disconnect the long connection with the first gateway, and send a chain-building request to the second gateway, the chain-building request including a conversation identifier, and the second gateway is configured to, in response to receiving the chain-building request, read the corresponding conversation state information from the storage system according to the conversation identifier, and send a chain-building success notification to the intelligent device. The system guides the intelligent device to actively disconnect the connection with the first gateway, and seamlessly reconnects the second gateway based on the conversation state information persisted in the storage system, thereby maintaining the continuity of the long voice interaction during the batch release. In this embodiment, through the fine connection management and migration mechanism, the connection is actively migrated to other available nodes before the gateway machine is restarted, which avoids the failure of the user voice interaction request caused by directly disconnecting the connection, and guarantees the high availability of the service. The real-time performance of the long voice interaction during the batch release is also guaranteed, which avoids the delay and user experience interruption caused by data retransmission, and at the same time, the client does not need to maintain complex cache and retransmission logic, thereby reducing the development and maintenance cost of the client. Through the dynamic adjustment of the weight of the Vip Server, the traffic can be effectively controlled, the pressure on the server being restarted is avoided, and the stability of the overall system is guaranteed. The automated connection migration process reduces the need for manual intervention, reduces the workload of the operation and maintenance personnel, and reduces the service interruption risk caused by release.

[0107] Figure 2 A long voice interaction flowchart of the embodiment of the application is shown in FIG. 1. Figure 2As shown, the long voice interaction flow includes:

[0108] In step S201, the intelligent device establishes a long connection with the gateway.

[0109] Specifically, the intelligent device and the gateway establish a TCP long connection through TCP three-way handshake (SYN→SYN / ACK→ACK). The specific interaction process of establishing a long connection is not the focus of this embodiment and will not be expanded here.

[0110] In step S202, the intelligent device sends a wake-up request to the gateway.

[0111] In step S203, the gateway sends a wake-up request to the task server.

[0112] The wake-up request is used to request the task server to start long voice interaction (or session).

[0113] In step S204, the task server sends an interaction start notification to the gateway.

[0114] In step S205, the gateway sends an interaction start notification to the intelligent device.

[0115] The interaction start notification is used to prompt the intelligent device to enter long voice interaction.

[0116] In step S206, the intelligent device obtains user voice data.

[0117] In step S207, the intelligent device sends the user voice data to the gateway.

[0118] In step S208, the gateway sends the user voice data to the storage system to publish the user voice data to a specified channel based on the publish / subscribe communication mechanism.

[0119] In step S209, the gateway starts a storage system subscription service on the same node to subscribe to the specified channel.

[0120] In step S210, the gateway subscribes to the user voice data from the specified channel.

[0121] In step S211, the gateway sends the user voice data to the task server.

[0122] In step S212, the task server processes the user voice data to obtain a corresponding voice processing result.

[0123] In step S213, the task server sends the voice processing result to the gateway.

[0124] In step S214, the gateway sends the voice processing result to the intelligent device.

[0125] Step S215, the intelligent device outputs the voice processing result.

[0126] In one possible implementation, if the gateway fails to send the user voice data to the task server in step S210, or the task server fails to process the user voice data in step S211, fault tolerance processing is performed. For example, the voice data is sent to the task server again according to an exponential backoff strategy, and if the retry still fails, the failure record (containing the voice data, the session ID, and the failure reason) is written into a failure queue or a Stream (such as voice:fail) of the storage system. Another gateway or a compensation thread will periodically read the failure record from the queue, perform playback or reply, ensure that the voice data is finally processed correctly, and avoid interruption of the user session or loss of data.

[0127] Steps S206-S208 are network threads, and steps S209-S215 are task threads. The two threads are decoupled and can be executed in a loop.

[0128] The above Figure 2 is a normal long voice interaction implementation process. The gateway in the process is a gateway that is long-connected with the intelligent device, such as the first gateway before the chain is kicked and the second gateway after the chain is kicked and reconnected. The objects and operation implementation processes in each step can be referred to the above embodiments, which are not described herein again.

[0129] Figure 3 is a gateway migration interaction flowchart of the embodiment of the application. As shown in the figure, the gateway migration interaction flowchart includes the following steps. Figure 3

[0130] Step S301, the first gateway receives a restart notification.

[0131] At this time, the intelligent device is long-connected with the first gateway.

[0132] Step S302, the first gateway starts to start the gateway migration flowchart.

[0133] Specifically, when the first gateway is ready to enter the restart state, a Java Shut down Hook is triggered to start the gateway migration flowchart. The Java Shut down Hook is a thread executed by the Java virtual machine when it is closed. By registering the Shutdown Hook, some cleaning work can be performed before the JVM is closed, such as releasing resources, saving states, etc. In this embodiment, the Shut down Hook can be used to gracefully close the long connection, etc.

[0134] Step S303, the first gateway adjusts its weight to 0.

[0135] ​Specifically, the first gateway calls a virtual server (Vip Server) API to dynamically adjust the weight of the first gateway to 0, so as to prevent new connection requests from being routed to the first gateway and to prevent affecting subsequent migration.

[0136] In step S304, the first gateway performs active session detection to determine the target smart device set.

[0137] Specifically, the first gateway scans all long connections of the corresponding long connection gateway in the device dimension one by one to identify active long voice sessions in the connection multiplexing state, and generates an active long voice session table, which is used to determine the target smart device set that needs to execute the chain kicking instruction.

[0138] In a possible implementation, the first gateway can determine whether the currently active long voice interaction has completed single processing according to the characteristics of the event instruction. The event instruction can be translation, conversation, etc. If the event instruction is translation, the single processing is that a complete sentence is translated. If the event instruction is conversation, the single processing is that a complete sentence is generated or a question of the user is answered. The definition of word processing can be determined according to actual conditions. The migration of the gateway is performed after the word processing is completed, which can improve the experience of the user and avoid the user from perceiving obvious pauses during voice interaction.

[0139] That is, one gateway can be connected to multiple smart devices, and therefore, when one gateway is about to restart, all smart devices that need to be kicked out of the chain need to be determined.

[0140] In step S305, the first gateway determines the session state of the active long voice session.

[0141] The session state includes a session identifier, a received voice duration, and a processed event instruction sequence.

[0142] In a possible implementation, the session state can also be set with a time to live, for example, 30 seconds.

[0143] In step S306, the first gateway sends the session state to Redis.

[0144] In step S307, Redis writes the session state.

[0145] In step S308, the first gateway sends a chain kicking instruction to the smart device.

[0146] Specifically, if the current smart device is also one of the target smart device set, the chain kicking instruction is sent to the smart device to notify the smart device that the connection is about to be disconnected and the connection switching is performed.

[0147] The kick chain instruction includes information such as a session identifier, a transmitted voice byte offset, and a timestamp, so as to continue transmission.

[0148] In step S309, the intelligent device performs pre-kick chain preparation.

[0149] The pre-kick chain preparation can include stopping sending new user voice data.

[0150] In step S310, the intelligent device sends a chain breaking instruction to the first gateway.

[0151] In step S311, the first gateway disconnects from the intelligent device.

[0152] In step S312, the first gateway determines that all connections are completed and disconnected.

[0153] In step S313, the first gateway enters a restart state.

[0154] In step S314, the intelligent device sends a chain building request to the second gateway.

[0155] The chain building request carries information such as a session identifier, a transmitted voice byte offset, and a timestamp.

[0156] In step S315, the second gateway reads the corresponding session state from the storage system according to the session identifier.

[0157] Specifically, after receiving the chain building request of the intelligent device, the second gateway reads the session state from the storage system (such as Redis) to restore the context of the long voice interaction, and continues to subscribe to the specified channel corresponding to the long voice interaction based on the session identifier, to continue receiving subsequent user voice data.

[0158] In step S316, the second gateway completes connection initialization according to the session state.

[0159] In step S317, the second gateway sends a chain building success notification to the intelligent device.

[0160] In step S318, the intelligent device sends user voice data to the second gateway.

[0161] Specifically, the user voice data to be transmitted is determined and sent according to the transmitted voice byte offset.

[0162] In step S319, the second gateway sends user voice data to the task server.

[0163] After step S319 is executed, it can return to Figure 2 The corresponding node continues the long voice interaction based on the data interaction among the intelligent device, the gateway, and the task server.

[0164] The specific implementation process of the above steps can be found in the above embodiments, and will not be repeated here.

[0165] The interaction process in this embodiment is based on the kick-chain protocol, which enables the smart device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the persistent session state in Redis, thereby maintaining the continuity of long voice interactions during the batch release.

[0166] Figure 4 This is a flowchart illustrating a gateway migration method applicable to smart devices according to an embodiment of the present invention. Figure 4 As shown, the method includes:

[0167] Step S401: Continuously acquire user voice data.

[0168] Step S402: Send the user voice data to the first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to the task server.

[0169] Step S403: In response to receiving a kick-chain command from the first gateway, disconnect the long connection with the first gateway.

[0170] Step S404: Generate a corresponding connection establishment request, wherein the connection establishment request includes a session identifier.

[0171] Step S405: Send the connection establishment request to the second gateway so that the second gateway can read the corresponding session state information from the storage system according to the session identifier.

[0172] Step S406: In response to receiving the successful connection establishment notification, continue sending the user voice data to the second gateway.

[0173] The specific implementation process of the above steps can be found in the above embodiments, and will not be repeated here.

[0174] The method in this embodiment is based on the kick-chain protocol, which enables the smart device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the persistent session state in Redis, thereby maintaining the continuity of long voice interactions during batch releases.

[0175] Figure 5 This is a flowchart of a gateway migration method applicable to gateways according to an embodiment of the present invention. Figure 5 As shown, the method includes:

[0176] Step S501: In response to receiving the restart command, locate and determine the active long voice session corresponding to the first gateway.

[0177] Step S502: Determine the session state information corresponding to the active long voice session.

[0178] Step S503, write the session state information into the storage system.

[0179] Step S504, send a kick chain instruction to the intelligent device corresponding to the active long voice session, so that the intelligent device actively disconnects the long connection with the first gateway and establishes a long connection with the second gateway.

[0180] The specific implementation process of the above steps can be seen from the above embodiments, which will not be described here.

[0181] The method of the embodiment is based on the kick chain protocol to make the intelligent device actively disconnect the connection with the first gateway, and based on the persistent session state in Redis to reconnect to the second gateway seamlessly, thereby maintaining the continuity of long voice interaction during batch publishing.

[0182] Figure 6 The flowchart of the gateway migration method suitable for the gateway of the embodiment of the application. As shown in the figure, Figure 6 The method comprises:

[0183] Step S601, in response to receiving the chain establishment request sent by the intelligent device, reading the corresponding session state information from the storage system according to the session identifier carried by the chain establishment request, wherein the session state information comprises a channel identifier.

[0184] Step S602, subscribe to a specified channel according to the channel identifier, wherein the specified channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data.

[0185] Step S603, send a chain establishment success notification to the intelligent device.

[0186] Step S604, in response to receiving the user voice data sent by the intelligent device, publishing the user voice data to the specified channel.

[0187] The specific implementation process of the above steps can be seen from the above embodiments, which will not be described here.

[0188] The method of the embodiment is based on the kick chain protocol to make the intelligent device actively disconnect the connection with the first gateway, and based on the persistent session state in the storage system to reconnect to the second gateway seamlessly, thereby maintaining the continuity of long voice interaction during batch publishing.

[0189] Figure 7 The schematic diagram of the gateway migration device of the embodiment of the application. As shown in the figure, Figure 7 The device comprises:

[0190] The first acquisition module 701 is configured to continuously acquire user voice data.

[0191] The first sending module 702 is used to send the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to the task server.

[0192] The disconnect module 703 is used to disconnect the long connection with the first gateway in response to receiving a disconnect command sent by the first gateway.

[0193] The generation module 704 is used to generate a corresponding connection establishment request, wherein the connection establishment request includes a session identifier.

[0194] The second sending module 705 is used to send the connection establishment request to the second gateway, so that the second gateway can read the corresponding session state information from the storage system according to the session identifier.

[0195] The third sending module 706 is used to continue sending the user voice data to the second gateway in response to receiving the connection establishment success notification.

[0196] The device in this embodiment uses a kick-chain protocol to enable the smart device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch releases.

[0197] Figure 8 This is a schematic diagram of a gateway migration device according to an embodiment of the present invention. Figure 8 As shown, the device includes:

[0198] The lookup module 801 is used to find and determine the active long voice session corresponding to the first gateway in response to receiving a restart command.

[0199] The first determining module 802 is used to determine the session state information corresponding to the active long voice session.

[0200] The writing module 803 is used to write the session state information into the storage system.

[0201] The fourth sending module 804 is used to send a kick-chain command to the smart device corresponding to the active long voice session, so that the smart device actively disconnects from the long connection with the first gateway and establishes a long connection with the second gateway.

[0202] The device in this embodiment uses a kick-chain protocol to enable the smart device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch releases.

[0203] Figure 9 This is a schematic diagram of a gateway migration device according to an embodiment of the present invention. Figure 9 As shown, the device includes:

[0204] The reading module 901 is used to respond to a connection establishment request sent by a smart device and read the corresponding session status information from the storage system according to the session identifier carried in the connection establishment request. The session status information includes a channel identifier.

[0205] The subscription module 902 is used to subscribe to a specified channel according to the channel identifier, wherein the specified channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data.

[0206] The fifth sending module 903 is used to send a connection establishment success notification to the smart device.

[0207] The publishing module 904 is used to publish the user voice data to the designated channel in response to receiving user voice data sent by the smart device.

[0208] The device in this embodiment uses a kick-chain protocol to enable the smart device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch releases.

[0209] The above-mentioned products can perform the methods provided in the embodiments of this application, and have the corresponding functional modules and beneficial effects of performing the methods. For technical details not described in detail in this embodiment, please refer to the methods provided in the embodiments of this application.

[0210] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A gateway migration system, characterized in that, The system includes: Smart devices; Storage system; Multiple gateways, including a first gateway that maintains a long-term connection with the smart device and a second gateway that is in an available state; The first gateway is configured to, in response to receiving a restart command, locate and determine the active long voice session corresponding to the first gateway and the session status information corresponding to the active long voice session, write the session status information into the storage system, and send a kick-chain command to the smart device corresponding to the active long voice session. The active long voice session refers to the long voice session that is currently being interacted with, and the session status information includes the session identifier, the byte offset that has been transmitted, and the channel identifier. The smart device is configured to disconnect the long connection with the first gateway and send a connection establishment request to the second gateway in response to receiving the kick-out command, the connection establishment request including a session identifier; The second gateway is configured to, in response to receiving a connection establishment request, read the corresponding session state information from the storage system based on the session identifier and send a connection establishment success notification to the smart device; The smart device is also configured to continue uploading user voice data by transmitting the voice byte offset itself after receiving the successful connection notification; The second gateway is configured to subscribe to a specified channel based on the channel identifier; Each of the gateways publishes user voice data from the active long voice session on a designated channel and subscribes to the designated channel to retrieve the user voice data, forming a "self-publishing-self-subscribing" data loop.

2. The system according to claim 1, characterized in that, The system also includes a task server; Each of the gateways is configured to send the user voice data to the task server in response to receiving user voice data uploaded by a smart device that is long-connected to the gateway; The task server is configured to process the user's voice data and return the voice processing results to the gateway.

3. The system according to claim 2, characterized in that, The first gateway is also configured to send user voice data uploaded by the smart device to a designated channel of the storage system, and to subscribe to the designated channel to obtain and send the user voice data to the task server.

4. The system according to claim 3, characterized in that, The first gateway is also configured to write back the failure record to the failure queue of the storage system in response to the failure of the user voice data transmission or processing, so as to wait for the compensation thread of the first gateway or the second gateway to replay or acknowledge according to the retry strategy.

5. The system according to claim 1, characterized in that, The first gateway is also configured to invoke a virtual server to adjust the weight corresponding to the first gateway to a predetermined value and remove traffic from the first gateway.

6. The system according to claim 1, characterized in that, The first gateway is specifically configured as follows: Scan all current long connections of the first gateway one by one according to the device dimension to identify active long voice sessions in the connection reuse state; An active long voice conversation list is generated based on the recognition results. The active long voice conversation list includes at least one smart device that needs to execute a kick-chain command.

7. The system according to claim 1, characterized in that, The first gateway is also configured to set the time-to-live (TTL) corresponding to the session state information.

8. The system according to claim 3, characterized in that, The kick-chain instruction also includes a timestamp corresponding to the offset of the transmitted voice bytes.

9. The system according to claim 3, characterized in that, The session state information includes the device identifier and the sequence of processed event commands; The second gateway is configured to verify the connection request based on the device identifier, and in response to successful verification, send a connection success notification carrying the offset of the transmitted voice bytes to the smart device, and in response to receiving user voice data uploaded by the smart device, process the user voice data according to the processed event instruction sequence. The smart device is also configured to continue uploading the user voice data from the byte offset after receiving the successful connection notification.

10. The system according to claim 1, characterized in that, The first gateway is also configured to, in response to the detection of an active long voice session, detect and wait for the completion of single event instructions for all active long voice sessions, and determine the session status information corresponding to the active long voice session.

11. A gateway migration method, applicable to smart devices, characterized in that, The method includes: Continuously acquire user voice data; The user voice data is sent to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to the task server. The user voice data is voice data in an active long voice session, and the active long voice session refers to a long voice session that is currently being interacted with. In response to receiving a kick-chain command from the first gateway, disconnect the long-lived connection with the first gateway; Generate a corresponding connection establishment request, the connection establishment request including a session identifier; Send the connection establishment request to the second gateway so that the second gateway can read the corresponding session status information from the storage system according to the session identifier and subscribe to the specified channel according to the channel identifier. The session status information includes the session identifier, the byte offset of transmission, and the channel identifier. Upon receiving the connection establishment success notification, the system transmits the voice byte offset to the second gateway and continues uploading the user's voice data. Each of the gateways publishes user voice data from the active long voice session on a designated channel and subscribes to the designated channel to retrieve the user voice data, forming a "self-publishing-self-subscribing" data loop.

12. A gateway migration method, applicable to gateways, characterized in that, The method includes: In response to receiving a restart command, the active long voice session corresponding to the first gateway is located and determined. The active long voice session refers to the long voice session that is currently being interacted with. Determine the session state information corresponding to the active long voice session, wherein the session state information includes the session identifier, the byte offset of the transmitted data, and the channel identifier; Write the session state information into the storage system; Send a kick-off command to the smart device corresponding to the active long voice session, so that the smart device actively disconnects from the long connection with the first gateway and establishes a long connection with the second gateway. After receiving the successful connection establishment notification sent by the second gateway, it transmits the voice byte offset itself and continues to upload user voice data. Each of the gateways publishes user voice data from the active long voice session on a designated channel and subscribes to the designated channel to retrieve the user voice data, forming a "self-publishing-self-subscribing" data loop. The second gateway is configured to subscribe to the designated channel based on the channel identifier.

13. A gateway migration method, applicable to gateways, characterized in that, The method includes: In response to receiving a connection establishment request from a smart device, the corresponding session status information is read from the storage system according to the session identifier carried in the connection establishment request. The session status information is the status information of an active long voice session, and the session status information includes the session identifier, the offset of the transmitted bytes, and the channel identifier. Subscribe to a designated channel according to the channel identifier, wherein the designated channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data; Send a connection establishment success notification to the smart device; In response to receiving the offset of the voice bytes transmitted by the smart device itself, the system continues to upload the user's voice data and publishes the user's voice data to the designated channel. Each of the gateways publishes user voice data from the active long voice session on a designated channel and subscribes to the designated channel to retrieve the user voice data, forming a "self-publishing-self-subscribing" data loop.

Images