Softphone agent state synchronization method and related products

Abstract

The application discloses a softphone agent state synchronization method and related products. In the scheme, the agent number in the sign-in request is stored in a global agent queue; the application server currently competing for a distributed lock reads the agent number from the global agent queue and distributes the agent number to the sub-queues corresponding to the application servers according to a preset balanced distribution strategy, and releases the distributed lock after the distribution is completed; each application server reads the corresponding agent number from the corresponding sub-queue, the application server currently competing for a number-level lock calls a bottom traffic capability interface to obtain the current traffic state of the corresponding agent and update the state data of the agent, and releases the number-level lock after the update is completed; and the agent number is removed from the global agent queue according to a sign-out request. The application avoids the inherent waiting delay of the traffic interface through asynchronous decoupling, double-layer queues and two-level lock mutual exclusion control, reduces invalid interface calls from the source, and improves the agent experience.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method for synchronizing the status of softphone agents and related products. Background Technology

[0002] Softphones are dedicated software for call center agents' daily operations. In customer service call center scenarios, agents use softphones to complete daily call tasks. During operation, softphones need to continuously connect to the underlying commercial call platform interface to synchronize the agent's online, offline, or call status in real time, ensuring the normal operation of agent business.

[0003] The underlying commercial call center platform interface typically uses a fixed response mechanism, but this mechanism has certain drawbacks: if the agent's call status has not changed, the interface needs to wait 10 seconds before returning response data. Continuously calling the interface to fetch agent status in the traditional polling synchronization mode generates a large number of invalid requests without any state changes. Each invalid call triggers a 10-second waiting delay, directly causing a lag in the agent status update displayed on the softphone. At the same time, the massive number of duplicate invalid requests continuously consume the underlying call center platform interface resources, further exacerbating the status synchronization delay, resulting in inconsistencies between the displayed agent status and the actual working conditions, severely impacting the agent's user experience.

[0004] How to synchronize agent status to avoid inherent waiting delays in call interfaces and reduce invalid interface calls, thereby improving the agent user experience, is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method and related products for synchronizing the status of softphone agents, aiming to synchronize agent status, avoid inherent waiting delays in call interfaces, reduce invalid interface calls, and improve the agent user experience.

[0006] The embodiments of this application disclose the following technical solutions: The first aspect of this application provides a method for synchronizing the status of softphone agents. The method is applied to a softphone agent status synchronization system, the system including a Redis cluster and multiple application servers. The method includes: The application server that receives the sign-in request from the softphone client stores the agent ID in the sign-in request into the global agent queue in the Redis cluster. The application server that currently wins the distributed lock reads the agent ID from the global agent queue and distributes the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to the preset balanced distribution strategy. After the distribution is completed, the distributed lock is released. Each application server reads the corresponding agent ID from the corresponding sub-queue. The application server that currently wins the agent ID-level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and updates the agent's status data. After the update is completed, the agent ID-level lock is released. The application server that receives the checkout request initiated by the softphone client removes the agent ID from the global agent queue.

[0007] Optionally, the lock key identifier of the distributed lock is a globally fixed key, the distributed lock is used to control the unique execution right of the distributed task, and the contention mode of the distributed lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the competition for the distributed lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the competition for the distributed lock.

[0008] Optionally, the lock key identifier of the employee ID-level lock corresponds one-to-one with the employee ID of the workstation. The employee ID-level lock is used to control the unique execution right of synchronizing the status of a single employee ID. The contention mode of the employee ID-level lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the employee ID level lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the employee ID level lock.

[0009] Optionally, distributing the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to a preset balanced distribution strategy includes: According to the preset weight or startup order of each application server, the agent IDs in the global agent queue are sequentially and cyclically distributed to the corresponding sub-queues of each application server in the Redis cluster.

[0010] Optionally, the method further includes: Record the heartbeat signals sent by each application server to the Redis cluster at preset time intervals, and record the last heartbeat time; If the time interval between the last heartbeat time and the current time of any application server exceeds a preset time threshold, it is considered a faulty server. The application server that currently competes for the distributed lock will reassign all unconsumed agent IDs in the sub-queue corresponding to the faulty server to the sub-queues corresponding to other healthy application servers.

[0011] A second aspect of this application provides a softphone agent status synchronization device, the device comprising: The sign-in processing module is an application server that receives sign-in requests initiated by softphone clients and stores the agent ID in the sign-in request into the global agent queue in the Redis cluster. The task distribution module is used by the application server that has currently won the distributed lock to read the agent ID from the global agent queue and distribute the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to the preset balanced distribution strategy. After the distribution is completed, the distributed lock is released. The status synchronization module is used by each application server to read the corresponding agent ID from the corresponding sub-queue. The application server that currently competes for the agent ID-level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and update the agent's status data. After the update is completed, the agent ID-level lock is released. The checkout processing module is used by the application server that receives the checkout request initiated by the softphone client to remove the agent ID from the global agent queue.

[0012] Optionally, the lock key identifier of the distributed lock is a globally fixed key, the distributed lock is used to control the unique execution right of the distributed task, and the contention mode of the distributed lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the competition for the distributed lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the competition for the distributed lock.

[0013] Optionally, the lock key identifier of the employee ID-level lock corresponds one-to-one with the employee ID of the workstation. The employee ID-level lock is used to control the unique execution right of synchronizing the status of a single employee ID. The contention mode of the employee ID-level lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the employee ID level lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the employee ID level lock.

[0014] A third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the softphone agent status synchronization method provided in any implementation of the first aspect.

[0015] The fourth aspect of this application provides a processor for running a computer program that, when running, executes a softphone agent state synchronization method as provided in any implementation of the first aspect.

[0016] Compared with the prior art, this application has the following beneficial effects: This application provides a method for synchronizing the status of softphone agents. The method is applied to a softphone agent status synchronization system, which includes a Redis cluster and multiple application servers. The method includes: an application server receiving a check-in request from a softphone client stores the agent ID from the check-in request into a global agent queue in the Redis cluster; the application server currently holding a distributed lock reads the agent ID from the global agent queue and distributes it to the corresponding sub-queues of each application server in the Redis cluster according to a preset balanced distribution strategy, releasing the distributed lock after distribution; each application server reads the corresponding agent ID from its corresponding sub-queue; the application server currently holding an ID-level lock calls the underlying call handling capability interface to obtain the current call handling status of the corresponding agent and updates the agent's status data, releasing the ID-level lock after the update; and the application server receiving a check-out request from the softphone client removes the agent ID from the global agent queue.

[0017] In the above method, when an agent signs in, the application server stores the agent's ID in the global agent queue. After the agent's ID enters the global agent queue, the background asynchronously schedules and executes the status acquisition. The agent can perform subsequent business operations without waiting for the call interface to return, thus completely decoupling the agent sign-in operation from the status synchronization task. The agent's operation is no longer constrained by the high latency of the call interface, significantly improving the agent's user experience. At the same time, an innovative two-layer queue model of a global agent queue and server-specific sub-queues is built. The global agent queue is used to uniformly collect all signed-in agent IDs, realizing centralized management of agent IDs; the sub-queues corresponding to each application server are used to receive the agent ID tasks assigned to that node. Through this two-layer queue model, tasks can be accurately split and distributed according to service nodes, achieving balanced distribution of business traffic. This avoids the lock overhead and performance loss caused by multiple application servers competing for the same queue in an disorderly manner, and also lays the foundation for each server to consume independently without interference. Building upon this foundation, a multi-layered mutual exclusion control mechanism reduces invalid interface calls at the request source: each application server competes for a distributed lock to obtain the sole right to execute the task distribution, ensuring that only one application server can execute the task at any given time. Due to the mutual exclusion control of the distributed lock, the problem of multiple application servers simultaneously reading the same agent ID from the global agent queue and repeatedly distributing it to different sub-queues is fundamentally avoided. Each application server independently reads the agent ID from its corresponding sub-queue for state synchronization, ensuring that servers do not interfere with each other and effectively reducing lock contention overhead. When an agent checks out, the application server removes the agent ID from the global agent queue, officially terminating all state synchronization tasks associated with that agent, ensuring that there are no residual tasks for offline agents in the system, and simultaneously releasing the lock resources and queue storage resources associated with that agent to avoid resource waste. Attached Figure Description

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

[0019] Figure 1 A flowchart of a softphone agent status synchronization method provided in this application embodiment; Figure 2 This is a schematic diagram of a softphone agent status synchronization device provided in an embodiment of this application. Detailed Implementation

[0020] As described earlier, current underlying commercial call platform interfaces typically employ a fixed response mechanism. However, this mechanism has certain drawbacks: if the agent's call status remains unchanged, the interface must wait 10 seconds before returning response data. Continuously calling the interface to retrieve agent status under the traditional polling synchronization mode generates a large number of invalid requests without any state changes. Each invalid call triggers a 10-second waiting delay, directly causing a lag in the agent status update displayed on the softphone. Simultaneously, the massive number of duplicate invalid requests continuously consumes the underlying call platform interface resources, further exacerbating the status synchronization delay and resulting in inconsistencies between the displayed agent status and the actual working conditions, severely impacting the agent's user experience.

[0021] In view of the above problems, this application proposes a method for synchronizing the status of softphone agents and related products. The method is applied to a softphone agent status synchronization system, which includes a Redis cluster and multiple application servers. The method includes: an application server receiving a check-in request from a softphone client stores the agent ID in the check-in request into a global agent queue in the Redis cluster; the application server currently holding the distributed lock reads the agent ID from the global agent queue and distributes the agent ID to the corresponding sub-queues of each application server in the Redis cluster according to a preset balanced distribution strategy, and releases the distributed lock after distribution; each application server reads the corresponding agent ID from its corresponding sub-queue, and the application server currently holding the agent ID-level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and updates the agent's status data, and releases the agent ID-level lock after the update; the application server receiving the check-out request from the softphone client removes the agent ID from the global agent queue.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0023] See Figure 1 This figure is a flowchart of a softphone agent status synchronization method provided in an embodiment of this application. Figure 1 As shown, the method is applied to a softphone agent status synchronization system, which includes a Redis cluster and multiple application servers. The method includes the following steps: S101. The application server that receives the sign-in request initiated by the softphone client stores the agent ID in the sign-in request into the global agent queue in the Redis cluster.

[0024] The Redis cluster serves as a global shared storage and scheduling hub, internally maintaining a global agent queue and multiple sub-queues. The global agent queue is used to uniformly store the agent ID information of signed-in agents; each sub-queue corresponds one-to-one with an application server and is used to store the agent IDs assigned to that application server.

[0025] Each application server includes a producer module and a consumer module: the producer module is used to perform task distribution operations; the consumer module is used to perform state synchronization operations.

[0026] An agent initiates a sign-in request via a softphone client. This request is then distributed to any one of multiple application servers via a load balancer. The application server receiving the request stores the agent's ID in the global agent queue, thus bringing that agent under state synchronization management.

[0027] S102. The application server that currently wins the distributed lock reads the agent ID from the global agent queue and distributes the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to the preset balanced distribution strategy. After the distribution is completed, the distributed lock is released.

[0028] In one feasible implementation, the lock key identifier of the distributed lock is a globally fixed key, the distributed lock is used to control the unique execution right of the distributed task, and the contention mode of the distributed lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the competition for the distributed lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the competition for the distributed lock.

[0029] After distribution is complete, the application server sends a lock release command to the Redis cluster. The Redis cluster verifies that the unique identifier stored in the lock key matches the unique identifier in the release request, and then deletes the lock key, thus completing the release of the distributed lock.

[0030] When a new application server joins the system, the new application server automatically initializes its corresponding sub-queue. In the next distribution cycle, the new application server competes for the distributed lock and redistributes the agent IDs in the global agent queue according to the balanced distribution strategy, so that the sub-queue of the new application server obtains the corresponding agent ID.

[0031] When a new application server is added to the system, there is no need to stop existing services or restart any existing servers. The new server automatically initializes a sub-queue and participates in distributed lock contention, and will obtain a work order number in the next distribution cycle. Throughout the entire expansion process, the services of already signed-in work orders are not affected in any way, achieving truly seamless online expansion.

[0032] Through the aforementioned distributed lock mechanism, only one application server in the entire system can execute the distribution task at any given time, thus fundamentally avoiding the problem of multiple application servers simultaneously reading the same agent ID from the global agent queue and repeatedly distributing tasks to different sub-queues.

[0033] In one feasible implementation, the agent ID is distributed to the corresponding sub-queue of each application server in the Redis cluster according to a preset balanced distribution strategy, including: According to the preset weight or startup order of each application server, the agent IDs in the global agent queue are sequentially and cyclically distributed to the corresponding sub-queues of each application server in the Redis cluster.

[0034] By employing a round-robin distribution strategy, a balanced distribution of employee IDs across servers was achieved in a lightweight and efficient manner. Furthermore, it supports differentiated configurations in heterogeneous server scenarios, effectively improving cluster throughput and hardware resource utilization.

[0035] S103. Each application server reads the corresponding agent ID from the corresponding sub-queue. The application server that currently wins the agent ID-level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and updates the agent's status data. After the update is completed, the agent ID-level lock is released.

[0036] In one feasible implementation, the lock key identifier of the employee ID-level lock corresponds one-to-one with the employee ID of the workstation. The employee ID-level lock is used to control the unique execution right of synchronizing the status of a single employee ID. The contention method for the employee ID-level lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the employee ID level lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the employee ID level lock.

[0037] For example, the application server that wins the agent ID-level lock calls the underlying call service capability interface, sends an HTTP request carrying the agent ID to the underlying call service platform, receives the status code returned by the call service platform, parses the status code into an agent status enumeration value, including at least one of idle state, call state, ringing state, hold state and unavailable state, and updates the agent's status data.

[0038] After the agent status is updated, the application server sends a lock release command to the Redis cluster. The Redis cluster verifies that the unique identifier stored in the lock key matches the unique identifier in the release request, and then deletes the lock key, thus completing the release of the agent-level lock.

[0039] Through the aforementioned agent ID-level locking mechanism, the same agent ID is processed by only one application server at a time, fundamentally avoiding the problems of multiple servers repeatedly calling the underlying call interface, data competition, and inconsistent states. Furthermore, since the lock key of the agent ID-level lock is bound to the agent ID, state updates for different agent IDs can be performed in parallel without blocking each other, significantly improving the system's concurrent processing capabilities.

[0040] S104. The application server that receives the check-out request initiated by the softphone client removes the agent ID from the global agent queue.

[0041] The checkout request is distributed to any one of the multiple application servers via a load balancer, and the application server that receives the request performs the removal operation.

[0042] In one feasible implementation, the method further includes: Record the heartbeat signals sent by each application server to the Redis cluster at preset time intervals, and record the last heartbeat time; If the time interval between the last heartbeat time and the current time of any application server exceeds a preset time threshold, it is considered a faulty server. The application server that currently competes for the distributed lock will reassign all unconsumed agent IDs in the sub-queue corresponding to the faulty server to the sub-queues corresponding to other healthy application servers.

[0043] The heartbeat detection mechanism monitors the operating status of each application server in real time. Once a server failure is detected, an automatic recovery process is immediately triggered to migrate the unused agent IDs in the faulty server's sub-queue to the healthy server, ensuring that the agent status synchronization service is not interrupted.

[0044] This application provides a method for synchronizing the status of softphone agents. The method is applied to a softphone agent status synchronization system, which includes a Redis cluster and multiple application servers. The method includes: an application server receiving a check-in request from a softphone client stores the agent ID from the check-in request into a global agent queue in the Redis cluster; the application server currently holding a distributed lock reads the agent ID from the global agent queue and distributes it to the corresponding sub-queues of each application server in the Redis cluster according to a preset balanced distribution strategy, releasing the distributed lock after distribution; each application server reads the corresponding agent ID from its corresponding sub-queue; the application server currently holding an ID-level lock calls the underlying call handling capability interface to obtain the current call handling status of the corresponding agent and updates the agent's status data, releasing the ID-level lock after the update; and the application server receiving a check-out request from the softphone client removes the agent ID from the global agent queue.

[0045] In the above method, when an agent signs in, the application server stores the agent's ID in the global agent queue. After the agent's ID enters the global agent queue, the background asynchronously schedules and executes the status acquisition. The agent can perform subsequent business operations without waiting for the call interface to return, thus completely decoupling the agent sign-in operation from the status synchronization task. The agent's operation is no longer constrained by the high latency of the call interface, significantly improving the agent's user experience. At the same time, an innovative two-layer queue model of a global agent queue and server-specific sub-queues is built. The global agent queue is used to uniformly collect all signed-in agent IDs, realizing centralized management of agent IDs; the sub-queues corresponding to each application server are used to receive the agent ID tasks assigned to that node. Through this two-layer queue model, tasks can be accurately split and distributed according to service nodes, achieving balanced distribution of business traffic. This avoids the lock overhead and performance loss caused by multiple application servers competing for the same queue in an disorderly manner, and also lays the foundation for each server to consume independently without interference. Building upon this foundation, a multi-layered mutual exclusion control mechanism reduces invalid interface calls at the request source: each application server competes for a distributed lock to obtain the sole right to execute the task distribution, ensuring that only one application server can execute the task at any given time. Due to the mutual exclusion control of the distributed lock, the problem of multiple application servers simultaneously reading the same agent ID from the global agent queue and repeatedly distributing it to different sub-queues is fundamentally avoided. Each application server independently reads the agent ID from its corresponding sub-queue for state synchronization, ensuring that servers do not interfere with each other and effectively reducing lock contention overhead. When an agent checks out, the application server removes the agent ID from the global agent queue, officially terminating all state synchronization tasks associated with that agent, ensuring that there are no residual tasks for offline agents in the system, and simultaneously releasing the lock resources and queue storage resources associated with that agent to avoid resource waste.

[0046] Based on the softphone agent status synchronization method described in the preceding embodiments, this application also provides a softphone agent status synchronization device. Figure 2 This is a schematic diagram of the device. Figure 2 As shown, the softphone agent status synchronization device includes: The sign-in processing module 201 is an application server that receives a sign-in request initiated by a softphone client and stores the agent ID in the sign-in request into the global agent queue in the Redis cluster. The task distribution module 202 is used for the application server that currently competes for the distributed lock to read the agent ID from the global agent queue, and distribute the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to the preset balanced distribution strategy, and release the distributed lock after the distribution is completed. The status synchronization module 203 is used for each application server to read the corresponding agent ID from the corresponding sub-queue. The application server that currently competes for the agent ID level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and update the agent's status data. After the update is completed, the agent ID level lock is released. The checkout processing module 204 is used to remove the agent ID from the global agent queue when the application server receives the checkout request initiated by the softphone client.

[0047] Optionally, the lock key identifier of the distributed lock is a globally fixed key, the distributed lock is used to control the unique execution right of the distributed task, and the contention mode of the distributed lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the competition for the distributed lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the competition for the distributed lock.

[0048] Optionally, the lock key identifier of the employee ID-level lock corresponds one-to-one with the employee ID of the workstation. The employee ID-level lock is used to control the unique execution right of synchronizing the status of a single employee ID. The contention mode of the employee ID-level lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the employee ID level lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the employee ID level lock.

[0049] Optionally, the task distribution module is used to: According to the preset weight or startup order of each application server, the agent IDs in the global agent queue are sequentially and cyclically distributed to the corresponding sub-queues of each application server in the Redis cluster.

[0050] Optionally, the device further includes: a fault handling module; The fault handling module is used to record the heartbeat signals sent by each application server to the Redis cluster at preset time intervals, and to record the last heartbeat time. If the time interval between the last heartbeat time and the current time of any application server exceeds a preset time threshold, it is considered a faulty server. The application server that currently competes for the distributed lock will reassign all unconsumed agent IDs in the sub-queue corresponding to the faulty server to the sub-queues corresponding to other healthy application servers.

[0051] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the softphone agent status synchronization method as described in any of the method embodiments.

[0052] Furthermore, this application embodiment also provides a processor for running a computer program, which executes the softphone agent status synchronization method as described in any of the foregoing method embodiments.

[0053] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment solution according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0054] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for synchronizing the status of softphone agents, characterized in that, The method is applied to a softphone agent status synchronization system, the system including a Redis cluster and multiple application servers, and the method includes: The application server that receives the sign-in request from the softphone client stores the agent ID in the sign-in request into the global agent queue in the Redis cluster. The application server that currently wins the distributed lock reads the agent ID from the global agent queue and distributes the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to the preset balanced distribution strategy. After the distribution is completed, the distributed lock is released. Each application server reads the corresponding agent ID from the corresponding sub-queue. The application server that currently wins the agent ID-level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and updates the agent's status data. After the update is completed, the agent ID-level lock is released. The application server that receives the checkout request initiated by the softphone client removes the agent ID from the global agent queue.

2. The method according to claim 1, characterized in that, The distributed lock uses a globally fixed key as its key identifier. This distributed lock controls the unique execution right of distributed tasks. The contention methods for this distributed lock include: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the competition for the distributed lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the competition for the distributed lock.

3. The method according to claim 1, characterized in that, The lock key identifier of the employee ID-level lock corresponds one-to-one with the employee ID of the workstation. The employee ID-level lock is used to control the unique execution right of synchronizing the status of a single employee ID. The contention mode of the employee ID-level lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the employee ID level lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the employee ID level lock.

4. The method according to claim 1, characterized in that, The step of distributing the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to a preset balanced distribution strategy includes: According to the preset weight or startup order of each application server, the agent IDs in the global agent queue are sequentially and cyclically distributed to the corresponding sub-queues of each application server in the Redis cluster.

5. The method according to claim 1, characterized in that, The method further includes: Record the heartbeat signals sent by each application server to the Redis cluster at preset time intervals, and record the last heartbeat time; If the time interval between the last heartbeat time and the current time of any application server exceeds a preset time threshold, it is considered a faulty server. The application server that currently competes for the distributed lock will reassign all unconsumed agent IDs in the sub-queue corresponding to the faulty server to the sub-queues corresponding to other healthy application servers.

6. A softphone agent status synchronization device, characterized in that, include: The sign-in processing module is an application server that receives sign-in requests initiated by softphone clients and stores the agent ID in the sign-in request into the global agent queue in the Redis cluster. The task distribution module is used by the application server that has currently won the distributed lock to read the agent ID from the global agent queue and distribute the agent ID to the corresponding sub-queue of each application server in the Redis cluster according to the preset balanced distribution strategy. After the distribution is completed, the distributed lock is released. The status synchronization module is used by each application server to read the corresponding agent ID from the corresponding sub-queue. The application server that currently competes for the agent ID-level lock calls the underlying call service capability interface to obtain the current call service status of the corresponding agent and update the agent's status data. After the update is completed, the agent ID-level lock is released. The checkout processing module is used by the application server that receives the checkout request initiated by the softphone client to remove the agent ID from the global agent queue.

7. The apparatus according to claim 6, characterized in that, The distributed lock uses a globally fixed key as its key identifier. This distributed lock controls the unique execution right of distributed tasks. The contention methods for this distributed lock include: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the competition for the distributed lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the competition for the distributed lock.

8. The apparatus according to claim 6, characterized in that, The lock key identifier of the employee ID-level lock corresponds one-to-one with the employee ID of the workstation. The employee ID-level lock is used to control the unique execution right of synchronizing the status of a single employee ID. The contention mode of the employee ID-level lock includes: Each application server sends an atomic lock acquisition command to the Redis cluster, so that the Redis cluster can determine whether the lock key identifier corresponding to each atomic lock acquisition command has been occupied and return the determination result; If the judgment result is yes, then the lock key identifier has been occupied and the corresponding application server has not won the employee ID level lock; if the judgment result is no, then the lock key identifier has not been occupied and the corresponding application server has won the employee ID level lock.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the softphone agent status synchronization method as described in any one of claims 1-5.

10. A processor, characterized in that, Used to run a computer program, which, when running, executes the softphone agent status synchronization method as described in any one of claims 1-5.

Images