Live broadcast ordering processing method and device, equipment and medium

Abstract

The invention relates to a live broadcast ordering processing method and device, equipment and a medium in the field of network live broadcast, and the method comprises the steps: a node in a distributed cluster receives an audience ordering request and distributes the audience ordering request to a processing thread, and when the node and a plurality of opponent nodes are selected as a target node, the processing thread sends the processing thread to the node; calling a target thread to determine a request result and performing local storage and external caching respectively, and receiving audience ordering requests carrying the same information by each node; when the node is selected as a waiting node, calling a target thread to obtain a request result in an external cache and locally storing the request result; when the processing thread and the opponent threads are selected as target threads, the audience order placing requests are responded according to the obtained request result, and the audience order placing requests carrying the same information are distributed to all the threads; and when the processing thread competes as a waiting thread, responding to the audience ordering request by using a locally stored request result. Therefore, high-efficiency and low-consumption live broadcast room ordering service is realized.

Description

Technical Field

[0001] The present application relates to the field of online live broadcasting, and in particular to a live broadcast order processing method and corresponding devices, electronic devices, and computer-readable storage media. Background Art

[0002] In the context of social e-commerce, livestreaming has become a key sales model. Operators in livestream studios often employ a "shouting" strategy to urge viewers to place orders. Specifically, operators pre-set a series of product-related keywords. During the livestream, operators provide detailed information about the product's features and advantages, then inform viewers that they can place an order simply by sending the specified product-related keywords within the studio. It's worth noting that a single livestream studio may have hundreds of keywords, each corresponding to different product rules. Accurately matching viewer content and extracting the key information needed for ordering requires data processing and analysis, which is typically CPU-intensive. Furthermore, because these scenarios resemble "flash sales" in interface access, the instantaneous concurrency of orders is often high, placing extremely high demands on the system's processing power and stability.

[0003] Traditional technology typically matches each viewer's content individually. When there's a large volume of content (e.g., hundreds, thousands, or even more), the system needs to process a massive amount of data. This can lead to a sharp increase in CPU load, potentially exceeding the CPU's processing capacity, causing system lag or even crashes. Furthermore, completing these matches takes a long time, and some viewers may have to wait a long time for system feedback. This can make them impatient and even lead them to abandon their orders. This poor user experience significantly hinders the advancement of live streaming order-calling services.

[0004] In view of the shortcomings of traditional practices, the applicant has been engaged in research in related fields for a long time and has taken a different approach to solve the problems in the industry. Summary of the Invention

[0005] The primary purpose of this application is to solve at least one of the above problems and provide a live broadcast order processing method and corresponding devices, electronic equipment, and computer program products.

[0006] In order to meet the various objectives of this application, this application adopts the following technical solutions: A live streaming order processing method provided for one of the purposes of this application includes the following steps: The node in the distributed cluster receives audience order requests, assigns them to a processing thread, controls the processing thread and multiple opponent threads to compete, configures the only thread that succeeds in the competition as the target thread, and configures the remaining threads as dormant threads. The audience order requests assigned to each thread carry the same live broadcast room order information; The local node in the distributed cluster competes with multiple opponent nodes. The only node that succeeds in the election becomes the target node, and the remaining nodes become waiting nodes. When the local node is the target node, the target thread is called to determine the request result corresponding to the live broadcast room order information, and the request result is associated with the live broadcast room order information and stored in the local node database and external cache respectively. The viewer order requests received by each node carry the same live broadcast room order information; When the current node is the waiting node, the target thread is called to obtain the request result corresponding to the live broadcast room order information in the external cache, and the result is stored in the database of the current node. The request result is determined by the target node and stored in the external cache. When the processing thread is the target thread, calling the processing thread to respond to the viewer's order request with the obtained request result; When the processing thread is the dormant thread, the processing thread is awakened, and the processing thread is called to obtain the request result in the database of this node according to the live broadcast room order information to respond to the viewer's order request.

[0007] On the other hand, a live broadcast order processing device provided to meet one of the purposes of the present application includes a single-thread processing module, a single-node processing module, a result acquisition module, a first request response module and a second request response module, wherein the single-thread processing module is used for the current node in the distributed cluster to receive audience order requests, assign them to processing threads, control the processing threads and multiple opponent threads to compete, configure the only thread that successfully wins the election as the target thread, and configure the remaining threads as dormant threads, and the audience order requests assigned to each of the threads carry the same live broadcast room order information; the single-node processing module is used for the current node in the distributed cluster to compete with multiple opponent nodes, the only node that successfully wins the election becomes the target node, and the remaining nodes become waiting nodes. When the current node is the target node, the target thread is called to determine the request corresponding to the matching live broadcast room order information. The result of the request is requested, and the request result is associated with the live broadcast room order information and stored in the local node database and the external cache respectively. The audience order requests received by each node carry the same live broadcast room order information; the result retrieval module is used to call the target thread to obtain the request result corresponding to the live broadcast room order information in the external cache when the local node is the waiting node, and store it in the local node database. The request result is determined by the target node and stored in the external cache; the first request response module is used to call the processing thread to respond to the audience order request with the obtained request result when the processing thread is the target thread; the second request response module is used to wake up the processing thread when the processing thread is the dormant thread, and call the processing thread to obtain the request result in the local node database according to the live broadcast room order information to respond to the audience order request.

[0008] On the other hand, an electronic device provided to meet one of the purposes of the present application includes a central processing unit and a memory, and the central processing unit is used to call and run a computer program stored in the memory to execute the steps of the live broadcast order processing method described in the present application.

[0009] On the other hand, a computer program product provided to meet another purpose of the present application includes a computer program / instruction, which, when executed by a processor, implements the steps of the method described in any embodiment of the present application.

[0010] The technical solution of this application has many advantages, including but not limited to the following: This application first uses a node and thread election mechanism in a distributed cluster to ensure that, when processing multiple viewer order requests carrying the same live broadcast room order information, only one node calls its thread to handle the same live broadcast room order information, avoiding duplicate processing and wasted resources. This election mechanism greatly reduces the CPU load when processing a large number of requests, effectively preventing lag or crashes caused by excessive load, and significantly improving stability and reliability.

[0011] Secondly, by storing request results in an external cache and the local node database, rapid data sharing and access is achieved. When the local node is the target node, the processed request results are not only stored in the local database but also synchronized to the external cache, allowing other waiting nodes to quickly obtain the results and store them in the local database, thereby quickly responding to the viewer's order request. This data storage and shared synchronization mechanism significantly shortens the time viewers wait for feedback, improves the user experience, reduces the number of people abandoning orders due to excessive waiting times, and effectively promotes the smooth development of live order-calling services.

[0012] Furthermore, resource utilization is optimized by rationally allocating thread states (target and dormant threads) and coordinating threads across nodes. When the processing thread is the target thread, it directly responds to viewer order requests based on the request results, ensuring synchronous and timely processing. When the processing thread is dormant, it can quickly respond based on the request results in the node's database upon awakening. This flexible thread scheduling mechanism ensures efficient and orderly processing of viewer order requests, further improving processing capacity and response speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which: Figure 1 A schematic diagram of a typical network deployment architecture for implementing the technical solution of this application; Figure 2 This is a flowchart of a typical embodiment of the live broadcast order processing method of the present application; Figure 3 This is a principle block diagram of the live broadcast order processing device of this application; Figure 4 This is a schematic diagram of the structure of an electronic device used in this application. DETAILED DESCRIPTION

[0014] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and are not to be construed as limiting the present application.

[0015] It will be understood by those skilled in the art that, unless expressly stated otherwise, the singular forms "a", "an", "said" and "the" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. In addition, "connected" or "coupled" as used herein may include wireless connections or wireless couplings. The term "and / or" used herein includes all or any units and all combinations of one or more associated listed items.

[0016] Those skilled in the art will understand that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with their meanings in the context of the prior art and, unless specifically defined as such, will not be interpreted in an idealized or overly formal sense.

[0017] Those skilled in the art will appreciate that the terms "client," "terminal," and "terminal device" as used herein include both devices that are wireless signal receivers, i.e., devices that only have wireless signal receivers without transmission capabilities, and devices that have receiving and transmitting hardware capable of two-way communication over a two-way communication link. Such devices may include: cellular or other communication devices such as personal computers and tablet computers, which have single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service), which may combine voice, data processing, fax, and / or data communication capabilities; PDA (Personal Digital Assistant), which may include a radio frequency receiver, a pager, Internet / Intranet access, a web browser, a notepad, a calendar, and / or a GPS (Global Positioning System) receiver; and conventional laptop and / or palmtop computers or other devices, which have and / or include a radio frequency receiver. As used herein, "client," "terminal," or "terminal device" may be portable, transportable, installed in a vehicle (air, sea, and / or land), or adapted and / or configured to operate locally and / or in a distributed manner at any other location on Earth and / or in space. The terms "client," "terminal," or "terminal device" may also refer to a communication terminal, an Internet terminal, or a music / video playback terminal, such as a PDA, a mobile internet device (MID), and / or a mobile phone with music / video playback capabilities, as well as a smart TV, a set-top box, or other similar device.

[0018] The hardware referred to by names such as "server", "client", and "service node" in this application is essentially an electronic device with capabilities equivalent to those of a personal computer. It is a hardware device that has the necessary components revealed by the von Neumann principle, such as a central processing unit (including an arithmetic unit and a controller), a memory, an input device, and an output device. Computer programs are stored in its memory, and the central processing unit loads the program stored in the external memory into the internal memory for execution, executes the instructions in the program, and interacts with the input and output devices to complete specific functions.

[0019] It should be noted that the concept of "server" referred to in this application can also be extended to server clusters. Based on the network deployment principles understood by those skilled in the art, the servers described should be logically divided. In physical space, these servers can be independent of each other but callable through interfaces, or integrated into a single physical computer or a computer cluster. Those skilled in the art should understand this flexibility and should not use it to restrict the implementation of the network deployment method of this application.

[0020] See also Figure 1 The hardware infrastructure required for the implementation of the relevant technical solutions of this application can be deployed according to the architecture shown in the figure. The server 80 referred to in this application is deployed in the cloud. As a business server, it can be responsible for further connecting to relevant data servers and other servers that provide relevant support, thereby forming a logically related service cluster to provide services for relevant terminal devices such as the smartphone 81 and personal computer 82 shown in the figure, or a third-party server (not shown). The smartphone and personal computer can both access the Internet through well-known network access methods and establish a data communication link with the server 80 in the cloud to run terminal applications related to the services provided by the server.

[0021] For the server, the application is usually constructed as a service process, opening the corresponding program interface for remote calls by applications running on various terminal devices. The relevant technical solutions in this application that are suitable for running on the server can be implemented in the server in this way.

[0022] The application mentioned above refers to an application running on a server or terminal device. This application implements the relevant technical solutions of the present application in a programming manner. Its program code can be stored in a non-volatile storage medium that can be recognized by the computer in the form of computer-executable instructions, and can be loaded into the memory by the central processing unit for execution. The relevant device of the present application is constructed by the operation of this application on the computer.

[0023] For the server, the application is usually constructed as a service process, opening the corresponding program interface for remote calls by applications running on various terminal devices. The relevant technical solutions in this application that are suitable for running on the server can be implemented in the server in this way.

[0024] For various popular terminal devices nowadays, especially mobile devices such as tablets and mobile phones, they are usually equipped with built-in imaging devices such as cameras, or personal computers can also be externally connected to the said imaging devices. In theory, the application of the terminal device of this application can call the imaging devices in these cases.

[0025] The technical solution in this application suitable for implementation in terminal devices can also be programmed and built into an application that provides live broadcasting as part of its extended functions. The live broadcasting mentioned above refers to a live broadcast room network service implemented based on the aforementioned network deployment architecture.

[0026] The live broadcast room referred to in this application refers to a video chat room implemented by Internet technology, which usually has audio and video broadcast control functions, including anchor users and audience users. Audience users can include registered users who have registered on the platform, or unregistered visitor users; they can be registered users who follow anchor users, or registered or unregistered users who do not follow anchor users. Anchor users and audience users can interact through well-known online interactive methods such as voice, video, and text. Generally, anchor users perform programs for audience users in the form of audio and video streams, and economic transactions can also be generated during the interaction. Of course, the application form of live broadcast rooms is not limited to online entertainment, but can also be extended to other related scenarios, such as education and training scenarios, video conferencing scenarios, product promotion and sales scenarios, and any other scenarios that require similar interactions.

[0027] Unless expressly stated to be mutually exclusive, the various embodiments disclosed in this application may be cross-combined with the relevant technical features of the various embodiments to flexibly construct new embodiments, as long as such combination does not deviate from the creative spirit of this application and can meet the needs of the prior art or resolve certain deficiencies in the prior art. Those skilled in the art should be aware of such flexibility.

[0028] Those skilled in the art should be aware that although the various methods of this application are described based on the same concept and thus exhibit commonality, unless otherwise specified, these methods can be independently executed. Similarly, the various embodiments disclosed in this application are all based on the same inventive concept. Therefore, concepts with the same expression, as well as concepts that are appropriately transformed for convenience despite different expression, should be understood as equivalent.

[0029] See also Figure 2 In a typical embodiment of the present application, a live broadcast order processing method includes the following steps: Step S1100: The local node in the distributed cluster receives a viewer order request, assigns it to a processing thread, controls the processing thread and multiple opponent threads to compete, configures the only thread that successfully competes as the target thread, and configures the remaining threads as dormant threads. The viewer order requests assigned to each thread all carry the same live broadcast room order information. A distributed cluster consists of multiple server nodes connected by a high-speed network to jointly complete computing tasks or store data. Each node is an independent server with its own processor, memory, and storage. Nodes in a distributed cluster can be physical servers or virtual machines.

[0030] Audience users in the live broadcast room can participate in the live broadcast room's order-calling activities through a variety of information sending methods. The information sent is the participation interaction information. It can be understood that the audience user's intention in sending the participation interaction information is to place an order for a certain product marketed in the live broadcast room in the form of text description. These methods can be input in the bottom input box of the live broadcast room's playback interface, input in the barrage sending entrance of the playback interface, and so on. Therefore, when the audience user submits the participation interaction information in the live broadcast room's playback interface, it triggers the audience user's terminal to encapsulate the participation interaction information and the live broadcast room identifier corresponding to the live broadcast room into the live broadcast room order information, and generate an audience order request carrying the live broadcast room order information and send it to the distributed cluster.

[0031] When a distributed cluster receives a viewer order request, it can dispatch it to a single node based on various strategies to maintain cluster load balancing. Each node in the distributed cluster utilizes a process that allocates a thread to each viewer order request it receives. This thread then responds to the assigned viewer order request, effectively serving as a dedicated processing thread for that request. This node can be any server in the distributed cluster.

[0032] It is understood that this node can assign viewer order requests carrying the same live broadcast room order information received within a preset duration or at the same time to corresponding threads. These threads are the processing threads that respond to the received viewer order requests. However, since these processing threads need to participate in the competition, the other processing threads are rival threads relative to a single processing thread. The preset duration can be set as needed by those skilled in the art, for example, 1500ms.

[0033] In one embodiment, this node can create a campaign execution thread within the process. When any processing thread receives a viewer order request, this thread is called to generate a campaign identifier for that processing thread, which contains a timestamp and thread priority. The timestamp records the time when the thread began processing the request, and the priority is dynamically assigned based on the thread's load, with lower-load threads receiving higher priorities. The thread then sends the campaign identifier to a campaign queue, which is accessed by the campaign execution thread.

[0034] The load of a thread can be expressed as the execution time of the thread on the CPU. The longer the execution time, the higher the load. It can also be the historical execution time corresponding to the audience order request received by the thread. The higher the historical execution time, the higher the load. It can also be the estimated memory resources required by the thread during execution. The more memory resources, the higher the load. The load of the thread can be measured by at least one load indicator that can be visualized (for example, quantified) or a combination of various load indicators. Technical personnel in this field can express it as needed.

[0035] During the election process, the election execution thread periodically checks the election queue and compares the processing thread's election identifier with those of other rival threads according to pre-set rules. First, the timestamps are compared; the thread with the earliest timestamp wins. If the timestamps of all compared threads are the same, the thread with the higher priority wins. Once the winning thread is determined, the comparison ends. In this way, a single successful election thread is ultimately selected, the target thread. The target thread then continues processing viewer order requests, responding to them with the corresponding processing results and storing them in the local node database. Other unsuccessful threads are configured as dormant threads, entering a dormant state and waiting until the target thread completes processing and stores the results in the local node database. These dormant threads are then awakened, retrieve the processing results from the local node database, and respond to received viewer order requests. The local node database is a local database created and maintained by the node itself.

[0036] Step S1200: The local node and multiple opponent nodes in the distributed cluster compete for a spot, and the only node that succeeds in the competition becomes the target node, and the remaining nodes become waiting nodes. When the local node is the target node, the target thread is called to determine the request result corresponding to the live broadcast room order information, and the request result is associated with the live broadcast room order information and stored in the local node database and external cache respectively. The viewer order requests received by each node carry the same live broadcast room order information; In one embodiment, each node in a distributed cluster periodically (e.g., every 500ms) reports its health metrics to a cluster registration center (e.g., ZooKeeper or Etcd), including CPU utilization, remaining memory, network latency, and disk I / O throughput. The registration center maintains a health table storing the health metrics of each node. When any node in the distributed cluster receives a viewer order request, it sends a candidate application containing the live studio identifier to the registration center. Upon receiving the candidate application, the registration center filters out all active nodes (i.e., opponent nodes) currently processing the same live studio identifier. The registration center then performs a weighted sum operation based on at least one health metric of each node in the health table to determine a comprehensive health score for each node. If the node with the highest comprehensive health score receives a candidate success signal, it marks it as the target node; otherwise, it returns a candidate failure signal, marking it as a waiting node. After processing the viewer order request, the target node writes the request result to an external cache (e.g., Redis) and broadcasts a notification. Upon receiving the notification, each waiting node directly retrieves the request result from the external cache.

[0037] When the target node processes the audience's order request, the target node calls the target thread that has successfully won the election in its internal multi-threaded election, and obtains the minimum inventory unit list of the corresponding live broadcast room in the external database according to the live broadcast room identifier in the live broadcast room order information, and determines the sub-item matching results between each minimum inventory unit in the list and the participation interaction information in the live broadcast room order information. Based on each sub-item matching result, the request result for matching the live broadcast room order information is determined, and then the request result and the live broadcast room order information are associated and stored in the local database and external cache of the node respectively.

[0038] Step S1300: When the current node is the waiting node, the target thread is called to obtain the request result corresponding to the live broadcast room order information in the external cache, and the result is stored in the database of the current node. The request result is determined by the target node and stored in the external cache. Each waiting node can monitor in real time whether there is a request result in the external cache that matches the live broadcast room order information. If it exists, it means that the target node has stored the request result in the external cache. The waiting node calls the target thread that has successfully elected in its internal multi-threaded election, obtains the request result from the external cache, and stores it in the local database of the node.

[0039] Step S1400: When the processing thread is the target thread, calling the processing thread to respond to the viewer's order request with the obtained request result; After a series of selection processes and data processing, the target thread has successfully obtained a request result that matches the live broadcast room order information. At this point, the target thread directly returns the request result to the terminal of the viewer user who submitted the viewer order request, completing the processing of the viewer order request.

[0040] Step S1500: When the processing thread is the dormant thread, wake up the processing thread and call the processing thread to obtain the request result in the database of this node according to the live broadcast room order information to respond to the viewer's order request.

[0041] After the target thread completes the viewer order processing and stores the corresponding request result in the local node's database, the dormant thread is awakened by the local node. The dormant thread retrieves the corresponding request result from the local node's database using the result storage address obtained during its configuration. The result is then returned to the terminal of the viewer user who submitted the viewer order request, completing the processing of the viewer order request.

[0042] When all dormant threads are awakened, the node deletes the live streaming room order information from its database. During this process, dormant threads remain dormant while waiting, minimizing server resource usage. This mechanism effectively utilizes server resources, avoiding resource waste and data conflicts caused by multiple threads processing the same request simultaneously, while ensuring the system's high concurrency and data consistency.

[0043] It is not difficult to understand from the above embodiments that compared with the prior art, the present application has many advantages, including at least: This application first uses a node and thread election mechanism in a distributed cluster to ensure that, when processing multiple viewer order requests carrying the same live broadcast room order information, only one node calls its thread to handle the same live broadcast room order information, avoiding duplicate processing and wasted resources. This election mechanism greatly reduces the CPU load when processing a large number of requests, effectively preventing lag or crashes caused by excessive load, and significantly improving stability and reliability.

[0044] Secondly, by storing request results in an external cache and the local node database, rapid data sharing and access is achieved. When the local node is the target node, the processed request results are not only stored in the local database but also synchronized to the external cache, allowing other waiting nodes to quickly obtain the results and store them in the local database, thereby quickly responding to the viewer's order request. This data storage and shared synchronization mechanism significantly shortens the time viewers wait for feedback, improves the user experience, reduces the number of people abandoning orders due to excessive waiting times, and effectively promotes the smooth development of live order-calling services.

[0045] Furthermore, resource utilization is optimized by rationally allocating thread states (target and dormant threads) and coordinating threads across nodes. When the processing thread is the target thread, it directly responds to viewer order requests based on the request results, ensuring synchronous and timely processing. When the processing thread is dormant, it can quickly respond based on the request results in the node's database upon awakening. This flexible thread scheduling mechanism ensures efficient and orderly processing of viewer order requests, further improving processing capacity and response speed.

[0046] In a further embodiment, step S1100, controlling the processing thread to compete with multiple opponent threads, configuring the only thread that succeeds in the competition as the target thread, and configuring the remaining threads as dormant threads, includes the following steps: Step S1110: The calling processing thread and multiple opponent threads respectively obtain the thread scheduling lock in the local node; A local lock is created on this node as a thread scheduling lock, which is used within a single application instance to ensure that at least one thread can seize the thread scheduling lock at a time, thereby gaining access to shared resources on this node. This lock has low overhead, a very short preemption time, and minimal impact on the performance of this node.

[0047] Step S1120: When any of the threads seizes the thread scheduling lock, the thread queries the database of the node to see whether the live broadcast room order information carried by the viewer order request exists; This node can create and maintain a local mapping table in the local database to store the order information of different live broadcast rooms and their associated request results. The request result corresponds to the viewer order request corresponding to the live broadcast room order information.

[0048] At this time, the thread that seizes the thread scheduling lock has the right to query the local node database to confirm whether there is live broadcast room order information carried by the audience order request, in order to determine whether the request is a repeated request for the same live broadcast room order information.

[0049] Step S1130: When the thread queries the database of the local node and finds that the live broadcast room order information does not exist, the thread creates a new result storage address, associates the result storage address with the live broadcast room order information and stores it in the database of the local node, releases the thread scheduling lock, and uses the thread as the target thread. The result storage address is the address where the request result corresponding to the live broadcast room order information is stored in the database of the local node; At this point, the thread that has seized the thread scheduling lock creates a new result storage address, associates the result storage address with the live broadcast room order information, and stores it in the local node database. The thread scheduling lock is then released, and the thread is used as the target thread, completing the target thread configuration. It's easy to understand that this way, a unique thread is identified from multiple threads and configured as the target thread. Furthermore, since the thread scheduling lock has been released, it can be seized by other threads, allowing them to access the local node database for subsequent processes.

[0050] Step S1140: When the thread queries the database of the local node for the live broadcast room order information, the thread obtains the result storage address corresponding to the live broadcast room order information in the database of the local node, and sets the thread as a dormant thread, so that the dormant thread is in a dormant state waiting to be awakened, and after being awakened, obtains the request result pointed to by the result storage address in the database of the local node; At this time, it means that in the election between the processing thread and multiple opponent threads, only one thread has successfully been configured as the target thread, and the target thread has written the result storage address corresponding to the live broadcast room order information into the database of this node. Based on this, the thread that currently seizes the thread scheduling lock fails in the election. Based on the queried live broadcast room order information, the result storage address is obtained from the database of this node, and the node is used as a dormant thread.

[0051] Step S1150: After waking up each of the dormant threads, delete the live broadcast room order information in the database of this node.

[0052] It can be understood that after the target thread stores the request result of the determined matching live broadcast room order information into the result storage address associated with the live broadcast room order information, the node wakes up each dormant thread and then deletes the live broadcast room order information in the node database. This makes it so that the thread that seizes the thread scheduling lock after this can no longer obtain the result storage address in the node database based on the live broadcast room order information, and then obtain the request result pointed to by the result storage address. However, this does not affect the dormant thread's ability to obtain the request result pointed to by the result storage address that has been obtained during configuration. Such an implementation can ensure the timeliness and reliability of the request results.

[0053] In this embodiment, first, by grabbing the thread scheduling lock through multiple threads, it is ensured that only one thread can seize the lock and access the shared resources in this node at the same time, thereby avoiding resource conflicts and data inconsistencies caused by multiple threads processing the same request at the same time, greatly improving the stability of the system. Secondly, when any thread seizes the thread scheduling lock, it queries the database of this node to see whether the live broadcast room order information carried by the audience order request exists, and can quickly determine whether the request is a repeated request, thereby avoiding repeated processing of repeated requests and saving resources of this node. If the query result shows that the live broadcast room order information does not exist in the database of this node, the thread will create a new result storage address, and store the result storage address in association with the live broadcast room order information in the database of this node, and then release the thread scheduling lock, and use the thread as the target thread, which not only ensures the uniqueness of the target thread, but also allows other threads to continue to participate in the subsequent election process by releasing the thread scheduling lock, thereby improving the concurrent processing capability. On the other hand, if the query results show that the live broadcast room order information already exists in the local node database, the thread is treated as a dormant thread and placed in a dormant state waiting to be awakened. At the same time, after being awakened, it can quickly obtain the request result based on the storage address of the obtained result. This mechanism effectively reduces the thread's ineffective waiting time and improves the thread's response speed. Finally, after waking up each dormant thread, the live broadcast room order information in the local node database is deleted. This operation further ensures the timeliness and reliability of the request result and avoids the interference of outdated data on subsequent processing.

[0054] In a further embodiment, step S1200, in which the current node and multiple opponent nodes in the distributed cluster compete for a node, the only node that succeeds in the competition becomes the target node, and the remaining nodes become waiting nodes, includes the following steps: Step S1201: The local node and multiple opponent nodes in the distributed cluster respectively query the external cache for the first time whether there is a batch identifier corresponding to the live broadcast room order information, where the batch identifier is a unique feature identifier generated based on the live broadcast room order information; The external cache can be a Redis cluster, in which a batch information mapping table and a result identifier mapping table can be created and maintained. For the external cache, a result lock is configured for the result identifier mapping table and stored in the external cache, allowing the node that preemptively obtains the lock to access the table. In addition, a node scheduling lock is configured and stored in the external cache. The batch information mapping table is used to store the order information of each live broadcast room and its associated batch identifiers; the result identifier mapping table is used to store each batch identifier and its associated request results.

[0055] Step S1202: When the node queries the external cache for the first time and the batch identifier does not exist, the node obtains a node scheduling lock in the external cache; When the node queries the external cache for the first time based on the live broadcast room order information and finds that the corresponding batch identifier does not exist, it means that the live broadcast room order information has not yet been processed, and multiple nodes may obtain the batch identifier at the same time. Therefore, the node at this time obtains the node scheduling lock in the external cache, so that only one of the controlling node and each opponent node seizes the node scheduling lock, and the first node to seize the node scheduling lock generates the batch identifier once, and associates it with the live broadcast room order information and stores it in the external cache to avoid repeated generation.

[0056] Step S1203: When any of the nodes preemptively obtains the node scheduling lock, the node queries the external cache for a second time whether the batch identifier exists. If not, the node preemptively obtains the result read lock and becomes the target node. The node generates a corresponding batch identifier based on the live broadcast room order information, stores the live broadcast room order information associated with the batch identifier in the external cache, and releases the node scheduling lock. At this time, there are two situations: the first situation: the node that seizes the node scheduling lock is the first node to seize the lock; the second situation: the node that seizes the node scheduling lock is not the first node to seize the lock, but is seized after being released by the first node that seized the lock. Accordingly, when a node seizes the node scheduling lock, it is necessary for the node to further confirm whether the batch identifier exists or not in the external cache by a second query, and confirm whether the node is not or is the first node to seize the node scheduling lock. When the second query shows that the batch identifier does not exist, it belongs to the first situation, that is, the node is the first node to seize the node scheduling lock. Therefore, the node first obtains the result lock in the external cache. Since the only node currently obtains the lock, it is inevitable that the node seizes the lock. Subsequently, the node becomes the target node. The target node then calls the hash algorithm or UUID algorithm based on the live broadcast room order information to generate a corresponding unique identifier based on the live broadcast room identifier as the batch identifier, and associates the live broadcast room order information with the batch identifier and stores it in the batch information mapping table in the external cache.

[0057] Step S1204: When the node queries the external cache for the first or second time and the batch identifier exists, the node becomes a waiting node, obtains the batch identifier, and obtains the result lock in the external cache, so that the waiting node is in a waiting state before preempting the result lock, and after preempting the result lock, obtains the request result corresponding to the live broadcast room order information in the external cache according to the batch identifier.

[0058] Regardless of whether the node finds the batch identifier in the external cache for the first or second time, it means that the target node has already completed the generation and storage of the batch identifier. Therefore, the node becomes a waiting node and obtains the batch identifier from the external cache. It also has to obtain the result lock in the external cache. Since the waiting node cannot obtain the result lock before the target node releases it, it is relatively realized that the target node is the only node that processes the request result, and other nodes are waiting nodes waiting for the target node to produce the result.

[0059] In this embodiment, first, the node and multiple rival nodes each query the external cache for the presence of a batch identifier corresponding to the live broadcast room order information. This allows for a quick determination of whether the request has been processed, avoiding repeated processing of the same request and improving the system's processing efficiency and resource utilization. Secondly, when the node first queries the external cache and finds that the batch identifier does not exist, it acquires the node scheduling lock in the external cache, ensuring that only one node can generate the batch identifier and store it in the external cache. This avoids multiple nodes from repeatedly generating batch identifiers, further reducing resource waste and the possibility of data conflicts. Thirdly, after the node preemptively obtains the node scheduling lock, it performs a second query to determine whether the batch identifier exists in the external cache. If not, the node preemptively obtains the result read lock and becomes the target node. Based on the live broadcast room order information, it generates the corresponding batch identifier and stores it in the external cache. This process not only ensures the uniqueness and accuracy of the batch identifier, but also, by releasing the node scheduling lock, enables other nodes to promptly obtain the correct batch identifier, improving the system's response speed and data consistency. Finally, when a node queries the external cache for a batch identifier for the first or second time, the node becomes a waiting node and obtains the batch identifier and the result lock in the external cache. The waiting node is in a waiting state before preempting the result lock, ensuring that the target node is the only node that processes the request result. Other nodes wait for the target node to complete processing before obtaining the result. This mechanism effectively coordinates the processing order between nodes, avoids data competition and conflicts, and improves the stability and reliability of the system.

[0060] In a further embodiment, step S1200, when the current node is a target node, calling the target thread to determine the request result corresponding to the order information of the matching live broadcast room, and storing it in the current node database and the external cache respectively, includes the following steps: Step S1210: Call the target thread to obtain a minimum inventory unit list of the corresponding live broadcast room in an external database according to the live broadcast room identifier in the live broadcast room order information; The external database can be an external cache (for example, a Redis cluster) or an external persistent storage database (for example, a MySQL database). Since the Redis cluster is a cached database, it is necessary to synchronize the live broadcast product mapping table in the persistent storage database. The live broadcast product mapping table is used to store the identifiers of different live broadcast rooms and their associated minimum inventory units. The live broadcast room identifier is used to uniquely refer to a single live broadcast room, which is different from other live broadcast rooms, such as an ID, etc., which can be implemented as needed by those skilled in the art. The minimum inventory unit list includes multiple minimum inventory units, namely SKUs (stock-keeping units), corresponding to the marketing of different commodities in the corresponding live broadcast room.

[0061] This node calls the target thread to read the minimum inventory unit list of the corresponding live broadcast room in the external database according to the live broadcast room identifier in the live broadcast room order information.

[0062] Step S1220: The target thread creates a child thread pool, and based on the sub-item matching results between the corresponding minimum inventory unit and the participation interaction information in the live broadcast room order information, each child thread determines the request result for matching the live broadcast room order information. The child thread pool includes multiple child threads set for each minimum inventory unit in the minimum inventory unit list, including: Step S1221: The target thread selects at least one child thread from the child thread pool using a token queue and assigns a token to the child thread; This node calls the target thread to create multiple child threads for each minimum inventory unit in the minimum inventory unit list. These child threads constitute a child thread pool. Subsequently, a token queue and its corresponding at least one token are constructed, and then the token queue is called to select at least one child thread. Each token is assigned to each selected child thread, so that these child threads that obtain tokens can determine the sub-item matching results in parallel.

[0063] Step S1222: When the child thread obtains the token, the child thread obtains the preset reference text corresponding to the set minimum inventory unit, matches the preset reference text with the viewer order message in the live broadcast room order information, obtains a sub-item matching result and returns it to the target thread, and returns the token to the token queue; For each child thread that obtains a token, the child thread retrieves the corresponding preset reference text from the external database based on the set minimum stock keeping unit. The preset reference text includes at least one descriptive text pre-set by the operator of the live broadcast room based on the minimum stock keeping unit, or the minimum stock keeping unit and the quantity of the ordered product. For ease of understanding, an exemplary example is given: the minimum stock keeping unit is: "256G red mobile phone of a certain generation and brand"; the preset reference text is: "Mobile phone number one, A2, the first mobile phone in the shopping cart, 256G red mobile phone of a certain generation and brand"; "Mobile phone number one", "the first mobile phone in the shopping cart", and "256G red mobile phone of a certain generation and brand" all refer to "256G red mobile phone of a certain generation and brand"; "A2" refers to "256G red mobile phone of a certain generation and brand" and the order quantity is "two units".

[0064] In one embodiment, the sub-thread is used to determine whether the semantics of the audience order information in the live broadcast room order information is the same as the semantics of any descriptive text in the preset reference text, and generates at least one corresponding regular expression according to the preset reference text. For ease of understanding, further exemplary examples are given based on the previous example: each regular expression: "\b256G\s+red\s+\w+\s+\w+\s+mobile phone\b", "\b(number one mobile phone|first mobile phone in shopping cart|first mobile phone in shopping cart)\b", "\b(A2|a2)\b". Each regular expression is used to match the audience order information. If any regular expression is successfully matched, it is determined that the corresponding sub-item matching result is that the preset reference text matches the audience order information; otherwise, it is determined that the corresponding sub-item matching result is that the preset reference text does not match the audience order information.

[0065] In another embodiment, the sub-thread constructs a corresponding prompt text input into the large language model for the purpose of determining whether the semantics of the audience order information in the live broadcast room order information are the same as the semantics of any descriptive text in the preset reference text, and confirms whether the semantics are the same based on the large language model, and correspondingly determines whether the sub-item matching result is a match between the preset reference text and the audience order information. The large language model is suitable for text processing in the field of NLP. It is pre-trained to convergence using an extremely large corpus, and has the ability to generate human language and has a certain degree of accurate text semantic understanding and logical reasoning capabilities. The selection of this model includes Falcon, Chinchilla, PaLM, LLaMA 2, etc.

[0066] Step S1223: The target thread determines the minimum inventory unit that matches the viewer's order information as the request result based on the sub-item matching results corresponding to each minimum inventory unit in the minimum inventory list.

[0067] After receiving the sub-item matching results returned by each sub-thread, the target thread selects the smallest inventory unit that best matches the viewer's order information based on all the sub-item matching results as the request result.

[0068] Step S1230: The target thread stores the request result in the local node database according to the result storage address, and stores the request result associated with the batch identifier in the external cache based on the result lock and batch identifier, and releases the result lock. The result storage address is created by the local node calling the thread during the process of configuring the thread. The result lock and batch identifier are correspondingly obtained by the local node during the process of competing to become the target node and generated according to the live broadcast room order information. Since this node holds the result lock, it has the right to access the result identifier mapping table in the external cache, store the batch identifier associated with the request result in the external cache, and then release the result lock.

[0069] Step S1240: The target thread deletes the live broadcast room order information and its associated batch identifier in the external cache based on the live broadcast room order information.

[0070] This node calls the target thread to query the batch information mapping table in the external cache for the batch identifier corresponding to the live broadcast room order information, and deletes the live broadcast room order information and batch identifier in the batch information mapping table. It can be understood that since the batch identifier and its associated request result have been configured in the result identifier mapping table, the waiting node can still read the corresponding request result in the result identifier mapping table according to the batch identifier after preempting the result lock. In addition, the request result matching the live broadcast room order information needs to be reconfirmed after this. In this way, the timeliness and reliability of the request result are ensured.

[0071] In this embodiment, first, by calling the target thread to obtain the minimum inventory unit list of the corresponding live broadcast room in the external database according to the live broadcast room identifier in the live broadcast room order information, the product information related to the viewer's order request can be quickly and accurately located. It ensures that subsequent matching processing can be carried out based on accurate product data, laying the foundation for the subsequent efficient and accurate determination of request results, avoiding processing errors or resource waste caused by inaccurate product information, and improving the overall processing accuracy and stability. Secondly, the target thread creates a sub-thread pool, and determines the sub-item matching results based on the sub-threads, and then determines the request results, realizing multi-threaded parallel processing and significantly improving processing efficiency. The creation of the sub-thread pool enables the matching processing of each minimum inventory unit to be carried out in parallel, fully utilizing the computing power of the multi-core processor and significantly shortening the processing time. At the same time, the sub-thread tasks are reasonably allocated through the token queue, further optimizing the utilization efficiency of thread resources and avoiding thread competition and resource waste. In addition, the child thread uses regular expressions or large language models for semantic matching, which can flexibly and accurately handle the matching relationship between the audience's order information and the preset reference text, thereby improving the accuracy and adaptability of the match. Whether it is a simple text match or a complex semantic understanding scenario, it can effectively cope with it, further improving the intelligence level and user experience of the system. Furthermore, the target thread stores the request result in the local node database according to the result storage address, and stores the request result associated with the batch identifier in the external cache based on the result lock and batch identifier, and then releases the result lock to achieve rapid data sharing and access. Storing the request result in the local node database and the external cache at the same time enables the target node to quickly respond to the audience's order request, while providing other waiting nodes with a way to quickly obtain the request result. The use of the result lock ensures thread safety and data consistency when storing in the external cache, avoids data conflicts and errors caused by multiple nodes writing at the same time, and ensures the stability and reliability of the system. Finally, the target thread deletes the live broadcast room order information and its associated batch identifiers from the external cache based on the live broadcast room order information. This ensures the timeliness and reliability of the request results, avoids redundant and outdated data in the external cache, and enables subsequent requests matching the live broadcast room order information to be reconfirmed, ensuring processing accuracy and data freshness. This also optimizes the storage space of the external cache, improves cache utilization and access efficiency, and further enhances performance and scalability.

[0072] In a further embodiment, step S1300, when the current node is the waiting node, calling the target thread to obtain the request result corresponding to the live broadcast room order information in the external cache and storing it in the current node database includes the following steps: Step S1310: When the target thread is called to preemptively obtain the result lock in the external cache, the target thread obtains the request result associated with the batch identifier in the external cache, where the batch identifier is a unique feature identifier generated based on the live broadcast order information and obtained by the current node in the process of being elected as a waiting node; When this node is a waiting thread, when the target thread is called to preemptively obtain the result lock in the external cache, it means that it has the right to access the result identifier mapping table in the external cache. Therefore, the target thread reads the request result in the result identifier mapping table according to the batch identifier.

[0073] Step S1320: The target thread stores the request result in the local node database according to the result storage address, and the result storage address is created by the local node calling the thread during the process of configuring the thread.

[0074] Furthermore, the target thread stores the request result in the local node database based on the result storage address created previously, so that the subsequent dormant thread can obtain it.

[0075] In this embodiment, first, the request result is obtained by calling the target thread to seize the result lock in the external cache, thereby ensuring access control to the result data in a multi-node concurrent environment, avoiding data competition and conflict, and ensuring data consistency and integrity. Secondly, by utilizing the request results associated with the batch identifiers in the external cache, the waiting node can quickly and accurately obtain the required request results without repeating complex calculations and matching processes, greatly improving processing efficiency and reducing resource consumption. In addition, the obtained request results are stored in the database of this node, which facilitates the rapid awakening and response of subsequent dormant threads, further improving the response speed and user experience. This mechanism enables the waiting node to efficiently utilize the processing results of the target node, realizes the optimal configuration and collaborative work of resources in the distributed cluster, enhances the overall stability and reliability, and provides strong technical support for high-concurrency scenarios of live order processing.

[0076] In a further embodiment, step S1500, when the processing thread is the dormant thread, awakening the processing thread, calling the processing thread to obtain the request result in the local node database according to the live broadcast room order information to respond to the viewer order request, includes the following steps: Step S1510: Wake up the processing thread configured as the dormant thread, call the processing thread to obtain the corresponding request result in the node database according to the result storage address obtained during its configuration process; This node wakes up the processing thread configured as a dormant thread, calls the processing thread to read the result storage address corresponding to the live broadcast order information in the local mapping table based on the thread scheduling lock obtained by prior preemption, and obtains the requested result from the node database.

[0077] Step S1520: The processing thread responds to the viewer's order request with the request result.

[0078] The processing thread returns the request result to the terminal of the viewer user who submitted the viewer order request, completing the processing of the viewer order request.

[0079] In this embodiment, first, by waking up the processing thread configured as a dormant thread and calling the thread to obtain the corresponding request result in the node database according to the result storage address obtained during the configuration process, it can be ensured that after the target thread completes the processing, the dormant thread can quickly and accurately obtain the processing result. This mechanism avoids the unnecessary occupation of resources by the dormant thread during the waiting process, while ensuring the orderliness and efficiency of the processing. Secondly, the processing thread returns the request result directly to the terminal of the audience user, realizing a rapid response to the audience's order request, significantly shortening the time the audience waits for feedback, thereby greatly improving the user experience. This mechanism not only improves the overall processing capacity and response speed, but also reduces the possibility of the audience giving up the order due to too long waiting time, which effectively promotes the smooth development of the live broadcast order business and enhances the commercial value and market competitiveness.

[0080] See also Figure 3, a live broadcast order processing device provided to adapt to one of the purposes of the present application is a functional embodiment of the live broadcast order processing method of the present application. On the other hand, the device is a live broadcast order processing device provided to adapt to one of the purposes of the present application, including a single-thread processing module 1100, a single-node processing module 1200, a result acquisition module 1300, a first request response module 1400 and a second request response module 1500, wherein the single-thread processing module 1100 is used for the current node in the distributed cluster to receive audience order requests, assign them to processing threads, control the processing threads and multiple opponent threads to compete, configure the only thread that successfully wins the election as the target thread, and configure the remaining threads as dormant threads, and the audience order requests assigned to each thread carry the same live broadcast room order information; the single-node processing module 1200 is used for the current node in the distributed cluster to compete with multiple opponent nodes, the only node that successfully wins the election becomes the target node, and the remaining nodes become waiting nodes When this node is the target node, the target thread is called to determine the request result corresponding to the live broadcast room order information, and the request result is associated with the live broadcast room order information and stored in the local node database and the external cache respectively. The audience order requests received by each node carry the same live broadcast room order information; the result retrieval module is used to call the target thread to obtain the request result corresponding to the live broadcast room order information in the external cache when this node is the waiting node, and store it in the local node database. The request result is determined by the target node and stored in the external cache; the first request response module 1400 is used to call the processing thread to respond to the audience order request with the obtained request result when the processing thread is the target thread; the second request response module 1500 is used to wake up the processing thread when the processing thread is the dormant thread, and call the processing thread to obtain the request result in the local node database according to the live broadcast room order information to respond to the audience order request.

[0081] In a further embodiment, the single-thread processing module 1100 includes: a thread lock grabbing submodule, which is used to call the processing thread and multiple opponent threads to respectively obtain the thread scheduling lock in this node; a lock checking submodule, which is used for when any of the threads grabs the thread scheduling lock, the thread queries the database of this node whether there is the live broadcast room order information carried by the viewer order request; an address storage submodule, which is used for when the thread queries the database of this node and finds that the live broadcast room order information does not exist, the thread creates a new result storage address, associates the result storage address with the live broadcast room order information and stores it in the database of this node, releases the thread scheduling lock, and uses the thread as the target thread. The result storage address is the address in the database of this node where the request result corresponding to the live broadcast room order information is stored; a sleep configuration submodule is used for, when the thread queries the database of this node for the existence of the live broadcast room order information, the thread obtains the result storage address corresponding to the live broadcast room order information in the database of this node, and uses the thread as a sleep thread, so that the sleep thread is in a sleep state waiting to be awakened, and after being awakened, obtains the request result pointed to by the result storage address in the database of this node; an information deletion submodule is used for deleting the live broadcast room order information in the database of this node after waking up each of the sleep threads.

[0082] In a further embodiment, the single-node processing module 1200 includes: a batch identification query submodule, which is used for the current node and multiple opponent nodes in the distributed cluster to respectively query for the first time whether the batch identification corresponding to the live broadcast room order information exists in the external cache, and the batch identification is a unique feature identification generated according to the live broadcast order information; a scheduling lock preemption submodule, which is used to obtain the node scheduling lock in the external cache when the node queries the external cache for the first time and the batch identification does not exist; a scheduling lock release submodule, which is used for when any of the nodes preempts and obtains the node scheduling lock, the node queries for the second time whether the batch identification exists in the external cache. When it does not exist, the node seizes the result reading lock and becomes the target node, generates a corresponding batch identifier based on the live broadcast room order information, stores the batch identifier associated with the live broadcast room order information into the external cache, and releases the node scheduling lock; the result lock acquisition submodule is used to make the node become a waiting node and obtain the batch identifier and the result lock in the external cache when the node queries the external cache for the first or second time and the batch identifier exists, so that the waiting node is in a waiting state before seizing the result lock, and after seizing the result lock, obtains the request result corresponding to the live broadcast room order information in the external cache according to the batch identifier.

[0083] In a further embodiment, the single-node processing module 1200 includes: a list acquisition submodule, used to call the target thread to obtain a minimum inventory unit list of the corresponding live broadcast room in an external database according to the live broadcast room identifier in the live broadcast room order information; a result determination submodule, used to create a sub-thread pool by the target thread, and determine the request result of matching the live broadcast room order information based on the sub-item matching result between the corresponding minimum inventory unit and the participation interaction information in the live broadcast room order information determined by each sub-thread, and the sub-thread pool includes multiple sub-threads set for each minimum inventory unit in the corresponding minimum inventory unit list; The result lock release submodule is used for the target thread to store the request result into the local node database according to the result storage address, and based on the result lock and batch identifier, store the request result associated with the batch identifier into the external cache to release the result lock. The result storage address is created by the local node calling the thread in the process of configuring the thread. The result lock and batch identifier are correspondingly obtained by the local node in the process of competing to become the target node and generated according to the live broadcast room order information; the cache deletion submodule is used for the target thread to delete the live broadcast room order information and its associated batch identifier in the external cache according to the live broadcast room order information.

[0084] In a further embodiment, the result determination submodule includes: a token dispatching submodule, which is used by the target thread to select at least one subthread in the subthread pool using a token queue and assign a token to the subthread; a token returning submodule, which is used by the subthread to obtain the preset reference text corresponding to the set minimum inventory unit when the subthread obtains the token, match the preset reference text with the audience order message in the live broadcast room order information, obtain the sub-item matching result and return it to the target thread, and return the token to the token queue; a result determination submodule, which is used by the target thread to determine the minimum inventory unit matching the audience order information as the request result based on the sub-item matching results corresponding to each minimum inventory unit in the minimum inventory list.

[0085] In a further embodiment, the result waiting module includes: a target fruit retrieval module, which is used for the target thread to obtain the request result associated with the batch identifier in the external cache when calling the target thread to preemptively obtain the result lock in the external cache. The batch identifier is a unique feature identifier generated according to the live broadcast order information obtained by this node in the process of competing to become a waiting node; a result storage submodule, which is used for the target thread to store the request result into the local node database according to the result storage address. The result storage address is created by this node calling the thread in the process of configuring the thread.

[0086] In a further embodiment, the second request response module 1500 includes: a wake-up and fruit-retrieval module, which is used to wake up the processing thread configured as a dormant thread, call the processing thread according to the result storage address obtained during its configuration process, and obtain the corresponding request result in the node database; a request response sub-module, which is used for the processing thread to respond to the audience's order request with the request result.

[0087] In order to solve the above technical problems, the present application also provides an electronic device. Figure 4 As shown, a schematic diagram of the internal structure of an electronic device. The electronic device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. Among them, the computer-readable storage medium of the electronic device stores an operating system, a database, and computer-readable instructions, and the database may store a control information sequence, and when the computer-readable instructions are executed by the processor, the processor can implement the live broadcast order processing method. The processor of the electronic device is used to provide computing and control capabilities to support the operation of the entire electronic device. The memory of the electronic device may store computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor can execute the live broadcast order processing method described in this application. The network interface of the electronic device is used to connect and communicate with the terminal. Those skilled in the art will understand that, Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the electronic device to which the solution of the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0088] In this execution mode, the processor is used to execute Figure 3 The memory stores the program code and various data required to execute the modules and submodules in the live broadcast order processing device. The network interface is used to transmit data between user terminals or servers. The memory in this implementation mode stores the program code and data required to execute all modules / submodules in the live broadcast order processing device of this application. The server can call the server's program code and data to execute the functions of all submodules.

[0089] The present application also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the method of any embodiment of the present application.

[0090] Those skilled in the art will appreciate that all or part of the processes in the above-described embodiments of the present application can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes in the above-described embodiments of the method. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0091] To sum up, this application realizes an efficient and low-cost live broadcast room ordering service.

[0092] Those skilled in the art will understand that the various operations, methods, steps, measures, and schemes in the processes discussed in this application may be interchanged, changed, combined, or deleted. Furthermore, other steps, measures, and schemes in the various operations, methods, and processes discussed in this application may also be interchanged, changed, rearranged, decomposed, combined, or deleted. Furthermore, the steps, measures, and schemes in the various operations, methods, and processes in the prior art that are open source and disclosed in this application may also be interchanged, changed, rearranged, decomposed, combined, or deleted.

[0093] The above is only part of the implementation of this application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of this application. These improvements and modifications should also be regarded as the scope of protection of this application.

Claims

1. A live broadcast order processing method, characterized in that: The steps include: The node in the distributed cluster receives audience order requests, assigns them to a processing thread, controls the processing thread and multiple opponent threads to compete, configures the only thread that succeeds in the competition as the target thread, and configures the remaining threads as dormant threads. The audience order requests assigned to each thread carry the same live broadcast room order information; The local node in the distributed cluster competes with multiple opponent nodes. The only node that succeeds in the election becomes the target node, and the remaining nodes become waiting nodes. When the local node is the target node, the target thread is called to determine the request result corresponding to the live broadcast room order information, and the request result is associated with the live broadcast room order information and stored in the local node database and external cache respectively. The viewer order requests received by each node carry the same live broadcast room order information; When the current node is the waiting node, the target thread is called to obtain the request result corresponding to the live broadcast room order information in the external cache, and the result is stored in the database of the current node. The request result is determined by the target node and stored in the external cache. When the processing thread is the target thread, calling the processing thread to respond to the viewer's order request with the obtained request result; When the processing thread is the dormant thread, the processing thread is awakened, and the processing thread is called to obtain the request result in the database of this node according to the live broadcast room order information to respond to the viewer's order request.

2. The live broadcast order processing method according to claim 1, characterized in that: The control processing thread and multiple opponent threads compete for election, and the only thread that succeeds in the election is configured as the target thread, and the remaining threads are configured as dormant threads, including the following steps: The calling processing thread and multiple opponent threads respectively obtain the thread scheduling lock in this node; When any of the threads seizes the thread scheduling lock, the thread queries the database of the node whether there is the live broadcast room order information carried by the viewer order request; When the thread queries the database of this node and finds that the live broadcast room order information does not exist, the thread creates a new result storage address, associates the result storage address with the live broadcast room order information and stores it in the database of this node, releases the thread scheduling lock, and uses the thread as the target thread. The result storage address is the address where the request result corresponding to the live broadcast room order information is stored in the database of this node; When the thread queries the database of the local node for the live broadcast room order information, the thread obtains the result storage address corresponding to the live broadcast room order information in the database of the local node, and uses the thread as a dormant thread, so that the dormant thread is in a dormant state waiting to be awakened, and after being awakened, obtains the request result pointed to by the result storage address in the database of the local node; After each of the dormant threads is awakened, the live broadcast room order information in the local node database is deleted.

3. The live broadcast order processing method according to claim 1, characterized in that: The local node in the distributed cluster competes with multiple opponent nodes. The only node that succeeds in the election becomes the target node, and the remaining nodes become waiting nodes. The process includes the following steps: The local node and multiple opponent nodes in the distributed cluster respectively query for the first time whether there is a batch identifier corresponding to the live broadcast room order information in the external cache, where the batch identifier is a unique feature identifier generated according to the live broadcast room order information; When the node queries the external cache for the first time and finds that the batch identifier does not exist, acquiring a node scheduling lock in the external cache; When any of the nodes seizes and obtains the node scheduling lock, the node queries the external cache for the second time whether the batch identifier exists. If not, the node seizes and obtains the result read lock and becomes the target node. It generates a corresponding batch identifier based on the live broadcast room order information, stores the live broadcast room order information associated with the batch identifier in the external cache, and releases the node scheduling lock; When the node queries the external cache for the first or second time and finds the batch identifier, the node becomes a waiting node, obtains the batch identifier, and obtains the result lock in the external cache, so that the waiting node is in a waiting state before preemptively obtaining the result lock, and after preemptively obtaining the result lock, obtains the request result corresponding to the live broadcast room order information in the external cache according to the batch identifier.

4. The live broadcast order processing method according to claim 1, characterized in that: When the current node is the target node, the target thread is called to determine the request result corresponding to the order information of the matching live broadcast room, and the result is stored in the local node database and the external cache respectively, including the following steps: Calling the target thread to obtain a minimum inventory unit list of the corresponding live broadcast room in an external database according to the live broadcast room identifier in the live broadcast room order information; The target thread creates a child thread pool, and based on each child thread determining a sub-item matching result between a corresponding minimum inventory unit and the interaction information in the live broadcast room order information, determines a request result for matching the live broadcast room order information, wherein the child thread pool includes a plurality of child threads set corresponding to each minimum inventory unit in the minimum inventory unit list; The target thread stores the request result in the local node database according to the result storage address, and stores the request result associated with the batch identifier in the external cache based on the result lock and batch identifier, and releases the result lock. The result storage address is created by the local node calling the thread during the process of configuring the thread. The result lock and batch identifier are correspondingly obtained by the local node in the process of competing to become the target node and generated according to the live broadcast room order information; The target thread deletes the live broadcast room order information and its associated batch identifier in the external cache based on the live broadcast room order information.

5. The live broadcast order processing method according to claim 4, characterized in that: Based on the sub-item matching results between the corresponding minimum inventory unit and the participation interaction information in the live broadcast room order information determined by each sub-thread, a request result for matching the live broadcast room order information is determined, including the following steps: The target thread selects at least one child thread from the child thread pool using a token queue and assigns a token to the child thread; When the child thread obtains the token, the child thread obtains the preset reference text corresponding to the set minimum inventory unit, matches the preset reference text with the viewer order message in the live broadcast room order information, obtains the sub-item matching result and returns it to the target thread, and returns the token to the token queue; The target thread determines the minimum inventory unit that matches the viewer's order information as the request result based on the sub-item matching results corresponding to each minimum inventory unit in the minimum inventory list.

6. The live broadcast order processing method according to claim 1, characterized in that: When the current node is the waiting node, the target thread is called to obtain the request result corresponding to the live broadcast room order information in the external cache and store it in the database of the current node, including the following steps: When the target thread is called to preemptively obtain the result lock in the external cache, the target thread obtains the request result associated with the batch identifier in the external cache, where the batch identifier is a unique feature identifier generated based on the live broadcast order information and obtained by the node in the process of competing to become a waiting node; The target thread stores the request result in the local node database according to the result storage address, and the result storage address is created by calling the thread in the process of configuring the thread.

7. The live broadcast order processing method according to claim 1, characterized in that: When the processing thread is the dormant thread, the processing thread is awakened, and the processing thread is called to obtain the request result in the local node database according to the live broadcast room order information to respond to the viewer order request, including the following steps: Waking up the processing thread configured as a dormant thread, calling the processing thread to obtain the corresponding request result in the node database according to the result storage address obtained during its configuration process; The processing thread responds to the viewer's order request with the request result.

8. A live broadcast order processing device, characterized in that: It includes: A single-thread processing module is used to receive viewer order requests from this node in the distributed cluster, assign them to a processing thread, control the processing thread and multiple opponent threads to compete, configure the only thread that successfully competes as the target thread, and configure the remaining threads as dormant threads. The viewer order requests assigned to each thread all carry the same live broadcast room order information; A single-node processing module is used for the local node in the distributed cluster to compete with multiple opponent nodes. The only node that succeeds in the election becomes the target node, and the remaining nodes become waiting nodes. When the local node is the target node, the target thread is called to determine the request result corresponding to the live broadcast room order information, and the request result is associated with the live broadcast room order information and stored in the local node database and external cache respectively. The viewer order requests received by each node carry the same live broadcast room order information; A result retrieval module is used to call the target thread to obtain the request result corresponding to the live broadcast room order information in the external cache when the current node is the waiting node, and store it in the local node database. The request result is determined by the target node and stored in the external cache; A first request response module is configured to, when the processing thread is the target thread, call the processing thread to respond to the viewer's order request with the obtained request result; The second request response module is used to wake up the processing thread when the processing thread is the dormant thread, and call the processing thread to obtain the request result in the database of this node according to the live broadcast room order information to respond to the viewer's order request.

9. An electronic device comprising a central processing unit and a memory, characterized in that: The central processing unit is configured to call and run a computer program stored in the memory to execute the steps of the method according to any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that: It stores a computer program implemented according to the method described in any one of claims 1 to 7 in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the corresponding method are executed.

Images