[Question] - Huge Live stream architecture

[hamidreza-hosseini]

Hi,
I wanna Deploy a big cluster of SRS (Now I'm considering scalability for the next 10 years )
I was thinking about the following Architecture:

Client is publishing Stream B on origin servers and origin servers are sending this stream to 3 servers (server A,B,C)
If in the middle of streaming event , the number of clients became more than bandwidth of this 3 servers (for instace, with 10Gb NIC on each server and 2mb bandwidth of each stream I can just handle 5000 stream for playback)
So for this 3 servers I can just handle specific number of live stream playback and I don't know which stream would have more clients for playback to push it to 5 server or more
Can SRS handle this problem dynamically?
What is best solution to solve this issue?

[winlinvip]

For a long-term live-streaming system arch, generally the CDN arch:

1. Server A,B,C is not a server, it's servers or region. The region A,B,C contains more than one servers. And there is only one stream between an origin and edge server, whatever how many players on edge server.
2. The edge cluster is design for huge players, for example, Origin(1 player) => Edges(each 100 players) => Edges(each 1000 streams), which serves at most 100*1000=100k players, and there is only one player to fetch stream from origin server.
3. The origin cluster is design for huge streams(publishers), where each publisher publish one stream to origin. You should implements the query API for origin server, which is implemented as a mesh network between origin servers(which query each other about the stream information).

Please try this arch, do some research and demos. And bellow is about the load balance, and never forget the scalability of system depends on GSLB first, not only about media servers:

1. Create multiple origin-edge clusters, where GSLB can dispatch client to different origin-edge cluster, for example, by url hash, the client which play x://xxx/x/x is dispatched to cluster A, and client plays y://yyy/y is dispatched to cluster B.
2. The GSLS is only a load balance API, for example, an HTTP RESTful API, to get the server to publish or play.
3. The common tech for GSLB is DNS or HTTP-DNS, please do some research.

And please consider about WebRTC and meeting system, which is supported by SRS 4.0, it's not the same arch as we discussed, and we're developing the cluster for RTC, please read #2091