CN108235051B - Live broadcast system and method for storing and acquiring live broadcast data - Google Patents
Live broadcast system and method for storing and acquiring live broadcast data Download PDFInfo
- Publication number
- CN108235051B CN108235051B CN201711475368.3A CN201711475368A CN108235051B CN 108235051 B CN108235051 B CN 108235051B CN 201711475368 A CN201711475368 A CN 201711475368A CN 108235051 B CN108235051 B CN 108235051B
- Authority
- CN
- China
- Prior art keywords
- live broadcast
- live
- server
- anchor
- broadcast data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
- H04N21/23103—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion using load balancing strategies, e.g. by placing or distributing content on different disks, different memories or different servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
- H04N21/23113—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving housekeeping operations for stored content, e.g. prioritizing content for deletion because of storage space restrictions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/232—Content retrieval operation locally within server, e.g. reading video streams from disk arrays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/27—Server based end-user applications
- H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The embodiment of the invention provides a live broadcast system and a method for storing and acquiring live broadcast data, wherein the live broadcast data is received and stored through a main Redis server, live broadcast identifications and live broadcast identifications of all live broadcasts of the same anchor are acquired from the live broadcast data, and the live broadcast identifications are stored in a live broadcast identification set corresponding to the anchor; then synchronously storing each live broadcast data and each live broadcast identification set into a secondary Redis server; and the slave Redis server acquires the live broadcast identification in the corresponding live broadcast identification set according to each anchor broadcast identification in the live broadcast data acquisition request, thereby acquiring the live broadcast data corresponding to each live broadcast identification one to one and sending the live broadcast data to the corresponding user client. The main Redis server is used for storing live broadcast data, the slave Redis server responds to a live broadcast data acquisition request, high concurrency query can be effectively responded, the phenomena that the performance of a live broadcast database is reduced and the live broadcast database is blocked due to the high concurrency query are reduced, and the user experience of live broadcast service is improved.
Description
Technical Field
The invention relates to the technical field of live broadcast, in particular to a live broadcast system and a method for storing and acquiring live broadcast data.
Background
In the existing live broadcast system, after live broadcast data of main broadcast live broadcast is collected in real time by a live broadcast client, the live broadcast data is synchronously uploaded to a live broadcast server and sent to a live broadcast database server by the live broadcast server. When a user enters a live broadcast room of a certain anchor to watch live broadcast, the live broadcast server responds to a broadcast request sent by a user client, directly queries a live broadcast database to obtain live broadcast data of the anchor, and sends the obtained live broadcast data to the user client for the user to watch.
However, in the live broadcast system, the same live broadcast database server stores live broadcast data, responds to a live broadcast data query request, analyzes the query request, acquires live broadcast data and sends the live broadcast data to users, and when a large number of users send broadcast requests at the same time to generate a large number of queries, performance of the live broadcast database is reduced and is blocked due to high concurrency of the queries, the live broadcast data cannot be acquired quickly, and user experience of live broadcast service is affected.
Therefore, how to still quickly acquire live broadcast data during high-concurrency query is a problem to be solved by the existing live broadcast system.
Disclosure of Invention
The embodiment of the invention aims to provide a live broadcast system and a live broadcast data storage and acquisition method, so that live broadcast data can be still acquired quickly during high-concurrency query. The specific technical scheme is as follows:
in a first aspect, an embodiment of the present invention provides a live broadcast system, where the system includes:
the live broadcast server is used for receiving live broadcast data submitted by the live broadcast client of each anchor and sending the live broadcast data to the main Redis server;
the main Redis server is used for receiving live broadcast data submitted by each live broadcast client from the live broadcast server and obtaining anchor identifiers of each anchor and live broadcast identifiers of all live broadcasts of the same anchor from the live broadcast data; storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor; synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server;
the slave Redis server is used for receiving live broadcast data acquisition requests sent by all user clients from the live broadcast server and acquiring live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition requests; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
Optionally, the live broadcasting system further includes: a load balancing server; the number of the secondary Redis servers is multiple;
the master Redis server synchronously stores each stored live broadcast data and each live broadcast identification set into each slave Redis server;
the live broadcast server receives live broadcast data acquisition requests sent by the user clients and forwards the live broadcast data acquisition requests to the load balancing server;
the load balancing server judges the current load size of each slave Redis server after receiving the live data acquisition request, and selects the slave Redis server with the minimum load as the current slave Redis server; sending the received live broadcast data acquisition request to the current slave Redis server;
the current slave Redis server acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition request; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
In a second aspect, an embodiment of the present invention provides a method for storing live broadcast data, which is applied to the live broadcast system in the first aspect, and the method includes:
a master Redis server receives the live broadcast data sent by a live broadcast server, and acquires the anchor identification of each anchor and the live broadcast identification of each live broadcast of the same anchor from the live broadcast data;
storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor;
and synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server.
Optionally, the step of storing each live broadcast identifier in a live broadcast identifier set of a corresponding anchor includes:
and storing each live broadcast identifier in an ordered live broadcast identifier set of a corresponding main broadcast in a main Redis server according to a receiving time sequence, and taking the receiving time as a time label of each live broadcast identifier in the live broadcast identifier set.
Optionally, the step of synchronously storing each stored live data and each live identification set in the slave Redis server includes:
acquiring the current live broadcast data transmission rate of the live broadcast system;
if the transmission rate of the current live broadcast data is smaller than a preset data transmission rate threshold value, when the number of the currently watched users meets a preset condition, synchronously storing each live broadcast data in the master Redis server to the slave Redis server in an AOF mode;
if the current live data transmission rate is larger than or equal to a preset data transmission rate threshold, synchronously storing each live data in the master Redis server to the slave Redis server in an RDB mode;
and synchronously storing each live broadcast identification set in the master Redis server to the slave Redis server in an RDB mode.
Optionally, if the current live data transmission rate is less than a preset data transmission rate threshold, when the number of users meets a preset condition, the step of synchronously storing each live data in the master Redis server to the slave Redis server in an AOF manner includes:
if the transmission rate of the current live broadcast data is smaller than a preset data transmission rate threshold value, acquiring the number of users watching each anchor live broadcast currently;
if the number of users watching the corresponding anchor is larger than or equal to a preset user number threshold, synchronously storing live broadcast data of the corresponding anchor in a master Redis server into a slave Redis server in an RDB mode;
and if the number of the users watching the corresponding anchor is smaller than a preset user number threshold value, synchronously storing the live broadcast data of the corresponding anchor in the master Redis server to the slave Redis server in an AOF mode.
In a third aspect, an embodiment of the present invention provides a method for acquiring live broadcast data, which is applied to the live broadcast system in the first aspect, and the method includes:
receiving a live broadcast data acquisition request sent by each user client from a live broadcast server from a Redis server, and acquiring live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to each anchor identifier in the live broadcast data acquisition request;
and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
Optionally, the live broadcast identifier set corresponding to the anchor identifier is an ordered set, and the live broadcast identifiers are stored in the order of live broadcast data receiving time;
the method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
receiving current live broadcast data acquisition requests sent by user clients from a Redis server from the live broadcast server;
when the live broadcast identifications are stored according to the sequence from far to near of the live broadcast data receiving time, acquiring live broadcast identifications stored at the last position in a live broadcast identification set corresponding to the live broadcast identifications according to each anchor identification in the live broadcast data acquisition request;
and when the live broadcast identifications are stored according to the sequence of the live broadcast data receiving time from near to far, acquiring the live broadcast identification set corresponding to the anchor broadcast identification and stored in the top live broadcast identification according to each anchor broadcast identification in the live broadcast data acquisition request.
Optionally, the live broadcast identifier set corresponding to the anchor identifier further includes a time tag of each live broadcast identifier, where the time tag is used to distinguish receiving time of each live broadcast data;
the method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
receiving a playback live broadcast data acquisition request sent by each user client from a Redis server from the live broadcast server;
and according to each anchor identification and the live broadcast time in the playback live broadcast data acquisition request, acquiring the live broadcast identification, of which the time tag corresponds to the live broadcast time in the playback live broadcast data acquisition request, in a live broadcast identification set corresponding to the anchor identification.
Optionally, when the live data acquiring method of the third aspect is applied to the live system of the first aspect, the live system further includes: a load balancing server; the number of the slave Redis servers is multiple;
the method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
after receiving a live data acquisition request sent by each user client from the live server, the load balancing server judges the current load size of each slave Redis server, and selects the slave Redis server with the minimum load as the current slave Redis server; sending the received live broadcast data acquisition requests sent by the user clients to the current slave Redis server;
the current slave Redis server acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition request; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
The embodiment of the invention provides a live broadcast system and a method for storing and acquiring live broadcast data, which receive live broadcast data through a main Redis server, and acquire anchor marks of all anchor and live broadcast marks of all live broadcasts of the same anchor from the live broadcast data; storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor; synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server; receiving, by a slave Redis server, a live data acquisition request sent by each user client from the live server, and acquiring, according to each anchor identifier in the live data acquisition request, a live identifier in a live identifier set corresponding to the anchor identifier; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server. Compared with the traditional mode that the same live broadcast database server undertakes live broadcast data storage and responds to the live broadcast data acquisition request, the embodiment of the invention has the advantages that the main Redis server stores the live broadcast data, the secondary Redis server responds to the live broadcast data acquisition request, high concurrency query can be more effectively responded, the phenomena of performance reduction and jamming of the live broadcast database caused by the high concurrency query are reduced, and the user experience of the live broadcast service is improved. Of course, it is not necessary for any product or method of practicing the invention to achieve all of the above-described advantages at the same time.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below.
Fig. 1 is a schematic structural diagram of a live broadcast system according to an embodiment of the present invention;
fig. 2 is a flowchart of a method for storing live data according to an embodiment of the present invention;
fig. 3 is a flowchart of a method for acquiring live data according to an embodiment of the present invention;
fig. 4 is another schematic structural diagram of a live broadcast system according to an embodiment of the present invention.
Detailed Description
In order to make those skilled in the art better understand the technical solution of the present invention, the technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In order to achieve the purpose that live data can still be quickly acquired during high-concurrency query, the embodiment of the invention provides a live broadcast system and a method for storing and acquiring live data.
Next, a live broadcast system provided in an embodiment of the present invention is described first.
As shown in fig. 1, a schematic structural diagram of a live broadcast system provided in an embodiment of the present invention includes:
and the live broadcast server 101 is configured to receive live broadcast data submitted by live broadcast clients of each anchor and send the live broadcast data to the master Redis server.
The main Redis server 102 is configured to receive live broadcast data submitted by each live broadcast client from the live broadcast server, and obtain, from the live broadcast data, a anchor identifier of each anchor and a live broadcast identifier of each live broadcast of the same anchor; storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor; and synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server.
The slave Redis server 103 is used for receiving live broadcast data acquisition requests sent by each user client from the live broadcast server, and acquiring live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition requests; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
It should be noted that, in fig. 1, the client is connected to the live broadcast server in various ways. For example: if the client is a computer, the client can be connected with the live broadcast server through a wired network or a wireless network. The embodiment of the invention does not limit the connection mode of the client and the live broadcast server.
For example: the anchor a and the anchor b live the live client 105 through their respective live clients 104, and the live server 101 receives the live data submitted by these live clients and then sends the live data to the master Redis server 102. The master Redis server 102 receives live broadcast data submitted by each live broadcast client from the live broadcast server 101, and obtains respective anchor identifiers a and B of an anchor a and an anchor B in the live broadcast data, and live broadcast identifiers of each live broadcast of the same anchor, such as: a1, B1. The master Redis server 102 stores the acquired live broadcast data, and stores each live broadcast identifier in a live broadcast identifier set corresponding to the master: the set RA of live identifiers of anchor a is { a1}, and the set RB of live identifiers of anchor B is { B1 }. And finally, synchronously sending and storing each stored live broadcast data and each live broadcast identification set into the secondary Redis server 103.
When a user d, a user e, and a user f enter a live broadcast room of each anchor through respective user clients 106, 107, and 108 to watch live broadcasts, the user clients will send live broadcast data acquisition requests to the live broadcast server 101. Receiving, from the direct broadcast server 101, a direct broadcast data acquisition request sent by each user client from the Redis server 103, and acquiring, according to each anchor identifier in the direct broadcast data acquisition request, a direct broadcast identifier in a direct broadcast identifier set corresponding to the anchor identifier. If user d, user e, and user f watch the live broadcast of anchor a and the live broadcast of anchor B, respectively, then the Redis server 103 obtains the live broadcast id a1 in the live broadcast id set RA of anchor a and the live broadcast id B1 in the live broadcast id set RB of anchor B. And acquiring synchronously stored live broadcast data corresponding to each live broadcast identification one by one from the Redis server 103 according to the acquired live broadcast identification A1 and the live broadcast identification B1, sending the live broadcast data corresponding to the live broadcast identification A1 to the user client 106 and the user client 107 through the live broadcast server 101, and sending the live broadcast data corresponding to the live broadcast identification B1 to the user client 108 through the live broadcast server 101.
In the live broadcast system provided by the embodiment of the invention, live broadcast data is received through the master Redis server, and the anchor identification of each anchor and the live broadcast identification of each live broadcast of the same anchor are obtained from the live broadcast data; storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor; synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server; receiving, by a slave Redis server, a live data acquisition request sent by each user client from the live server, and acquiring, according to each anchor identifier in the live data acquisition request, a live identifier in a live identifier set corresponding to the anchor identifier; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server. Compared with the traditional mode that the same live broadcast database server undertakes live broadcast data storage and responds to a live broadcast data acquisition request, the embodiment of the invention has the advantages that the main Redis server stores the live broadcast data, the stored data are synchronously stored in the secondary Redis server, and the secondary Redis server responds to the live broadcast data acquisition request, so that high concurrency query can be more effectively responded, the phenomena of performance reduction and jamming of the live broadcast database caused by the high concurrency query are reduced, and the user experience of the live broadcast service is improved. In addition, the Redis server is a server for storing data in a Key-Value structure, and the Key-Value structure has excellent storage and query speeds, so that the quick storage and acquisition of live data can be ensured.
As shown in fig. 2, a flowchart of a live data storage method provided in an embodiment of the present invention is applied to the live system shown in fig. 1, and may include the following steps:
s201, a master Redis server receives the live broadcast data sent by a live broadcast server, and obtains the anchor identification of each anchor and the live broadcast identification of each live broadcast of the same anchor from the live broadcast data.
S202, storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor broadcast.
S203, synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server.
For example: the master Redis server 102 receives live broadcast data submitted by each live broadcast client from the live broadcast server 101, and obtains respective anchor identifiers a and B of an anchor a and an anchor B in the live broadcast data, and live broadcast identifiers of each live broadcast of the same anchor, such as: a1, B1. The master Redis server 102 stores the acquired live broadcast data, and stores each live broadcast identifier in a live broadcast identifier set corresponding to the master: the set RA of live identifiers of anchor a is { a1}, and the set RB of live identifiers of anchor B is { B1 }. And finally, synchronously sending and storing each stored live broadcast data and each live broadcast identification set into the secondary Redis server 103. And the slave Redis server I acquires the live broadcast identification in the live broadcast identification set corresponding to the live broadcast identification according to each live broadcast identification in the live broadcast data acquisition request.
The embodiment of the invention provides a method for storing live broadcast data, which comprises the steps of receiving the live broadcast data through a master Redis server, and obtaining anchor marks of all anchor broadcasts and live broadcast marks of all live broadcasts of the same anchor broadcast from the live broadcast data; storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor; and synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server. Compared with the traditional mode that the same live broadcast database server undertakes live broadcast data storage and responds to a live broadcast data acquisition request, the embodiment of the invention stores the live broadcast data by the master Redis server and synchronously stores the stored data on the slave Redis server, so that the slave Redis server can respond to the live broadcast data acquisition request subsequently, high concurrency query can be responded effectively, the phenomena of performance reduction and jamming of the live broadcast database caused by the high concurrency query are reduced, and the user experience of the live broadcast service is improved. In addition, the Redis server is a server for storing data in a Key-Value structure, and the Key-Value structure has excellent storage and query speeds, so that the quick storage and acquisition of live data can be ensured.
Optionally, in the storage method of live data shown in fig. 2, step S202 may include:
and storing each live broadcast identifier in an ordered live broadcast identifier set of a corresponding main broadcast in a main Redis server according to a receiving time sequence, and taking the receiving time as a time label of each live broadcast identifier in the live broadcast identifier set.
For example: anchor a has 3 live data reception times a 1: 20:00 at 12.9.2017, a 2: 9/2017, 19/20: 15, a 3: 26/05 of 2017, live identifiers a1, a2 and A3 in the 3 live data are stored in a live identifier set RA of the anchor a in the receiving time sequence of the live identifiers, that is, RA ═ a1, a2 and A3, or RA ═ A3, a2 and a1, and the time labels of the live identifiers a1, a2 and A3 are respectively: 2017.9.12.20.00, 2017.9.19.20.15, 2017.9.26.20.05.
It can be understood that the live broadcast identifications are stored in the ordered set according to the sequence of the receiving time, and the receiving time is used as the time tag of each live broadcast identification, so that the live broadcasts of multiple sessions of the same anchor are conveniently and continuously stored and managed, and richer live broadcast data information is conveniently provided for users.
Optionally, in the method for acquiring live data shown in fig. 2, step S203 may include:
and acquiring the current live broadcast data transmission rate of the live broadcast system.
And if the current live data transmission rate is smaller than a preset data transmission rate threshold value, synchronously storing each live data in the master Redis server to the slave Redis server by adopting an AOF mode when the number of the currently watched users meets a preset condition.
If the current live data transmission rate is larger than or equal to a preset data transmission rate threshold, synchronously storing each live data in the master Redis server to the slave Redis server in an RDB mode;
and synchronously storing each live broadcast identification set in the master Redis server to the slave Redis server in an RDB mode.
The AOF (attached File) persistence scheme is a scheme for completely restoring and recording each live broadcast data in a main Redis server, and can well ensure the integrity of the data. For the condition that the network environment is not stable enough, the live broadcast data in the master Redis server can be effectively ensured to be completely and synchronously stored in the slave Redis server. An RDB (Redis DataBase, Redis DataBase backup) persistence scheme is a scheme for recording each live data in a main Redis server in a snapshot mode according to a preset frequency, can quickly store the live data, has a small amount of stored files, and can quickly respond to a data acquisition request. The AOF method is slower than the RDB method in response to a data acquisition request because the amount of files to be saved is larger than that in the RDB method.
Therefore, before synchronous storage, the current live broadcast data transmission rate of the live broadcast system can be acquired to judge whether the current network environment is stable.
And if the current live data transmission rate is smaller than a preset data transmission rate threshold value, namely the current network environment is not stable enough, and when the number of users meets a preset condition, synchronously storing each live data in the master Redis server to the slave Redis server in an AOF mode. The limitation that the number of users meets the preset condition is to ensure that the slow response speed of the data acquisition request can still meet the requirement of the live data acquisition of users watching a certain anchor with the number of users who currently watch the anchor meeting the preset condition when the AOF mode is adopted.
If the current live data transmission rate is greater than or equal to the preset data transmission rate threshold, namely under the condition that the current network environment is stable, the RDB mode is adopted to synchronously store each live data in the master Redis server to the slave Redis server, the problem that the safety cannot meet the requirement when the data are synchronously stored in the RDB mode due to unstable network environment can be avoided, and meanwhile, the speed of acquiring the live data is effectively improved.
And synchronously storing each live broadcast identification set in the master Redis server to the slave Redis server in an RDB mode. It can be understood that, for a small amount of live broadcast identifier sets, the live broadcast identifier sets are quickly and synchronously stored in the secondary Redis server in an RDB mode, which is more reasonable than an AOF mode.
Optionally, if the current live data transmission rate is less than a preset data transmission rate threshold, when the number of users meets a preset condition, the step of synchronously storing each live data in the master Redis server to the slave Redis server in an AOF manner may specifically include:
and if the transmission rate of the current live broadcast data is less than a preset data transmission rate threshold value, acquiring the number of users watching each anchor live broadcast currently.
And if the number of the users watching the corresponding anchor is larger than or equal to a preset user number threshold, synchronously storing the live broadcast data of the corresponding anchor in the master Redis server into the slave Redis server by adopting RDB.
And if the number of the users watching the corresponding anchor is smaller than a preset user number threshold value, synchronously storing the live broadcast data of the corresponding anchor in the master Redis server into the slave Redis server by adopting AOF.
For example: and under the condition that the current live broadcast data transmission rate of the live broadcast system is smaller than a preset data transmission rate threshold value, acquiring the number of users watching each anchor live broadcast currently. The preset threshold value of the number of users is 1000, the number of the obtained users currently watching anchor a is 1200, the number of the users watching anchor b is 500, and correspondingly, the number of the responses required to the request for obtaining the live data of anchor a exceeds the capability of responding in the AOF mode. Therefore, the live data of the anchor a is synchronously stored in the secondary Redis server in an RDB mode with high response speed and small file storage volume, and quick response can still be carried out when a large number of live data acquisition requests exist. And the number of responses required to obtain the live data of the anchor b is still within the coping capability of the AOF mode. Therefore, the live data of the anchor b is synchronously stored in the slave Redis server in the AOF mode with the slow response speed.
According to the optional implementation method, under the condition of poor network environment, according to the number of users watching the anchor currently, corresponding AOF or RDB modes are adopted for different user numbers. Compared with the method of directly adopting AOF or RDB, the method reasonably distributes the resources of the synchronous storage mechanism, so that the live broadcast system can still rapidly deal with the condition of a large amount of live broadcast data acquisition requests, and the user experience is effectively improved.
As shown in fig. 3, a flowchart of a live data obtaining method provided in an embodiment of the present invention is applied to the live system shown in fig. 1, and may include:
s301, receiving a live broadcast data acquisition request sent by each user client from the live broadcast server from the Redis server, and acquiring a live broadcast identifier in a live broadcast identifier set corresponding to a live broadcast identifier according to each anchor broadcast identifier in the live broadcast data acquisition request.
S302, according to the obtained live broadcast identifications, obtaining synchronously stored live broadcast data corresponding to the live broadcast identifications one by one, and sending the live broadcast data to the user client through the live broadcast server.
For example: receiving, from the direct broadcast server 101, a direct broadcast data acquisition request sent by each user client from the Redis server 103, and acquiring, according to each anchor identifier in the direct broadcast data acquisition request, a direct broadcast identifier in a direct broadcast identifier set corresponding to the anchor identifier, for example, if the user d, the user e watches the direct broadcast a1 of the anchor a, and the user f watches the direct broadcast B1 of the anchor B, then acquiring the direct broadcast identifier a1 in the direct broadcast identifier set RA of the anchor a, and the direct broadcast identifier B1 in the direct broadcast identifier set RB of the anchor B. And the Redis server 103 acquires synchronously stored live broadcast data corresponding to each live broadcast identification one by one according to the acquired live broadcast identification A1 and live broadcast identification B1, sends the live broadcast data A1 to the user client 106 and the user client 107 through the live broadcast server 101, and sends the live broadcast data B1 to the user client 108 through the live broadcast server 101.
The method for acquiring the live broadcast data comprises the steps of receiving a live broadcast data acquisition request sent by each user client from a live broadcast server through a Redis server, and acquiring live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to each anchor identifier in the live broadcast data acquisition request; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server. Compared with the traditional mode that the same live broadcast database server undertakes live broadcast data storage and responds to the live broadcast data acquisition request, the embodiment of the invention responds to the live broadcast data acquisition request from the Redis server to acquire the live broadcast data synchronously stored on the Redis server, can more effectively deal with high concurrency query, reduces the phenomena of performance reduction and jamming of the live broadcast database caused by the high concurrency query, and improves the user experience of the live broadcast service. In addition, the Redis server is a server for storing data in a Key-Value structure, and the Key-Value structure has excellent storage and query speeds, so that the quick storage and acquisition of live data can be ensured.
Optionally, in the embodiment shown in fig. 3, a live broadcast identifier set corresponding to the anchor identifier is an ordered set, where the live broadcast identifiers are stored in an order of live broadcast data receiving time.
The method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
and receiving current live broadcast data acquisition requests sent by the user clients from the live broadcast server from the Redis server.
And when the live broadcast identifications are stored according to the sequence from far to near of the live broadcast data receiving time, acquiring the live broadcast identification set corresponding to the anchor broadcast identification and storing the live broadcast identification at the last position in the live broadcast identification set according to each anchor broadcast identification in the live broadcast data acquisition request.
And when the live broadcast identifications are stored according to the sequence of the live broadcast data receiving time from near to far, acquiring the live broadcast identification set corresponding to the anchor broadcast identification and stored in the top live broadcast identification according to each anchor broadcast identification in the live broadcast data acquisition request.
For example: the current time is 2017, 9, 26, 20:05, and the receiving times of the 3-field live broadcast data of anchor a are respectively a 1: 20:00 at 12.9.2017, a 2: 9/2017, 19/20: 15, a 3: and 9 and 26 in 2017, 20:05, the current live broadcast is A3.
And receiving a current live broadcast data acquisition request for the anchor a from the Redis server from the live broadcast server, wherein the request is sent by a user client E. If the live identifiers are stored in the order of the receiving time from far to near, the current live identifier A3 must be stored at the end, i.e. the set RA of live identifiers of the anchor a ═ a1, a2, A3, then the live identifier at the end of direct acquisition must be A3. If the live identifiers are stored in the order of the receiving time from near to far, the current live identifier A3 must be stored at the top, i.e. the live identifier set RA of the anchor a is { A3, a2, a1}, and the live identifier directly obtained at the top must be A3.
It can be understood that the live broadcast identification is stored in the ordered set according to the sequence of the receiving time, so that when the Redis server receives the current live broadcast data acquisition request sent by each user client from the live broadcast server, the live broadcast identification at the fixed position in the ordered live broadcast identification set can be directly acquired without searching and comparing, the live broadcast identification can be acquired quickly, the time is saved for acquiring the live broadcast data according to the live broadcast identification subsequently, and the acquisition efficiency of the live broadcast data is further improved.
Optionally, the live broadcast identifier set corresponding to the anchor identifier further includes a time tag of each live broadcast identifier, where the time tag is used to distinguish the receiving time of each live broadcast data.
Correspondingly, the step of receiving, by the slave Redis server, a live data acquisition request sent by each user client from the live server, and acquiring, according to each anchor identifier in the live data acquisition request, a live identifier in a live identifier set corresponding to the anchor identifier may include:
and receiving a playback live broadcast data acquisition request sent by each user client from the live broadcast server from the Redis server.
And according to each anchor identification and the live broadcast time in the playback live broadcast data acquisition request, acquiring the live broadcast identification, of which the time tag corresponds to the live broadcast time in the playback live broadcast data acquisition request, in a live broadcast identification set corresponding to the anchor identification.
For example: the current time is 2017, 9, 26, 20: 05. The ordered live broadcast identifier set RA of the anchor a ═ { a1, a2, A3}, time labels of the live broadcast identifiers a1, a2, A3 are: 2017.9.12.20.00, 2017.9.19.20.15, 2017.9.26.20.05. And receiving a playback live broadcast data acquisition request sent by the user client D, E from the live broadcast server from the Redis server. The user client 106 requests to acquire the live broadcast data of the anchor a at 12: 00 in 2017, 9 and 12 months, and the user client 107 requests to acquire the live broadcast data of the anchor a at 20:15 in 2017, 9 and 19 months, 9 and 19 days, then the live broadcast identifications A1 and A2 corresponding to the time labels are acquired according to the time labels 2017.9.12.20.00 and 2017.9.19.20.15 corresponding to the requested live broadcast time.
Through the corresponding relation between the live broadcast data acquisition request and the time tags of the live broadcast identifications in the ordered live broadcast identification set, the method can accurately respond to the playback acquisition request of the user to the historical live broadcast data.
As shown in fig. 4, another schematic structural diagram of the live broadcasting system provided in the embodiment of the present invention may further include, compared with the live broadcasting system shown in fig. 1: a load balancing server 404; the number of the slave Redis servers can be multiple.
Correspondingly, the master Redis server 402 stores the stored live broadcast data and the live broadcast identification sets synchronously into each slave Redis server.
The live broadcast server 401 receives live broadcast data acquisition requests sent by the user clients, and forwards the live broadcast data acquisition requests to the load balancing server 404.
And the load balancing server 404, after receiving the live data acquisition request, determines the current load size of each slave Redis server, selects the slave Redis server with the smallest load as the current slave Redis server, and sends the received live data acquisition request to the current slave Redis server.
The current slave Redis server acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition request; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
Based on the live broadcast system shown in fig. 4, the process of acquiring live broadcast data may include the following steps:
firstly, a client sends a live broadcast data acquisition request to a live broadcast server;
step two, the live broadcast server forwards the received live broadcast data acquisition request to a load balancing server;
after receiving the live data acquisition request, the load balancing server judges the current load size of each slave Redis server, selects the slave Redis server with the minimum load as the current slave Redis server, and sends the received live data acquisition request to the current slave Redis server; the load balancing server determines the current load size of the Redis server according to the number of the live data acquisition requests currently received from the Redis server, wherein the larger the number of the received live data acquisition requests is, the larger the load is;
and step four, the current slave Redis server acquires the live broadcast identification in the live broadcast identification set corresponding to the anchor broadcast identification according to each anchor broadcast identification in the live broadcast data acquisition request, acquires the synchronously stored live broadcast data corresponding to each live broadcast identification one by one according to each acquired live broadcast identification, and sends the live broadcast data to the user client through the live broadcast server.
It should be noted that, in fig. 4, the client is connected to the live broadcast server in various ways. For example: if the client is a computer, the client can be connected with the live broadcast server through a wired network or a wireless network. The embodiment of the invention does not limit the connection mode of the client and the live broadcast server.
For example: the direct broadcasting system comprises a secondary Redis server 1, a secondary Redis server 2, … … and a secondary Redis server n, wherein n is a positive integer greater than or equal to 1. The master Redis server 402 synchronously transmits and stores the stored live data and the live identification set RA of the anchor a { a1}, and the live identification set RB of the anchor B { B1}, to the slave Redis server 1, the slave Redis server 2, and the slave Redis server n.
After receiving the live data acquisition requests of the anchor a sent by the user clients 408 and 409, the live data server 401 forwards the live data acquisition requests to the load balancing server 404. After receiving the live data acquisition request, the load balancing server 404 determines that the slave Redis server 1, the slave Redis servers 2 and … … and the current load size of the Redis server n are the same, and selects the slave Redis server with the smallest load as the current slave Redis server. If the current load capacity from the Redis server 1 is 10 live data acquisition requests, the current load capacity from the Redis server 2 is 20 live data acquisition requests, … …, and the current load capacity from the Redis server n is 16 live data acquisition requests. The current load from the Redis server 3 is the minimum, and 7 live data acquisition requests are provided. The slave Redis server 3 is selected as the current slave Redis server and the received live data acquisition request is sent to the current slave Redis server 3. After receiving the live data acquisition request from the Redis server 3, the live identification a1 in the live identification set RA corresponding to the live identification a is acquired according to the anchor identification a in the live data acquisition request, the anchor a live data corresponding to the live identification a1 and stored synchronously is acquired according to the acquired live identification a1, and the anchor a live data is sent to the user client 408, 409 through the live server 401.
In the live broadcast system shown in fig. 4, live broadcast data is synchronously stored in a plurality of slave Redis servers through a master Redis server, and the plurality of slave Redis servers are scheduled by a load balancer, so that the plurality of slave Redis servers respond to a live broadcast data acquisition request. Compared with the traditional mode that the same live broadcast database server undertakes live broadcast data storage and responds to the live broadcast data acquisition request, the embodiment of the invention not only responds to the live broadcast data acquisition request from the Redis server and acquires the live broadcast data synchronously stored on the Redis server, but also can more effectively deal with high concurrency query, reduce the phenomena of performance reduction and jamming of the live broadcast database caused by the high concurrency query and improve the user experience of the live broadcast service. Meanwhile, the tasks responding to the live data acquisition request are further shared by the multiple secondary Redis servers, and the service efficiency is further improved. And the slave Redis server with the minimum current load is selected by the load balancing server to respond to the live data acquisition request of the current user, namely the slave Redis server for data acquisition and transmission is in the best state in the current system, so that live data can be provided for the user as fast as possible, and the reduction of the live data acquisition speed caused by the fact that the same slave Redis server responds to too many live data acquisition requests is avoided. In addition, the Redis server is a server for storing data in a Key-Value structure, and the Key-Value structure has excellent storage and query speeds, so that the quick storage and acquisition of live data can be ensured.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk Sol identified State Disk (SSD)), among others.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.
Claims (9)
1. A live broadcast system, the system comprising:
the live broadcast server is used for receiving live broadcast data submitted by the live broadcast client of each anchor and sending the live broadcast data to the main Redis server;
the main Redis server is used for receiving live broadcast data submitted by each live broadcast client from the live broadcast server and obtaining anchor identifiers of each anchor and live broadcast identifiers of all live broadcasts of the same anchor from the live broadcast data; storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor; synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server;
the slave Redis server is used for receiving live broadcast data acquisition requests sent by all user clients from the live broadcast server and acquiring live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition requests; according to the obtained live broadcast identifications, live broadcast data which are synchronously stored and correspond to the live broadcast identifications one to one are obtained, and the live broadcast data are sent to the user client through the live broadcast server;
the step of synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server includes:
acquiring the current live broadcast data transmission rate of the live broadcast system;
if the transmission rate of the current live broadcast data is smaller than a preset data transmission rate threshold value, when the number of the currently watched users meets a preset condition, synchronously storing each live broadcast data in the master Redis server to the slave Redis server in an AOF mode;
if the current live data transmission rate is larger than or equal to a preset data transmission rate threshold, synchronously storing each live data in the master Redis server to the slave Redis server in an RDB mode;
and synchronously storing each live broadcast identification set in the master Redis server to the slave Redis server in an RDB mode.
2. The system of claim 1, the live system further comprising: a load balancing server; the number of the secondary Redis servers is multiple;
the master Redis server synchronously stores each stored live broadcast data and each live broadcast identification set into each slave Redis server;
the live broadcast server receives live broadcast data acquisition requests sent by the user clients and forwards the live broadcast data acquisition requests to the load balancing server;
the load balancing server judges the current load size of each slave Redis server after receiving the live data acquisition request, and selects the slave Redis server with the minimum load as the current slave Redis server; sending the received live broadcast data acquisition request to the current slave Redis server;
the current slave Redis server acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition request; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
3. A method for storing live data, applied to the live system of claim 1, the method comprising:
a master Redis server receives the live broadcast data sent by a live broadcast server, and acquires the anchor identification of each anchor and the live broadcast identification of each live broadcast of the same anchor from the live broadcast data;
storing the live broadcast data, and storing each live broadcast identification in a live broadcast identification set corresponding to the anchor;
synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server;
the step of synchronously storing each stored live broadcast data and each live broadcast identification set into a secondary Redis server includes:
acquiring the current live broadcast data transmission rate of the live broadcast system;
if the transmission rate of the current live broadcast data is smaller than a preset data transmission rate threshold value, acquiring the number of users watching each anchor live broadcast currently;
if the number of users watching the corresponding anchor is larger than or equal to a preset user number threshold, synchronously storing live broadcast data of the corresponding anchor in a master Redis server into a slave Redis server in an RDB mode;
and if the number of the users watching the corresponding anchor is smaller than a preset user number threshold value, synchronously storing the live broadcast data of the corresponding anchor in the master Redis server to the slave Redis server in an AOF mode.
4. The storage method according to claim 3, wherein the step of storing each live broadcast identifier in a live broadcast identifier set of a corresponding anchor comprises:
and storing each live broadcast identifier in an ordered live broadcast identifier set of a corresponding main broadcast in a main Redis server according to a receiving time sequence, and taking the receiving time as a time label of each live broadcast identifier in the live broadcast identifier set.
5. The storage method according to claim 3, wherein after said obtaining a current live data transfer rate of the live system, the method further comprises:
if the current live data transmission rate is larger than or equal to a preset data transmission rate threshold, synchronously storing each live data in the master Redis server to the slave Redis server in an RDB mode;
and synchronously storing each live broadcast identification set in the master Redis server to the slave Redis server in an RDB mode.
6. A live data acquisition method applied to the live system of claim 1, the method comprising:
receiving a live broadcast data acquisition request sent by each user client from a live broadcast server from a Redis server, and acquiring live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to each anchor identifier in the live broadcast data acquisition request;
according to the obtained live broadcast identifications, live broadcast data which are synchronously stored and correspond to the live broadcast identifications one to one are obtained, and the live broadcast data are sent to the user client through the live broadcast server;
the live broadcast identification set and the live broadcast data are synchronously stored in the secondary Redis server by adopting the following steps:
acquiring the current live broadcast data transmission rate of the live broadcast system;
if the transmission rate of the current live broadcast data is smaller than a preset data transmission rate threshold value, acquiring the number of users watching each anchor live broadcast currently;
if the number of users watching the corresponding anchor is larger than or equal to a preset user number threshold, synchronously storing live broadcast data of the corresponding anchor in a master Redis server into a slave Redis server in an RDB mode;
and if the number of the users watching the corresponding anchor is smaller than a preset user number threshold value, synchronously storing the live broadcast data of the corresponding anchor in the master Redis server to the slave Redis server in an AOF mode.
7. The acquisition method according to claim 6, wherein the live broadcast identification set corresponding to the anchor identification is an ordered set, and the live broadcast identifications are stored in the order of the live broadcast data receiving time;
the method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
receiving current live broadcast data acquisition requests sent by user clients from a Redis server from the live broadcast server;
when the live broadcast identifications are stored according to the sequence from far to near of the live broadcast data receiving time, acquiring live broadcast identifications stored at the last position in a live broadcast identification set corresponding to the live broadcast identifications according to each anchor identification in the live broadcast data acquisition request;
and when the live broadcast identifications are stored according to the sequence of the live broadcast data receiving time from near to far, acquiring the live broadcast identification set corresponding to the anchor broadcast identification and stored in the top live broadcast identification according to each anchor broadcast identification in the live broadcast data acquisition request.
8. The acquisition method according to claim 7, wherein a live broadcast identifier set corresponding to the anchor identifier further includes: the time labels of the live broadcast identifications are used for distinguishing the receiving time of the live broadcast data;
the method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
receiving a playback live broadcast data acquisition request sent by each user client from a Redis server from the live broadcast server;
and according to each anchor identification and the live broadcast time in the playback live broadcast data acquisition request, acquiring the live broadcast identification, of which the time tag corresponds to the live broadcast time in the playback live broadcast data acquisition request, in a live broadcast identification set corresponding to the anchor identification.
9. The acquisition method according to claim 6, wherein the live broadcast system further comprises: a load balancing server; the number of the slave Redis servers is multiple;
the method comprises the following steps that the slave Redis server receives live broadcast data acquisition requests sent by user clients from the live broadcast server, and acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the anchor broadcast identifiers in the live broadcast data acquisition requests, wherein the steps comprise:
after receiving a live data acquisition request sent by each user client from the live server, the load balancing server judges the current load size of each slave Redis server, and selects the slave Redis server with the minimum load as the current slave Redis server; sending the received live broadcast data acquisition requests sent by the user clients to the current slave Redis server;
the current slave Redis server acquires live broadcast identifiers in a live broadcast identifier set corresponding to the live broadcast identifiers according to the live broadcast identifiers in the live broadcast data acquisition request; and according to the obtained live broadcast identifications, obtaining the synchronously stored live broadcast data corresponding to the live broadcast identifications one to one, and sending the live broadcast data to the user client through the live broadcast server.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711475368.3A CN108235051B (en) | 2017-12-29 | 2017-12-29 | Live broadcast system and method for storing and acquiring live broadcast data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711475368.3A CN108235051B (en) | 2017-12-29 | 2017-12-29 | Live broadcast system and method for storing and acquiring live broadcast data |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108235051A CN108235051A (en) | 2018-06-29 |
| CN108235051B true CN108235051B (en) | 2020-08-21 |
Family
ID=62646913
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711475368.3A Active CN108235051B (en) | 2017-12-29 | 2017-12-29 | Live broadcast system and method for storing and acquiring live broadcast data |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108235051B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109660816B (en) * | 2018-11-16 | 2021-09-28 | 视联动力信息技术股份有限公司 | Information processing method and device |
| CN109636514B (en) * | 2018-11-29 | 2021-06-25 | 腾讯科技（深圳）有限公司 | Business data processing method and device, computing equipment and storage medium |
| CN111026764B (en) * | 2019-12-13 | 2023-08-11 | 上海米哈游网络科技股份有限公司 | Data storage method and device, electronic product and storage medium |
| CN115314718B (en) * | 2021-05-07 | 2023-07-14 | 北京字节跳动网络技术有限公司 | Live broadcast data processing method, device, equipment and medium |
| CN113381990B (en) * | 2021-06-03 | 2022-06-10 | 湖南快乐阳光互动娱乐传媒有限公司 | Method and system for intercommunication between on-demand terminals |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102880529A (en) * | 2012-09-13 | 2013-01-16 | 新浪网技术(中国)有限公司 | Memory data backup method and memory data backup system |
| CN104580294A (en) * | 2013-10-16 | 2015-04-29 | 博雅网络游戏开发（深圳）有限公司 | Method and device for displaying server information |
| CN104881494A (en) * | 2015-06-12 | 2015-09-02 | 北京奇虎科技有限公司 | Method, device and system for performing data synchronization with Redis server |
| CN106330967A (en) * | 2016-10-24 | 2017-01-11 | 北京小米移动软件有限公司 | Processing method and device of live broadcast data processing |
| CN106385411A (en) * | 2016-09-12 | 2017-02-08 | 福建中金在线信息科技有限公司 | Network broadcast data display method and device |
| CN106488263A (en) * | 2016-10-24 | 2017-03-08 | 北京小米移动软件有限公司 | Push the method and device of live broadcast stream media data |
| CN107153674A (en) * | 2017-03-30 | 2017-09-12 | 武汉斗鱼网络科技有限公司 | A kind of live room information methods of exhibiting and system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10334302B2 (en) * | 2015-10-08 | 2019-06-25 | Synamedia Limited | Method and system for segment based recording |
-
2017
- 2017-12-29 CN CN201711475368.3A patent/CN108235051B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102880529A (en) * | 2012-09-13 | 2013-01-16 | 新浪网技术(中国)有限公司 | Memory data backup method and memory data backup system |
| CN104580294A (en) * | 2013-10-16 | 2015-04-29 | 博雅网络游戏开发（深圳）有限公司 | Method and device for displaying server information |
| CN104881494A (en) * | 2015-06-12 | 2015-09-02 | 北京奇虎科技有限公司 | Method, device and system for performing data synchronization with Redis server |
| CN106385411A (en) * | 2016-09-12 | 2017-02-08 | 福建中金在线信息科技有限公司 | Network broadcast data display method and device |
| CN106330967A (en) * | 2016-10-24 | 2017-01-11 | 北京小米移动软件有限公司 | Processing method and device of live broadcast data processing |
| CN106488263A (en) * | 2016-10-24 | 2017-03-08 | 北京小米移动软件有限公司 | Push the method and device of live broadcast stream media data |
| CN107153674A (en) * | 2017-03-30 | 2017-09-12 | 武汉斗鱼网络科技有限公司 | A kind of live room information methods of exhibiting and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108235051A (en) | 2018-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108235051B (en) | Live broadcast system and method for storing and acquiring live broadcast data | |
| US10764369B2 (en) | Data storage method and server applicable to distributed server cluster | |
| CN107943594B (en) | Data acquisition method and device | |
| US20200336769A1 (en) | Video Live Broadcast Method and Apparatus | |
| US20140165119A1 (en) | Offline download method, multimedia file download method and system thereof | |
| US9215569B2 (en) | Broadcast media content to subscriber group | |
| US10891302B2 (en) | Scalable synchronization with cache and index management | |
| CN112445626B (en) | Data processing method and device based on message middleware | |
| EP2897368B1 (en) | Interactive personal/internet protocol television subscription system, and subscription plan management method and device | |
| CN111277847B (en) | Method, device, server and system for displaying chat messages in live broadcast | |
| CN104348859B (en) | File synchronisation method, device, server, terminal and system | |
| CN103516585A (en) | Method and system for distributing messages according to priorities | |
| US11588890B2 (en) | System, method and apparatus having a redundant cluster for processing data | |
| CN103312593B (en) | A kind of message distributing system and method | |
| WO2015172497A1 (en) | Message pushing and acquisition methods and devices, and computer readable storage medium | |
| CN108063832B (en) | Cloud storage system and storage method thereof | |
| CN110798495B (en) | Method and server for end-to-end message push in cluster architecture mode | |
| US10204110B2 (en) | Method and system for deleting obsolete files from a file system | |
| CN110798492B (en) | Data storage method and device and data processing system | |
| CN114422591B (en) | Point-to-point communication method, data communication system, computer device, and storage medium | |
| CN113965538B (en) | Equipment state message processing method, device and storage medium | |
| CN106210779B (en) | Optimize the method and system of internet video live broadcasting data hierarchy transmission | |
| CN107171820B (en) | Information transmission, sending and acquisition method and device | |
| CN115082038A (en) | System integration method and device and electronic equipment | |
| CN108805741B (en) | Fusion method, device and system of power quality data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |