幽雨雨幽

, Benjamin当我们的业务超过单台流媒体服务器的承受能力，就会遇到负载均衡问题，一般我们会在集群中提供这种能力，但实际上集群并非是唯一的实现方式。有时候负载均衡还会和服务发现等时髦词汇联系起来，而云服务的LoadBalancer无疑是不可回避，因此，这个问题其实相当复杂，以致于大家会在多个场合询问这个问题，我打算系统的阐述这个问题。好吧，让我们详细聊聊负载和负载均衡。

publish的流和play的流怎么连接呢？这个恐怕是最绕的地方了。看了一上午的代码，淹没于各种数据结构与流程之中后，俺终于发现了连接publish和play的关键连个类是SrsSourceSrsConsumer负责连接着连个类实例的是SrsRtmpConn 下面我们详细讲解连接过程上片我们说到。在底层客户端连接上来后，会经过

librtmp是一个客户端库，好像是rtmpdump提供的一个客户端RTMP库。应用场景librtmp的主要应用场景包括：播放RTMP流：譬如rtmpdump，将服务器的流读取后保存为flv文件。推流：提供推流到RTMP服务器。基于同步阻塞socket，客户端用可以了。arm：编译出来给arm-linux用，譬如某些设备上，采集后推送到RTMP服务器。不支持直接发布h.26

SRS提供了一系列工具来定位性能瓶颈和内存泄漏，这些在./configure && make后的summary中是有给出来用法的，不过不是很方便，所以特地把用法写到这个文章中。文中所有的工具，对于其他的linux程序也是有用的。备注：所有工具用起来都会导致SRS性能低下，所以除非是排查问题，否则不要开启这些选项。GPERFGPERF是google tcmal

单进程SRS支持7.5k并发，如果单机需要单机100K并发，可以使用多进程SRS，即SRS-DOLPHIN。目前测试SRS-DOLPHIN的测试数据是20K并发，理论上多进程的扩展性可以到达任意并发，只要你的CPU和网卡还有交换机够。而SRS-DOLPHIN不仅仅是高并发，还可以做容错，提高稳定性。只需要修改启动命令，兼容单进程的配置文件。SRS为何做进程？有三个主要的因素：

SRS(simple-rtmp-server)流媒体服务器源码分析--系统启动一、前言       小卒最近看SRS源码，随手写下博客，其一为了整理思路，其二也是为日后翻看方便。如果不足之处，请指教！首先总结一下SRS源码的优点：       1、轻量级，代码结构清楚，目前SRS3.0代码8万行左右，但几乎满足直播业务的所有要求。       2、SRS采用St

协程库state threads library(以下简称st)是一个基于setjmp/longjmp实现的C语言版用户线程库或协程库（user level thread）。这里有一个基本的协程例子 http://www.csl.mtu.edu/cs4411.ck/www/NOTES/non-local-goto/coroutine.html， 可以了解setjmp和longjmp的基

st(state-threads) https://github.com/winlinvip/state-threads以及基于st的RTMP/HLS服务器：https://github.com/winlinvip/simple-rtmp-serverst是实现了coroutine的一套机制，即用户态线程，或者叫做协程。将epoll（async，nonblocking socket

译文在后面；代码我放在GITHUB了：http://github.com/ossrs/state-threads。State Threads for Internet ApplicationsIntroductionState Threads is an application library which provides a foundation for writing

State Threads是一个广受关注的高性能网络线程库，winlin在SRS中做了比较充分的应用，我很遗憾直到现在才精心研究它。下面是我的研究实录，以作备忘。一、源码编译下面是在Ubuntu 14.04 64bit上面的实操记录：从官网http://sourceforge.net/projects/state-threads/下载源码包，最新版是1.9，如果不能下载，就

代码阅读到现在。发现srs有两大类线程。一个是主线程的逻辑。一个是监听线程簇。结构图如下一定还有第三种线程模型，负责底层的多路分发。今天还没有发现。2016.08.25--21:00仔细阅读了state-threads的介绍，特别是setjmp()和longjmp（）函数，发现了一下代码

一、采集SRS支持两种方式得到RTMP直播源。一种是使用FFmpeg， 设备或其它方式将流推送到SRS。另一种方式是SRS本身带采集功能。采集(Ingest)指的是将文件（flv，mp4，mkv，avi，rmvb等等），流（RTMP，RTMPT，RTMPS，RTSP，HTTP，HLS等等），设备等的数据，转封装为RTMP流（若编码不是h264/aac则需要转码），推

srs的服务侦听的建立过程。以rtmp服务为例 srs服务侦听的建立依靠从上到下的三个类。分别是SrsServer  SrsStreamListener  SrsTcpListener端口侦听过程为1）main函数中调用全局变量_srs_server的  listen（）函数[cpp] view plain

一、编译SRS https://github.com/winlinvip/simple-rtmp-server 目前有1.0-release、2.0、3.0等版本 2.0官方文档地址：https://github.com/winlinvip/simple-rtmp-server/wiki/v2_CN_Home1.如果是新系统，先安装gitCentOS：yum -y inst

rtmp 1.0规范中，指定了RTMP的握手协议：c0/s0：一个字节，说明是明文还是加密。c1/s1: 1536字节，4字节时间，4字节0x00，1528字节随机数c2/s2: 1536字节，4字节时间1，4字节时间2，1528随机数和s1相同。 这个就是srs以及其他开源软件所谓的simple handshake，简单握手，标准握手，FMLE也是使用这个握手协议。Flash播放

SRS(Simple Rtmp Server)单进程能支持9000并发，nginx-rtmp单进程最多支持3000个，单进程的性能SRS(Simple Rtmp Server)是nginx-rtmp的三倍。SRS(Simple Rtmp Server)单进程性能如何做到nginx-rtmp的三倍的？SRS(Simple Rtmp Server)哪几个结构极大提升了性能？先来看看我们遇到的问题，

SRS_WORKDIR="."SRS_OBJS_DIR="objs"SRS_OBJS="${SRS_WORKDIR}/${SRS_OBJS_DIR}"# 设置输出目录 ./objsSRS_MAKEFILE="Makefile". auto/options.sh# ---- options.sh 主要代码段 begin -------opt=# f

C/C++中内存是一个很难处理的事情，正如强项就是弱项，强大的地方也是致命的地方。内存不释放就会泄漏，多次释放就会段错误，越界更恐怖。不释放和多次释放都可以用SrsAutoFree规避，越界就需要工具和经验的问题。释放和多次释放，原因是内存或者对象的生命周期过程，譬如在一个while循环中，有些时候要释放，有些时候continue就好，就容易出问题。真的需要活N久的

h.264裸码流的格式，参考“H.264-AVC-ISO_IEC_14496-10.pdf, page 211.”，这个文档的下载地址：https://github.com/winlinvip/simple-rtmp-server/tree/develop/trunk/doc/H.264-AVC-ISO_IEC_14496-10.pdf一个录制的h.264裸码流文件：http://winl

RTMP的url其实很简单，vhost其实也没有什么新的概念，但是对于没有使用过的同学来讲，还是很容易混淆。几乎每个新人都必问的问题：RTMP那个URL推流时应该填什么，什么是vhost，什么是app？RTMP和HLS的优势参考：HLS应用场景Vhost的主要应用场景包括：一个分发网络支持多个客户：譬如CDN，一个分发网络中，有N个客户公用一套流媒体系统，如何区分用