内容大纲
Live stream repeater 是如何工作的?
Live stream repeater 的两种工作模式
两种工作模式的比较
Live stream repeater 是如何工作的?
一个最简单的Wowza Live stream repeater架构下包含两个部分：一个Origin服务器，一个Edge服务器。 比如，编码器这种直播源直接将视频流推送到Origin服务器上，或者在一个独立的Wowza服务器上启用Transcoder后重新编码而作为直播源。 然后，播放端的用户访问边缘服务器来获取这个直播流。
Live stream repeater技术在origin服务器和edge服务器之间使用专有的WOWZ™ 协议，将Origin服务器上的流以正确的格式拉到Edge服务器上。
在一个Live stream repeater 架构下，对于一路直播流而言，不管有多少并发用户，每一种客户端的播放技术(协议)只会在Edge和Origin之间产生一个连接。 这非常重要，它显著地降低了对Origin服务器的压力。
对于一个已有的Wowza Streaming Engine™直播(Live)应用而言，它不需要任何额外的设置，就可以被当作一个Live stream repeater架构下的Origin服务器。如果是作为一个Edge服务器，则需要一些简单的额外配置。 如果有多台Edge服务器，则你还需要为它们配置负载均衡功能。
Live stream repeater依赖于Wowza服务器从外部拉流进入Wowza的技术，因此在这里顺便说一下这个"从外部拉流"：
"从外部拉流"有两种工作模式
"从外部拉流"有两种工作模式，1、按需拉流。 2、持久拉流。
一、按需拉流(On demand mode)
当你把Wowza Streaming Engine配置为一个Live Edge类型的应用时，你使用的就是默认的按需拉流模式(On demand mode)。因为只有用户实际访问了Edge，Edge才知道要拉哪个流进来。在这个模式下，当用户播放器向Edge服务器发起请求一个直播流时，Edge服务器才会建立起与Origin服务器之间的连接。而当用户请求的暂停后(一段时间没有任何用户请求这个流了) ，这个连接又会自动断开。 对于这一路流，每一个播放器技术/协议(RTMP 或者是 HTTP 类型)，在Edge服务器和Origin服务器之间都只会建立一个连接。比如，对于RTMP协议，它是一个连接，对于不同的HTTP类型(HLS、HDS、DASH等)也有不同的HTTP连接(因为数据打包格式不同)。
Live Edge应用被设计为只能从Origin直播应用(普通的Live应用)获得直播流，因此，HTTP流的打包实际都是在Origin服务器上完成的，也就是说关于HTTP切片的相关设置必须在Origin服务器上配置。
在这个模式下，由于直播流是按需从Origin拉取的，因此你不能将直播流的录制、转码的任务放在Edge服务器上。 如果你确实有这个需求，请在一个单独的服务器或Origin服务器上实现做这个工作。
此外，你的编码器或推流客户端也不能直接向Edge服务器推流，因为所有对Edge服务器的访问，都将导致Edge只到Origin服务器上拉流。 在Wowza Streaming Engine上为Edge 应用配置一个URL来访问Origin服务器上的流是非常简单的。 这意味你在Edge上的Wowza Streaming Engine 不用了解Origin应用上的流是如何实现的，只管去拉取客户端播放器需要的流即可。
注意：Wowza Streaming Engine上的Stream File技术也可以为每一个流实现这个功能。它被Wowza称之为"MediaCaster"技术，这个Stream file功能可以工作在按需拉流的模式下，也可以工作在持久拉流的模式下。具体是哪种模式，依据StreamType的配置来决定。
二、持久拉流模式(Persistent mode)
持久拉流模式(Persistent mode)是Wowza服务器持久性的从外部拉取一个视频流进入Wowza服务器。它不依赖于用户的请求。也就是说不管用户是否请求了这个流，它都会从外部 拉取这个流。
我们知道Wowza管理界面上的Stream File技术可以用来从外部拉流，它即可以在按需拉流模式下工作，也可以在持久拉流模式下工作。
比如，当你将这个Stream File中的流配置到Startup streams中，当服务器启动后，它就开始拉流。也就是说它随Wowza服务器的启动而启动，跟用户访问无关。
再比如，当你在Wowza管理界面上Stream File列表界面点击"连接"icon，将这个流连接到某一个Application时，它就开始拉流，也与用户访问无关。
但是，如果你将这个Application的Stream Type设置为"rtp-live"时，就可以支持按需拉流了。也就是说，这时你不用将这个stream file中定义的流连接到某一个Application， 也不用将它添加到Startup streams中，你只要访问这流，它会自动被加载到你请求的Application中，并自动从外部拉流。你停止播放后，它就会停止拉流。
在采用Stream File方式进行拉流时，对于一路直播流的所有用户播放器技术/协议而言，Edge服务器和外部的服务器之间只有一个连接(Stream File中配置的URL对应的连接类型，这和前面Live repeater技术是不一样的)。
两种工作模式的比较
1、对于这两种模式，相同的一点是，当Edge服务器与Origin服务器断开连接后，Edge服务器会继续尝试建立与Origin服务器的连接。 在按需访问模式下(On demand mode)，当你使用Live repeater技术时，如果你在Edge服务器上配置了多个源流(Origin上的流)的URL，那么Edge应用就会按顺序轮询访问这每一个源流的URL，直到可以正常拉取到这个流。
2、按需访问模式(On demand mode)下的Live repeater的配置很简单，如果Origin 服务器已经正常启动，你只需要在Edge服务器上创建Live Edge 类型的应用，然后配置它连接Origin 服务器上的Live应用，然后由播放器来访问Edge服务器即可。 相反，持久访问模式(Persistent mode)下，在播放器访问一个stream file中定义的流时，Wowza服务器必须先从外部将流拉取进来。
3、在按需访问模式(On demand mode)下，当播放器建立与Edge服务器的HTTP访问连接时，每一个Edge服务器从Origin服务器上获得都是完全同样的流切片数据，因为前面说过，这种模式下的Http切片打包是在Origin上完成的。 因此，当播放器的请求从一个Edge服务器切换到另一个Edge服务器时，完全可以实现平滑无缝的切换。 但在持久访问模式(Persistent mode)下，每一个Edge服务器都是自己实现HTTP流的切片打包的，当播放器的请求从一个Edge服务器切换到另一个Edge服务器上时就可能出现一个短暂的中断(不连贯)。
4、由于按需访问模式(On demand mode)下，如果您使用Live repeater技术，那么针对每一个播放器技术/协议都会建立一个Edge与Origin之间的连接，这样，就在Edge与Orgin之间占用的带宽而言，在一开始，它会比持久模式(Persistent mode)更多一些。但是，另一方面，在一段时间之后，按需访问模式(On demand mode)由于会伴随所有客户端播放器的逐渐停止访问(直到没有任何用户访问)而停止到Origin拉流又会减少对带宽的占用。 所以，如果多种不同的播放技术/协议会长时间地持续播放，那么持久访问模式(Persistent mode)会更节约带宽(当然，这说的是Edge和Origin之间的带宽)。