有效降低RealServer服务中的客户缓冲现象之二

用了单机多服务的模式后，许多人觉得管理麻烦多了，需要有许多设置，尤其是重做系统或添加新的服务器后，其实可以快速克隆服务的，具体方法如下。

    1、规划你的加载点，2000及其后续操作系统允许你编辑盘符。所以以我的例子说明，我把 G: H:盘对应为电影的2个发布点mov1和mov2，不论有多少硬盘，始终把电影盘修改为这2个盘符。Helix始终安装在 C:/program files/real/Helix server的默认路径下。



    2、安装好第一个服务，进入Helix管理，完整配置好全部的参数设置。

    3、保存好.cfg配置,我的是rm1.cfg

    4、进入bin目录，复制rmserever.exe为 rmserever1.exe rmserever2.exe等等，你准备安装几个服务就复制几个。

    5、安上面的方法注册多服务(可以做个bat文件集中注册)，然后进入注册表，更正.cfg的路径，同时也修改启动的程序分别为rmserever1.exe  rmserever2.exe 等等。这样的目的是在任务管理其中你能知道是第几个rmserever.exe的运行情况，否则进程名全是rmserever.exe，弄不清谁是谁了。

    6、试运行全部正常后，把system32下的 pncrt.dll 文件复制到Helix的bin目录下。



    现在好了，复制整个Helix Server目录作为备份。



    当你重做系统后，只要仍设定G: H:盘对应为电影的2个发布点mov1和mov2，把备份的Helix Server目录复制到C:/program files下，运行多个注册服务，更正注册表后，Helix就正常工作了。如果是新机器，只要遵循了预先设定的发布点盘符，也用复制的方法完成安装，这样就大大地减少了工作强度。



   技巧：最好备份好正常运行的.cfg文件，你是否遇到若干次配置helixServer后突然启动不正常，或者管理页面进不去，通常都是因为.cfg文件格式更改的缘故，只要你用备份的cfg文件覆盖后，在服务管理里重新启动服务，一切就都正常了。





纯数据库系统和文件系统的对比 





    所有的点播系统都是基于数据库系统的，毫无疑问数据库的优点是易于检索，还有人认为数据库便于分类索引，然而实际上，当你完全依赖数据库时会发现有诸多弊端，尤其是拥有多台点播服务器时。

    总体说来单纯使用数据库的缺点有：

    1、对技术人员的素质要求较高，建库时录入的数据量大，容易出错。

    2、不宜进行移动和删除操作，因为要涉及实际物理位置的变动。

    3、媒体物理发生变化时，数据库的更新较困难。

    4、数据库崩溃后，恢复的难度大。

    5、当某台媒体服务器的硬盘发生故障，数据库不会得到更新，产生死链。

    总之，由于先有物理信息，后再人为添加数据库信息，一旦其步伐没有跟上物理位置的变化，时间稍一常你就不知道数据库中信息的真实性了。

    产生这样的原因是在于工作方式，因为你的媒体地址往往形如 rtsp://某台服务器/路径/媒体.rm，录入时通常先将媒体复制或移动到某台服务器的某处位置，然后由管理员来录入位置索引。一旦你要移动、添加、删除、更新媒体时，必须要求管理员立刻更新数据库，稍有滞后、遗忘就会造成数据失真，过后很难复查。再有如果你有多台服务器，总会有发生故障的时候，一旦大量的物理位置发生变化，如何更新数据库就是很棘手的问题。另外我注意到大多数的媒体点播地址都形如 rtsp://你的服务器地址/GuoCaiMovie/SX/01.rm 这样的英文路径，如果你失去了数据库索引，硬盘上一大堆的 01.rm 02.rm ... ，恐怕你都不知道是什么东西了，所以这样的管理直观性差。



    为此我推荐使用基于文件系统的点播，数据库仅作为辅助检索的工具，录入全部由程序根据规格化的文件系统来完成，数据是单向流，只能从物理地址的变化，反映到数据库中去，而不是修改数据库中的数据，然后再更改物理信息。

    在拥有多台点播服务器时，不是采用通常的由中心点播WEB服务器集中生成连接。例如检索到媒体后，根据数据库数据形成如 rtsp://服务器B/路径/媒体.rm ，然而如果此时恰好服务器B因故维修呢，或者是发生永久性故障呢，或者路径发生了变更，用户就会找不到文件。也许有人会说可以采用备份，的确可以，不过这样的成本不菲，不知道有多少人采用了。反正我没有采用，即使坏一块硬盘也只占总数的1/10不到，而且通常是1，2年前的数据，不是很可惜。

    不论你采用何种方式，你首先要将媒体文件放置到设定的位置，所以最底层的就是文件系统。我在点播时，仅在主页配合的数据库中检索到对应的播放主机和路径，然后把播放的处理权移交到播放服务器，在移交之前会检查一下该播放服务是否正常，如不正常就不会移交。实际上我在检索服务器时就进行了检查，这样用户得到的始终是正常运行机器的数据，他感觉不到后台的故障维护。这样每一台播放服务器都是各自独立的，而且它们和数据库无关，任意拿走一台都不会影响到整个系统，对于扩充和删减十分方便，一旦中心机瘫痪，用户可临时访问各个播放服务器，临时提供播放服务。播放服务器接受播放任务后，根据传递的路径，找到本地的xml数据，形成播放连接。

    这样只要稍懂计算机的人，帮你把电影文件以汉字命名后扔到同样是汉字的目录中，其他都由程序作了，大大降低了维护的复杂性。



    具体的做法如下：

    一台中心机，用于主页WEB+数据库，若干台点播服务器，如果你只有一台点播服务器也可以和中心机和用，只不过我的方案对于拥有多台点播服务器的更为理想。

    点播服务器具有相同的结构，每块硬盘可以做个发布点，例如在 G盘(80-120G) 建立一个movie目录，同时也把它设为Web目录，虚目录为mov1。在movie目录下建立媒体目录，如mov1，当然也可以myMovie等等。然后再建立分类目录，如 动作片，伦理片，枪战片等等，一定要用汉字这样比较直观。之下你可以建立二级分类，然后是电影目录。要点是你要有统一的规则，要用汉字，这样便于其他人员协助管理。

    有了这样的文件结构，你可以编制Aspx服务程序了，主要功能有根据目录自动显示分类菜单，显示存在的媒体目录，生成点播路径，用户只要一点击就可以浏览了。这样一台独立的媒体播放服务器就完成了，当然为了完善功能还需要有自动扫描程序，每个电影媒体的信息做成xml文件保存在自己的目录下。当这块硬盘任意移动到新的机器上时，或者有目录改变时，只需用程序描xml文件，并对数据库进行更新，就可以记录播放机的地址和电影路径。我的xml文件结构示例：

<?xml version="1.0" enco****="gb2312"?>

<基本信息 xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

  <片名 索引="1104">  对应数据库中的ID，便于检索更新

    <正名>太阳的眼泪</正名> 电影名也是目录名

    <别名>tydyl Tear of sun</别名>

  </片名>

  <导演 索引="0">

    <正名 />

    <别名 />

  </导演>

  <演员 索引="17">

    <正名 />

    <别名>Jet Li llj Bridget Fonda Tcheky Karyo</别名>

  </演员>

  <日期>2003-04-18T00:00:00.0000000+08:00</日期>

  <基本信息 索引="12" 关键字="">

    <类型>/动作90分/危险使命</类型> 和电影名一起合成播放地址

    <级别 />

    <出版 />

    <版权 />

    <带宽>450K</带宽>

    <编码>RealVideo 9</编码>

    <集数>1</集数>

  </基本信息>

  <简介>　 《太阳的眼泪》(Tears of The Sun，暂译)：明年3月上映的惊险动作片，布鲁斯?威利斯领导的美国海军陆战队奉命潜入非洲丛林营救一名美丽的女医生(由意大利女星莫妮卡?贝鲁奇扮演)，不料她坚持除非其他70名人质都得到释放，否则绝不离开，于是这场营救行动变得愈加艰难起来……影片由《训练日》的导演安东尼?福奎阿执导，索尼旗下的革命电影公司负责发行.

</简介>

  <备注 />

  <累计>6407</累计>

</基本信息>



    规避下载风险：你会发现这样做的缺点是电影目录位于Web目录下，如果猜出了你的路径，就可以http下载了。你可以用vb,pb等作个简单的无界面exe程序，比如一运行就退出，然后在IIS的映射配置中，添加.rm .rmvb .asf等的映射，指定为你的exe程序，他人下载会得不到正确处理，提示找不到网页。

媒体点播中的路由控制 





    为啥需要路由控制呢，举例说明吧，我自己有个小区宽带网，用户是192.168.1.2这样的地址，我为了给自己用户提供上网，要有出口呀，比如是网通的 202.99.1.2(网关202.99.1.1/255.255.255.240)。为了有备份又和电信的219.148.1.2(网关219.148.1.1/255.255.255.240)有接口，还有铁通的220.148.1.2。你看这样我的机器上就有了4块网卡，分别是自己的、网通、电信和铁通。(注：此处我以虚构的说明来说明问题，实际上你可能是其它类型的网络，比如某某款带、企业网等等，但是原理是一样的。)

    接下来可能的问题有，比如经过协商上述单位可能会免费提供一定的带宽，条件是对其用户要免费提供服务，还有你在页面投放的广告要有限制，比如电信的广告(尤其是关于电话、上网的)不能让铁通、网通的用户看到，这也是情理之中的。还有所有通过202.99.1.2出口的都是你自己的用户，你希望他们不要绕圈子，最好转到192的内部地址看。有可能的话，铁通、电信等也有内部地址，希望通过他们的内部地址看。

    现在你看到了吧，针对这种情况如果对每个集团用户专门定制点播页面的话，工程量大而且不好同步，实际通过判断用户访问的是哪块网卡，以及用户的IP地址区间就可以知道用户的类别，然后给出不同的连接地址(主要是IP不同)，甚至是不同的页面。有了路由限制还能减少被攻击的概率，那些不在区内的用户根本ping不通你了，防止有些看不到你电影的，想着法弄瘫你。

    如果你有一台服务器这就简单了，但是我有6，7台机器就不一样了。每当协作方要求增减IP段时，我要更新好几台机器，好麻烦呀。所以我自己定义了xml文件，存放路由信息，放在中心机上，所有机器都到中心机上提取配置文件，然后每次运作时自动添加路由，经过实际运行效果不错。我的配置文件格式如下：



<?xml version="1.0" enco****="gb2312"?>

<基本信息 xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

  <网关信息> <!--预先定义网关，如果本机的某IP与其中的匹配，则网关就是下面的列表-->

    <网段 区域="网通" 网关="202.99.1.1">255.255.255.240</网段>

    <网段 区域="电信" 网关="219.148.1.1">255.255.255.240</网段>

    <网段 区域="铁通" 网关="220.148.1.1">255.255.255.240</网段>

    <网段 区域="内网" 网关="192.168.1.1">255.255.0.0</网段>

    <网段 区域="内网" 网关="192.169.1.1">255.255.0.0</网段>

  </网关信息>

<!--定义各个区域内可以观看的IP段-->

  <路由信息 区域="网通" 例外="FilmNo01"><!--指机器名为FilmNo01的例外，不设定此条路由-->

    <网段 掩码="255.255.255.0">202.99.64.0</网段>

    <网段 掩码="255.255.254.0" 广告="false">202.99.1.0</网段><!--广告设置-->

    <网段 掩码="255.255.252.0" 除流="True">61.10.196.0</网段><!--允许WEB但不允许流媒体-->

  </路由信息>

  <路由信息 区域="电信" >

    <网段 掩码="255.254.0.0" 广告="True">219.148.0.0</网段>

  </路由信息>

  <路由信息 区域="内网" >

    <网段 掩码="255.255.255.255" 定向="电信">192.168.2.1</网段><!--该段要定向到电信的网关IP组-->

    <网段 掩码="255.255.0.0">192.168.0.0</网段>

  </路由信息>

  <路由信息 区域="铁通" 定向="202.96.6.1;"><!--从202.96.6.1来的用户都定向到本区域-->

    <网段 掩码="255.255.0.0">220.148.0.0</网段>

  </路由信息>

  <路由信息 区域="特权管理"><!--管理页面的访问只能限制在下面的IP段内-->

    <网段 掩码="255.255.255.0" 除流="True">192.168.1.0</网段>

    <网段 掩码="255.255.255.255" 除流="True">127.0.0.1</网段>

    <网段 掩码="255.255.255.192" 除流="True">219.148.1.64</网段>

  </路由信息>

</基本信息>

该xml的VB.net的定义：

        Public Class Gateway

            ’定义了在某“区域”内，网关的配置情况