Live data scheduling, access method and its device, equipment, medium and product

Abstract

The present application discloses a method for scheduling and accessing live broadcast data and its apparatus, equipment, medium, and product. The scheduling method includes: calling a regression prediction model to obtain the anchor identifier corresponding to the anchor client that is online in the current time period in the live broadcast platform predicted by the model; querying the live broadcast data corresponding to the anchor identifier stored in the hierarchical database, determining the live broadcast data as hot spot data and floating it to the storage medium with the highest performance level in the hierarchical database for storage, and the data in the hierarchical database is dispersedly stored in multiple storage media with different performance levels; responding to a data acquisition event pushed by a live broadcast service server, querying the live broadcast data corresponding to the event in each storage medium according to the performance level from high to low, and pushing the live broadcast data. The present application effectively improves the transmission efficiency of live broadcast data by storing the source live broadcast data in a hierarchical manner and floating the predicted hot spot data to a high-performance storage medium.

Description

Technical Field

[0001] The present application relates to the technical field of network live broadcast data scheduling, and in particular to a live broadcast data scheduling and access method, and also to corresponding devices, equipment, non-volatile storage media and computer program products of the method. Background Art

[0002] In the live broadcast data transmission system of existing live broadcast platforms, the live broadcast data of the anchor users on the platform are generally distributed and stored in a cluster of storage business servers, so that the business servers can obtain the live broadcast data and provide live online services to the anchor users (anchor clients). In order to ensure the consistency of the live broadcast data stored in each business server in the cluster, the platform generally uses redis cache technology and uses the business servers in the cluster as redis nodes to increase the speed at which each business server obtains the live broadcast data. However, due to the bandwidth limitations of the redis cache, a bottleneck is caused in the transmission of live broadcast data, and the number of requests on the live broadcast platform is often in a highly concurrent state. Therefore, using redis technology to increase the data transmission speed is not ideal in the actual business use of live broadcasts, and it cannot adapt to the situation of high concurrent requests. In addition, using redis technology to use each business server in the cluster as a redis node has too high a construction cost. In summary, using redis technology to transmit live data will still cause the entire live broadcast data transmission system to be busy and have low availability.

[0003] In response to the above-mentioned problems, the applicant has made corresponding explorations in order to solve the problems. Summary of the Invention

[0004] The purpose of this application is to provide a live broadcast data scheduling and access method to meet user needs. In addition, it also relates to corresponding devices, equipment, non-volatile storage media and computer program products of this method.

[0005] In order to achieve the purpose of this application, the following technical solutions are adopted:

[0006] A live broadcast data scheduling method proposed to achieve the primary purpose of this application includes the following steps:

[0007] Call the regression prediction model to obtain the anchor ID corresponding to the anchor client that is online in the current time period on the live broadcast platform predicted by the model;

[0008] querying the live broadcast data corresponding to the anchor identifier stored in the hierarchical database, determining the live broadcast data as hot data and floating it to the storage medium with the highest performance level of the hierarchical database for storage, wherein the data of the hierarchical database is dispersedly stored in multiple storage media with different performance levels;

[0009] In response to a data acquisition event pushed by a live broadcast service server, live broadcast data corresponding to the event is searched in each storage medium according to performance level from high to low, and the live broadcast data is pushed to the live broadcast service server for data update.

[0010] In a further embodiment, the step of calling the regression prediction model includes the following steps performed by the regression prediction model:

[0011] Obtaining online time information corresponding to multiple anchor clients in the live broadcast platform;

[0012] The online time information and the corresponding anchor client's anchor ID are stored as mapping relationship data in the anchor online time list;

[0013] Obtain the current time period information, query the host online time list for one or more online time information corresponding to the current time period information, and obtain the host identifiers corresponding to the online time information;

[0014] Generate an anchor identification set including the anchor identifications, and output the anchor identification set.

[0015] In a further embodiment, the step of responding to the data acquisition event pushed by the live broadcast service server further includes the following steps:

[0016] In response to the data acquisition event, determining the live broadcast data pointed to by the event;

[0017] According to the performance levels corresponding to the plurality of storage media, the live broadcast data is searched in the storage media in descending order;

[0018] The live broadcast data is obtained from a storage medium storing the live broadcast data, and the live broadcast data is pushed to the live broadcast service server for data update.

[0019] In a further embodiment, the data of the hierarchical database is distributed and stored in a high-performance storage medium, a medium-performance storage medium, and a low-performance storage medium, wherein the high-performance storage medium is the running memory of the device.

[0020] A live broadcast data scheduling device proposed for the purpose of this application includes:

[0021] The anchor ID prediction module is used to call the regression prediction model to obtain the anchor ID corresponding to the anchor client online in the current time period on the live broadcast platform predicted by the model;

[0022] a live broadcast data uploading module, configured to query the live broadcast data corresponding to the anchor identifier stored in the hierarchical database, determine the live broadcast data as hot data, and upload it to the storage medium with the highest performance level in the hierarchical database for storage. The data in the hierarchical database is dispersedly stored in multiple storage media with different performance levels;

[0023] The acquisition event response module is used to respond to the data acquisition event pushed by the live broadcast service server, query the live broadcast data corresponding to the event in each storage medium according to the performance level from high to low, and push the live broadcast data to the live broadcast service server for data update.

[0024] In a further embodiment, the anchor identification prediction module includes:

[0025] The online time acquisition submodule is used to obtain the online time information corresponding to multiple anchor clients in the live broadcast platform;

[0026] The relational data storage submodule is used to store the online time information and the corresponding anchor ID of the anchor client as mapping relationship data in the anchor online time list;

[0027] The anchor identification acquisition submodule is used to obtain the current time period information, query the anchor online time list for one or more online time information corresponding to the current time period information, and obtain the anchor identification corresponding to the online time information;

[0028] The identification set output submodule is used to generate an anchor identification set including these anchor identifications and output the anchor identification set.

[0029] In a further embodiment, the acquiring event response module includes:

[0030] A live data determination submodule, configured to respond to the data acquisition event and determine the live data pointed to by the event;

[0031] A live data query submodule, configured to query the live data in the storage media in descending order according to the performance levels corresponding to the respective storage media;

[0032] The live broadcast data push submodule is used to obtain the live broadcast data from the storage medium storing the live broadcast data, and push the live broadcast data to the live broadcast service server for data update.

[0033] A live broadcast data access method proposed to meet another purpose of the present application includes the following steps:

[0034] Responding to a data increment query event acting on a live broadcast database, and broadcasting the data increment query event to all live broadcast service servers in the live broadcast service server cluster where the current live broadcast service server is located, the live broadcast database being used to store live broadcast data;

[0035] Pushing a data acquisition event to a source data server to drive the source data server to query the storage media for live data corresponding to the data acquisition event according to the performance levels of the storage media where the hierarchical database is located, from high to low;

[0036] The live broadcast data is acquired from a hierarchical database of a source data server, and the live broadcast data is stored in a live broadcast database.

[0037] In a further embodiment, before the step of responding to the data increment query event acting on the live broadcast database, the following steps are also included:

[0038] Respond to the anchor start event and determine the anchor client to which the anchor start event points;

[0039] The anchor identifier corresponding to the anchor client is determined to generate the data increment query event for storing the live broadcast data corresponding to the anchor identifier in the live broadcast database.

[0040] In a further embodiment, after the step of correspondingly updating the live broadcast data pre-stored in the own database, the following steps are also included:

[0041] Respond to high-load events on the source data server and push data synchronization events to other live service servers;

[0042] In response to data acquisition events of other live broadcast service servers, the incremental live broadcast data obtained from the hierarchical database of the source data server is pushed to other live broadcast service servers for synchronous update.

[0043] In a further embodiment, the data of the hierarchical database is distributed and stored in a high-performance storage medium, a medium-performance storage medium, and a low-performance storage medium, wherein the high-performance storage medium is the running memory of the device.

[0044] A live data access device proposed for the purpose of this application includes:

[0045] An incremental event response module, configured to respond to a data incremental query event acting on a live broadcast database, and broadcast the data incremental query event to all live broadcast service servers in the live broadcast service server cluster where the current live broadcast service server is located. The live broadcast database is used to store live broadcast data.

[0046] An acquisition event push module is used to push a data acquisition event to a source data server, so as to drive the source data server to query the storage media for the live data corresponding to the data acquisition event according to the performance level of each storage medium where the hierarchical database is located, from high to low;

[0047] The live broadcast data acquisition module is used to acquire the live broadcast data from the hierarchical database of the source data server and store the live broadcast data in the live broadcast database.

[0048] In order to solve the above technical problems, an embodiment of the present application also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor executes the steps of the above-mentioned live data scheduling method or live data access method.

[0049] In order to solve the above technical problems, an embodiment of 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 above-mentioned live data scheduling method or live data access method.

[0050] In order to solve the above technical problems, an embodiment of the present application also provides a computer program product, including a computer program and computer instructions. When the computer program and computer instructions are executed by a processor, the processor executes the steps of the above-mentioned live data scheduling method or live data access method.

[0051] Compared with the prior art, the advantages of this application are as follows:

[0052] This application constructs a hierarchical storage structure for live broadcast data in a source data server based on hierarchical storage technology, builds a hierarchical database for storing live broadcast data, and combines a regression prediction model to predict hot spot data, so as to float the hot spot data and store it in the highest performance storage medium of the hierarchical database to improve the writing and writing speed of hot spot data. Compared with the existing technology based on redis technology for data transmission, the live broadcast data management system constructed by hierarchical storage has a higher degree of integration with the live broadcast business. Further, through the role of the regression prediction model, it can effectively respond to the high-concurrency requests commonly seen in live broadcast business scenarios, so that the live broadcast data management system can effectively improve the data query speed while also improving the overall high availability, robustness and tolerance of the system.

[0053] Secondly, the regression prediction model of this application can predict the anchor clients that are online in the current time period, and store the live broadcast data of these anchor clients as hot data in the high-performance storage medium of the hierarchical database, thereby improving the smoothness of the live broadcast business of the anchor client and ensuring the immediacy of the data of the anchor client.

[0054] In addition, the live broadcast service server composed of the live broadcast service server of the present application only needs to obtain the live broadcast data of the online anchor client from the source data server for storage. It is based on incremental query technology and can effectively reduce the data transmission pressure of the source data server compared to traditional full data replication.

[0055] Furthermore, the live broadcast service server of the present application can serve the source data server, which is responsible for pushing the live broadcast data obtained from the source data server to other live broadcast service servers in the corresponding cluster, so as to share the data push service in the live broadcast data system, reduce the data transmission pressure of the source data server, and improve the overall stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] 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:

[0057] Figure 1 A schematic diagram of a typical network deployment architecture for implementing the technical solution of this application;

[0058] Figure 2 This is a flowchart of a typical embodiment of the live broadcast data scheduling method of the present application;

[0059] Figure 3 This is a flow chart of the specific implementation method of the regression prediction model of this application when predicting the live broadcast identifier, which is Figure 2 Specific implementation of step S11;

[0060] Figure 4 This is a flow chart of the specific implementation method executed when the source data server of this application responds to data to obtain data, which is Figure 2 Specific implementation of step S12;

[0061] Figure 5 This is a principle block diagram of a typical embodiment of the live broadcast data scheduling device of the present application;

[0062] Figure 6 A flowchart of a typical embodiment of the live broadcast data access method of the present application;

[0063] Figure 7 This is a flow chart of the pre-steps of the live data access method of this application. Figure 6 Executed before step S22;

[0064] Figure 8 This is a flow chart of the post-processing steps of the live data access method of this application, which is Figure 6Executed after step S24;

[0065] Figure 9 This is a principle block diagram of a typical embodiment of the live data access device of the present application;

[0066] Figure 10 This is a basic structural block diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0067] 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.

[0068] 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.

[0069] It will be understood by those skilled in the art 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 will not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0070] It will be understood by those skilled in the art 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, the terms "client," "terminal," or "terminal device" may be portable, transportable, or installed in a vehicle (air, sea, and / or land), or may be adapted and / or configured to operate locally and / or in a distributed manner at any other location on Earth and / or in space. As used herein, 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, an MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities, or may include a smart TV, a set-top box, or other device.

[0071] 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.

[0072] 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 constrain the implementation of the network deployment method of this application.

[0073] See also Figure 1 , the hardware foundation 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 relevant data servers and other servers that provide relevant support, etc., to form 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 a well-known network access method 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] See also Figure 2 In a typical embodiment of the present invention, a live broadcast data scheduling method includes the following steps:

[0082] Step S11: Call the regression prediction model to obtain the anchor identifier corresponding to the anchor client that is online in the current time period on the live broadcast platform predicted by the model:

[0083] The source data server calls the regression prediction model to predict one or more anchor clients online in the current time period on the live broadcast platform through the regression prediction model, and obtains the anchor identifiers corresponding to each of the anchor clients predicted and determined by the regression prediction model.

[0084] The source data server is mainly responsible for the hierarchical management of live broadcast data and providing data push services to the live broadcast business servers associated with it. The source data server uniformly manages the policy metadata of the hierarchical management of live broadcast data (generally including the regression prediction model) to facilitate developers to maintain and upgrade the hierarchical management live broadcast data system.

[0085] The regression prediction model is an algorithm model that has been set up. It predicts one or more anchor clients that are online in the current data segment of the live broadcast platform served by the source data server, and outputs the anchor identifiers corresponding to each of these anchor clients to the source data server. Specifically, the regression prediction model obtains the online time information corresponding to multiple anchor clients in the anchor platform, and generates an anchor online list that stores mapping relationship data between these online time information and the anchor identifiers of the corresponding anchor clients. Then, it obtains the current time period information, queries the anchor online list for one or more anchor identifiers whose online time information is within the time period represented by the current time period information, and outputs these anchor identifiers as a prediction set so that the source data server can obtain each anchor identifier contained in the prediction set.

[0086] In one embodiment, the regression prediction model may be a neural network model that has been trained to a convergent state, which is implemented based on a normalization algorithm and classifies time periods according to the online time information corresponding to each anchor identifier. When corresponding to the regression prediction model, the model will query one or more anchor identifiers classified into the current time period as a prediction set and output it, so that the source data server can obtain each anchor identifier contained in the prediction set.

[0087] The anchor identifier generally refers to the user ID of the anchor user corresponding to the anchor client. It can also be the live broadcast room ID corresponding to the anchor user. Designers in this field can flexibly design the anchor identifier as long as it can realize the function of identifying the anchor client. This step will not be repeated.

[0088] Step S12: querying the live broadcast data corresponding to the anchor identifier stored in the hierarchical database, determining the live broadcast data as hot data and floating it to the storage medium with the highest performance level of the hierarchical database for storage. The data of the hierarchical database is dispersedly stored in multiple storage media with different performance levels.

[0089] After the server obtains the anchor identifier predicted by the regression prediction model, it will query the hierarchical database for one or more live broadcast data corresponding to the anchor identifier, and determine these live broadcast data as hot data, so as to float these live broadcast data to the storage medium with the highest performance level in the hierarchical database for storage.

[0090] The live broadcast data refers to the data required by the anchor client to perform live broadcast room online services, such as the anchor client's nickname, live broadcast room name, live broadcast type, live broadcast stream data and other data. When the anchor client opens a live broadcast room on the anchor platform to perform live broadcast room services, the server will need to push the live broadcast data to it and the audience client so that the anchor client can perform live broadcast room online services.

[0091] The data stored in the hierarchical database is generally stored in multiple storage media with different performance levels. The storage media corresponding to each performance level are generally sorted from high performance to low performance according to their performance level. In a typical embodiment, the performance level types of each storage medium include high performance level storage media, medium performance level storage media and low performance level storage media. Among them, the high performance level storage medium is generally the running memory of the device, the medium performance level storage medium is generally a solid-state storage hard disk, and the low performance level storage medium is generally a mechanical storage hard disk. In other embodiments, those skilled in the art can set different performance levels according to the hardware performance of the storage medium, such as two or four performance levels.

[0092] The source data server floats the live broadcast data corresponding to the anchor identifier predicted by the regression server stored in the hierarchical database to the storage medium with the highest performance level among all storage media, so as to improve the transmission efficiency of the live broadcast data of the anchor client that is online in the current time period when performing live broadcast business, with the help of the high performance of the storage medium with the highest performance. Among them, when the source data server floats the live broadcast data corresponding to the anchor identifier to the storage medium with the highest performance level for storage, if the storage space of the storage medium with the highest performance level is full, the live broadcast data that is last sorted in the storage medium with the highest performance level will be sunk to the storage medium of the next performance level for storage, so as to release the storage space of the storage medium with the highest performance level until the storage space of the live broadcast data corresponding to the anchor identifier is satisfied.

[0093] Step S13: responding to the data acquisition event pushed by the live broadcast service server, searching for the live broadcast data corresponding to the event in each storage medium according to the performance level from high to low, and pushing the live broadcast data to the live broadcast service server for data update:

[0094] The source data server responds to the data acquisition event pushed by the live broadcast business server, determines the live broadcast data pointed to by the data acquisition event, and queries the live broadcast data in the storage media of each performance level that stores the data of the hierarchical database. Among them, the source data server will give priority to querying the live broadcast data pointed to by the data acquisition event from the storage medium of the highest performance level. If the live broadcast data cannot be found, the live broadcast data will be queried in the storage medium of the next performance level, and so on, until the live broadcast data is found in the storage medium of a certain performance level, so as to obtain the live broadcast data and push it to the live broadcast business server, so that the live broadcast business service can obtain the live broadcast data and implement the corresponding live broadcast online service.

[0095] The data acquisition event is generally generated by the live broadcast service server in response to the event triggered by the anchor client in the live broadcast platform starting the live broadcast service. The data acquisition event will point to the live broadcast data corresponding to the anchor client, so that after the live broadcast service pushes the data acquisition event to the source data server, it drives the source data server to query the live broadcast data corresponding to the data acquisition event from the hierarchical database and push it, thereby enabling the live broadcast service server to obtain the live broadcast data for providing live online services to the anchor client.

[0096] Specifically, the source data server receives the data acquisition event triggered by the live broadcast service server, determines the live broadcast data pointed to by the event acquisition event, and queries the live broadcast data in these storage media in sequence from high performance level to low performance level according to the performance levels corresponding to the multiple storage media storing the data in the hierarchical database. When the live broadcast data is queried, the live broadcast data is obtained from the storage medium storing the live broadcast data, and the live broadcast data is pushed to the live broadcast service server.

[0097] It can be understood that this method predicts the currently online anchor client through the regression prediction model, and uses the live broadcast data belonging to the anchor client as hot data, and floats it for storage in a high-performance storage medium for storage. This can improve the transmission speed of the source data server to push live data to the live broadcast service server, and reduce the operating pressure of the source data server that stores the live broadcast data. At the same time, the source data server disperses the data stored in the hierarchical database to storage media of various performance levels, and floats the hot data to the storage medium of the highest performance level. Based on the hierarchical storage idea, the source live data is managed, and hierarchical query and hierarchical writing from high performance to low performance can improve the efficiency of the live broadcast data management system. Secondly, the relevant policy metadata of the hierarchical management of live broadcast data, including the regression prediction model, can be uniformly managed by the source server, which is convenient for upgrading and maintaining the metadata. In addition, compared with the traditional distributed storage idea, the application of this application can effectively improve the ability to cope with the needs of high concurrent requests, while improving the overall high availability, robustness and tolerance of the live broadcast data management system, which can reduce the relevant deployment costs overall.

[0098] The above exemplary embodiments and their variations fully disclose the implementation scheme of the live broadcast data scheduling method of the present application. However, various variations of the method can be derived by transforming and amplifying certain technical means. Other embodiments are briefly described below:

[0099] In one embodiment, please refer to Figure 3 In the step of calling the regression prediction model, the following steps are performed by the regression prediction model:

[0100] Step S111: obtaining online time information corresponding to multiple anchor clients in the live broadcast platform:

[0101] The regression prediction model obtains the online time information corresponding to multiple anchor clients in the live broadcast platform where the source data server is located. The online time information refers to the time period information during which the anchor client performs live broadcast business, which is generated by the live broadcast platform by recording the online time of the anchor client.

[0102] Step S112: The online time information and the corresponding anchor ID of the anchor client are stored as mapping relationship data in the anchor online time list:

[0103] After the regression prediction model obtains the online time information corresponding to each of the multiple anchor clients, the online time information and the anchor identifiers of the corresponding anchor clients are used as mapping relationship data, and the mapping relationship data are stored in the anchor online time list to facilitate the implementation of subsequent predictions.

[0104] Step S113: Obtain the current time period information, query the host online time list for one or more online time information corresponding to the current time period information, and obtain the host identifiers corresponding to the online time information:

[0105] When the regression prediction model needs to predict the anchor client that is online on the live broadcast platform within the current time period, it will obtain the current time period information representing the current time period, and query the anchor online time list for the corresponding online time information within the time period represented by the current time period information, and obtain the anchor identifier associated with one or more online time information determined by the query.

[0106] Step S114: Generate a host identification set including these host identifications, and output the host identification set:

[0107] After the regression prediction model obtains the anchor identifiers associated with one or more online time information corresponding to the current time period information from the anchor online time list, it encapsulates these anchor identifiers to generate an anchor identifier set containing these anchor identifiers and outputs it to the source data server, so that the source data server can float the live broadcast data corresponding to these anchor identifiers to the storage medium with the highest performance level for storage.

[0108] In this embodiment, the regression prediction model is constructed to predict the anchor clients that are online in the current time period, so that the source data server can float and store the live broadcast data corresponding to these anchor clients to the storage medium with the highest performance level, thereby improving the rate of writing or reading these live broadcast data, thereby improving the smoothness of the live broadcast data transmission of the live broadcast business of the anchor client in the current time period.

[0109] In one embodiment, please refer to Figure 4 In the step of responding to the data acquisition event pushed by the live broadcast service server, the following steps are also included:

[0110] Step S131: respond to the data acquisition event and determine the live broadcast data pointed to by the event:

[0111] The source data server responds to the data acquisition event pushed by the live broadcast service server and determines the live broadcast data pointed to by the data acquisition event.

[0112] Step S132: query the live broadcast data in the storage media in descending order according to the performance levels corresponding to the multiple storage media.

[0113] After the source data server determines the live data pointed to by the data acquisition data, it will query the live data from the storage medium with the highest performance level first according to the performance levels corresponding to the multiple storage media storing the data in the hierarchical database. If no live data can be found, the live data will be queried from the storage medium with the next performance level, and so on, until the live data is found from the storage medium with a certain performance level.

[0114] Step S133: Obtain the live broadcast data from the storage medium storing the live broadcast data, and push the live broadcast data to the live broadcast service server for data update.

[0115] When the source data server queries the live data pointed to by the data acquisition data from a storage medium of any performance level, it will obtain the live data from the storage medium and push the live data to the live business server so that the live business server can obtain the live data and perform corresponding live online services.

[0116] In this embodiment, the source data server will query and obtain live data from multiple storage media in the hierarchical database according to the performance levels corresponding to each of the storage media, from high to low, and push the live data, thereby effectively improving the query speed of the live data.

[0117] Furthermore, by functionalizing the various steps in the methods disclosed in the above embodiments, a live broadcast data scheduling device of the present application can be constructed. Figure 5 In a typical embodiment, the device includes: an anchor identification prediction module 11, which is used to call a regression prediction model to obtain the anchor identification corresponding to the anchor client that is online in the current time period on the live broadcast platform predicted by the model; a live broadcast data floating module 12, which is used to query the live broadcast data corresponding to the anchor identification stored in the hierarchical database, determine the live broadcast data as hot data and float it to the storage medium with the highest performance level of the hierarchical database for storage, and the data of the hierarchical database is dispersedly stored in multiple storage media with different performance levels; an acquisition event response module 13, which is used to respond to the data acquisition event pushed by the live broadcast service server, query the live broadcast data corresponding to the event in each storage medium according to the performance level from high to low, and push the live broadcast data to the live broadcast service server for data update.

[0118] In one embodiment, the anchor identification prediction module 11 includes: an online time acquisition submodule, used to obtain online time information corresponding to multiple anchor clients in the live broadcast platform; a relationship data storage submodule, used to store the online time information and the anchor identification of the corresponding anchor client as mapping relationship data in the anchor online time list; an anchor identification acquisition submodule, used to obtain current time period information, query one or more online time information corresponding to the current time period information in the anchor online time list, and obtain the anchor identification corresponding to the online time information; an identification set output submodule, used to generate an anchor identification set containing the anchor identifications, and output the anchor identification set.

[0119] In one embodiment, the acquisition event response module 13 includes: a live data determination submodule, which is used to respond to the data acquisition event and determine the live data pointed to by the event; a live data query submodule, which is used to query the live data in these storage media in order from high to low according to the performance levels corresponding to each of the multiple storage media; a live data push submodule, which is used to obtain the live data from the storage medium storing the live data and push the live data to the live business server for data update.

[0120] See also Figure 6 In a typical embodiment of the present invention, a live broadcast data access method includes the following steps:

[0121] Step S22: responding to a data increment query event on a live broadcast database, and broadcasting the data increment query event to all live broadcast service servers in the live broadcast service server cluster where the current live broadcast service server is located, wherein the live broadcast database is used to store live broadcast data.

[0122] When the current live broadcast service server responds to the data incremental query event acting on the live broadcast database, it broadcasts the data incremental query event to the live broadcast service server cluster where the current live broadcast service server is located, so that the live broadcast servers included in the live broadcast service server cluster receive the data incremental query event and then add the live broadcast data pointed to by the data incremental query event to their respective corresponding live broadcast databases.

[0123] Specifically, the current live broadcast business server is the first server in the live broadcast business server group. When it receives the data incremental query event, it pushes the data incremental query event to the live broadcast data acquisition queue, and broadcasts the latest received data incremental query event in the live broadcast data acquisition queue to the live broadcast data acquisition queues corresponding to other live broadcast business servers in the live broadcast business server group, so that other live broadcast business servers in the live broadcast business server group can obtain the data incremental query event in response, and each incrementally query the live broadcast data corresponding to the event from the source data server.

[0124] The live broadcast database is used to store mapping relationship data consisting of live broadcast data and its corresponding live broadcast identifier, and the live broadcast data stored in the live broadcast database is generally the live broadcast data corresponding to the anchor client currently performing live broadcast business in the live broadcast platform, so that the live broadcast business server can provide live online services to the anchor client currently performing live broadcast business in the live broadcast platform through the mapping relationship data stored in the live broadcast database.

[0125] The live broadcast service server cluster is composed of multiple live broadcast service servers, and these live broadcast service servers establish data communication links between each other based on the local area network to ensure the transmission speed of the broadcast push of data update events.

[0126] The data incremental query event is generally triggered when the anchor client in the live broadcast platform where the current live broadcast service server is located starts the live broadcast service. When the anchor client starts the live broadcast service (commonly known as broadcasting), the data incremental query event will be triggered to drive the live broadcast service server to obtain the live broadcast data corresponding to the anchor client from the source data server and store it in the live broadcast database, so that the anchor client can perform the live broadcast service according to the live broadcast data.

[0127] The monitoring party that monitors the live broadcast platform's anchor start event is generally the live broadcast monitoring server set up by the live broadcast platform. When the live broadcast monitoring server monitors that any anchor client in the live broadcast platform starts the live broadcast service, it will generate the data incremental query event pointing to the live broadcast data corresponding to the anchor client, and push it to the current live broadcast service server to drive the live broadcast service server to obtain the live broadcast data pointed to by the event from the source data server and store it in the live broadcast database, so that the anchor client can perform live broadcast service based on the live broadcast data.

[0128] Furthermore, after the current live broadcast service server receives the data incremental query event pushed by the live broadcast monitoring server, it stores the data incremental query event in the live broadcast data acquisition queue. The multiple data update events are stored in the update event list, and each data update event is sorted in descending order in the update event list according to its entry time. The live broadcast service server obtains the latest data incremental query event in the live broadcast data acquisition queue to broadcast the data incremental query event to the live broadcast service server cluster where the current live broadcast service server is located, and the live broadcast data acquisition queues corresponding to all live broadcast service servers in the live broadcast service server cluster.

[0129] Step S23: Push the data acquisition event to the source data server to drive the source data server to query the live data corresponding to the data acquisition event in the storage media according to the performance level of each storage medium where the hierarchical database is located, from high to low:

[0130] The live broadcast service server pushes the data acquisition instruction to the source data server. After the source data server determines the live broadcast data pointed to by the data acquisition data, it will query the live broadcast data from the storage medium with the highest performance level first according to the performance levels corresponding to the multiple storage media storing the data in the hierarchical database. If no live broadcast data is found, the live broadcast data will be queried from the storage medium with the next performance level, and so on, until the live broadcast data is found from the storage medium with a certain performance level.

[0131] Specifically, after the current live broadcast service server responds to the data incremental query event, it will determine the live broadcast data pointed to by the event, and generate the data acquisition event pointing to the live broadcast data and push it to the source data server to query the live broadcast data corresponding to the data acquisition event from the hierarchical database of the source data server.

[0132] The live broadcast service server obtains the latest data update event in the update event list to broadcast the new data event to the live broadcast data lists corresponding to all live broadcast service servers in the live broadcast service server cluster where the live broadcast service server is located.

[0133] Step S24: Obtain the live broadcast data from the hierarchical database of the source data server and store the live broadcast data in the live broadcast database.

[0134] After the live broadcast service server queries the live broadcast data corresponding to the data acquisition event from the storage medium of any performance level of the source data server, it will obtain the live broadcast data from the storage medium and store the live broadcast data and its corresponding anchor identifier as mapping relationship data in the live broadcast database.

[0135] In one embodiment, the current live broadcast service server responds to the data acquisition instruction, obtains the live broadcast data pointed to by the data acquisition instruction from the live broadcast database, and transmits the live broadcast data to the pusher that pushes the data acquisition instruction, wherein the data acquisition instruction is generally pushed by the anchor client of the live broadcast platform to obtain the live broadcast data pointed to by the instruction from the live broadcast database of the live broadcast service server to perform live broadcast service.

[0136] In one embodiment, the current live broadcast service server responds to the anchor's broadcasting off event, determines the anchor client pointed to by the event, queries the live broadcast database for the live broadcast data corresponding to the anchor identifier of the anchor client, and deletes the live broadcast data from the live broadcast database to save storage space of the device.

[0137] It can be understood that in this method, the live broadcast business server responds to the data incremental query event acting on the live broadcast database, and sequentially and incrementally queries the live broadcast data pointed to by the event in the storage media with different performance levels in the hierarchical database of the source data server, from the high-performance level to the low-performance level for storage. Compared with the traditional database query method, the hierarchical storage method effectively improves the data query speed, and the live broadcast business server will push the data incremental query event to other servers in the server cluster where it is located to improve the data synchronization efficiency of each live broadcast business server in the cluster. The live broadcast business server is responsible for pushing the live broadcast data obtained from the source data server to the corresponding data demander, which can share the data push service in the live broadcast data system, reduce the data transmission pressure of the source data server, and improve the overall stability of the system.

[0138] The above exemplary embodiments and their variations fully disclose the implementation scheme of the live broadcast data access method of the present application. However, various variations of the method can be derived by changing and amplifying certain technical means. Other embodiments are briefly described below:

[0139] In one embodiment, please refer to Figure 7 Before the step of responding to the data increment query event acting on the live broadcast database, the method further includes the following steps:

[0140] Step S20: respond to the anchor start event and determine the anchor client to which the anchor start event points.

[0141] The current live broadcast service server responds to the anchor start event and drives the anchor client pointed to by the anchor start event to obtain the live broadcast data corresponding to the anchor client from the source data server.

[0142] The anchor start event is triggered by the current live broadcast service server starting the live broadcast service on the anchor client associated with it.

[0143] Step S21: Determine the anchor ID corresponding to the anchor client to generate the data increment query event for storing the live data corresponding to the anchor ID in the live database:

[0144] The current live broadcast service server responds to the anchor start event, determines that the event points to the anchor client, and then determines the anchor identifier corresponding to the anchor client, and then generates the data incremental query event to store the live broadcast event corresponding to the anchor identifier in the live broadcast database.

[0145] The current live broadcast service server responds to the data incremental query event, and then pushes a data acquisition event pointing to the live broadcast data corresponding to the event to the source data server, so as to obtain the live broadcast data pointed to by the data acquisition event from the hierarchical database of the source data server and store it in the live broadcast database, so as to facilitate the provision of live broadcast online services to the anchor client pointed to by the anchor start event.

[0146] In this embodiment, a data acquisition event is generated by responding to the broadcast start event of the anchor client in the live broadcast platform, so as to obtain the live broadcast data corresponding to the anchor client from the source data server and store it in the live broadcast database, thereby providing live broadcast online services for the anchor client, so that the live broadcast business of the anchor client can be executed in a process.

[0147] In one embodiment, please refer to Figure 8 After the step of updating the live broadcast data pre-stored in the own database, the following steps are also included:

[0148] Step S25: In response to the high load event of the source data server, push data synchronization events to other live service servers:

[0149] After the current live broadcast service server obtains the live broadcast data pointed to by the data acquisition event in the hierarchical database of the source data server and stores it in the live broadcast database, when the source server triggers the high load event, the current live broadcast server will push the event synchronization event to other live broadcast service servers.

[0150] The high-load event is generally an event triggered by the source data server being unable to push live data to other live business servers due to excessive load events such as high concurrent requests. After the source data server triggers the generation of the high-load event, the live business server that has obtained the corresponding live data from its hierarchical database will be responsible for responding to drive the live business server to push the data synchronization event pointing to the live data to other live business servers, triggering other live business servers to obtain the live data from the live business server that pushed the data synchronization event.

[0151] Step S26: In response to data acquisition events of other live broadcast service servers, the incremental live broadcast data acquired from the hierarchical database of the source data server is pushed to other live broadcast service servers for synchronous update:

[0152] After the current live broadcast service server pushes the data synchronization event to other live broadcast service servers, it will obtain the data acquisition event pushed by these live broadcast service servers, and push the incremental live broadcast data obtained in advance from the hierarchical database of the source data server to these live broadcast service servers, so that these live broadcast service servers can obtain the incremental live broadcast data and store it in their respective corresponding live broadcast databases, thereby completing the synchronous update of the live broadcast data in the live broadcast database.

[0153] The incremental live broadcast data refers to the live broadcast data obtained by the current live broadcast service server from the source data server in response to the data incremental query event.

[0154] In this embodiment, the live broadcast business server that has obtained the live broadcast data that currently needs to be incremented from the source data server responds to high-load events of the source data server due to high concurrency or other excessive loads, and uses itself as the live broadcast data pusher to push the live broadcast data obtained from the source data server to other live broadcast business servers, thereby sharing the transmission of the live broadcast data with the source data server, reducing the transmission pressure of the source data server, ensuring the transmission stability of the source data server, and also improving the push speed of the live broadcast data in the system.

[0155] Furthermore, by functionalizing the various steps in the methods disclosed in the above embodiments, a live data access device of the present application can be constructed. Figure 9 In a typical embodiment, the device includes: an incremental event response module 21, which is used to respond to a data incremental query event acting on a live broadcast database, and broadcast the data incremental query event to all live broadcast business servers in the live broadcast business server cluster where the current live broadcast business server is located, and the live broadcast database is used to store live broadcast data; an acquisition event push module 22, which is used to push a data acquisition event to a source data server to drive the source data server to query the live broadcast data corresponding to the data acquisition event in these storage media from high to low according to the performance levels of each storage medium where the hierarchical database is located; a live broadcast data acquisition module 23, which is used to obtain the live broadcast data from the hierarchical database of the source data server and store the live broadcast data in the live broadcast database.

[0156] In order to solve the above technical problems, the embodiment of the present application further provides a computer device for running a computer program implemented according to the live data scheduling method or live data access method. Figure 10 , Figure 10 This is a basic structural block diagram of the computer device in this embodiment.

[0157] like Figure 10 As shown, a schematic diagram of the internal structure of a computer device. The computer device includes a processor, a non-volatile storage medium, a memory and a network interface connected via a system bus. Among them, the non-volatile storage medium of the computer device stores an operating system, a database and computer-readable instructions, and the database may store a control information sequence. When the computer-readable instructions are executed by the processor, the processor may implement a live data scheduling method or a live data access method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor may execute a live data scheduling method or a live data access method. The network interface of the computer device is used to connect and communicate with a terminal. Those skilled in the art will understand that Figure 10 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 computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0158] In this embodiment, the processor is used to execute the specific functions of each module / submodule in the live data scheduling or live data access device of this application, and the memory stores the program code and various data required to execute these modules. The network interface is used to transmit data between user terminals or servers. The memory in this embodiment stores the program code and data required to execute all modules / submodules in the live data scheduling or live data access device, and the server can call the server's program code and data to execute the functions of all submodules.

[0159] The present application also provides a non-volatile storage medium, in which the live broadcast data scheduling method or live broadcast data access method is written into a computer program and stored in the storage medium in the form of computer-readable instructions. When the computer-readable instructions are executed by one or more processors, it means that the program is running in the computer, thereby enabling one or more processors to execute the steps of the live broadcast data scheduling method or live broadcast data access method of any of the above-mentioned embodiments.

[0160] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments 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 executed, the program can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0161] In summary, the present application effectively improves the transmission efficiency of live broadcast data by storing source live broadcast data in layers and floating the predicted hot spot data to a high-performance storage medium.

[0162] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0163] Those skilled in the art will appreciate that the steps, measures, and schemes in the various operations, methods, and processes discussed in this application may be interchanged, modified, combined, or deleted. Furthermore, other steps, measures, and schemes in the various operations, methods, and processes discussed in this application may also be interchanged, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and schemes in the prior art that are similar to those disclosed in this application may also be interchanged, modified, rearranged, decomposed, combined, or deleted.

[0164] The above description is only part of the implementation methods of the present 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 the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A live broadcast data scheduling method, characterized in that: The steps include: Call the regression prediction model to obtain the anchor ID corresponding to the anchor client that is online in the current time period on the live broadcast platform predicted by the model; Querying the live broadcast data corresponding to the anchor identifier stored in the hierarchical database, determining the live broadcast data as hot data and floating it to the storage medium with the highest performance level of the hierarchical database for storage, wherein the data of the hierarchical database is dispersedly stored in multiple storage media with different performance levels; The source data server responds to the data acquisition event pushed by the live broadcast service server, searches for the live broadcast data corresponding to the event in each storage medium according to the performance level from high to low, and pushes the live broadcast data to the live broadcast service server; The responding to the data acquisition event pushed by the live broadcast service server also includes: responding to the data acquisition event and determining the live broadcast data pointed to by the event; According to the performance levels corresponding to the multiple storage media, the live data is queried in the storage media in order from high to low; the live data is obtained from the storage media storing the live data, and the live data is pushed to the live service server for data update.

2. The method according to claim 1, characterized in that The step of calling the regression prediction model includes the following steps performed by the regression prediction model: Obtaining online time information corresponding to multiple anchor clients in the live broadcast platform; The online time information and the corresponding anchor client's anchor ID are stored as mapping relationship data in the anchor online time list; Obtain the current time period information, query the host online time list for one or more online time information corresponding to the current time period information, and obtain the host identifiers corresponding to the online time information; Generate an anchor identification set including the anchor identifications, and output the anchor identification set.

3. The method according to any one of claims 1 to 2, characterized in that: The data of the hierarchical database is distributed and stored in a high-performance storage medium, a medium-performance storage medium, and a low-performance storage medium, wherein the high-performance storage medium is the running memory of the device.

4. A live broadcast data access method, characterized in that: The steps include: Respond to the anchor start event and determine the anchor client to which the anchor start event points; Determine the anchor identifier corresponding to the anchor client to generate a data increment query event for storing the live broadcast data corresponding to the anchor identifier in the live broadcast database; Responding to a data increment query event acting on a live broadcast database, and broadcasting the data increment query event to all live broadcast service servers in the live broadcast service server cluster where the current live broadcast service server is located, the live broadcast database being used to store live broadcast data; Pushing a data acquisition event to a source data server to drive the source data server to query the storage media for live data corresponding to the data acquisition event according to the performance levels of the storage media where the hierarchical database is located, from high to low; The live broadcast data is acquired from a hierarchical database of a source data server, and the live broadcast data is stored in a live broadcast database.

5. The method according to claim 4, characterized in that The following steps are also included: Respond to high-load events on the source data server and push data synchronization events to the live broadcast service server; In response to the data acquisition event of the live broadcast service server, the incremental live broadcast data obtained from the hierarchical database of the source data server is pushed to the live broadcast service server for synchronous update.

6. The method according to any one of claims 4 to 5, characterized in that: The data of the hierarchical database is distributed and stored in a high-performance storage medium, a medium-performance storage medium, and a low-performance storage medium, wherein the high-performance storage medium is the running memory of the device.

7. A live broadcast data scheduling device, characterized in that: include: The anchor ID prediction module is used to call the regression prediction model to obtain the anchor ID corresponding to the anchor client online in the current time period on the live broadcast platform predicted by the model; a live data uploading module, configured to query the live data corresponding to the anchor identifier stored in the hierarchical database, identify the live data as hot data, and upload it to the storage medium with the highest performance level in the hierarchical database for storage. The data in the hierarchical database is stored in a dispersed manner in multiple storage media with different performance levels; An acquisition event response module is used to respond to a data acquisition event pushed by a live broadcast service server by a source data server, query the live broadcast data corresponding to the event in each storage medium according to the performance level from high to low, and push the live broadcast data to the live broadcast service server; The responding to the data acquisition event pushed by the live broadcast service server also includes: responding to the data acquisition event and determining the live broadcast data pointed to by the event; According to the performance levels corresponding to the multiple storage media, the live data is queried in the storage media in order from high to low; the live data is obtained from the storage media storing the live data, and the live data is pushed to the live service server for data update.

8. 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 6.

9. 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 6 in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the method are executed.

10. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images