随着计算机的普及，vod和ktv系统也迅速发展起来。娱乐场所，酒店，小区也逐步采用vod和ktv系统。市场调查发现，ktv点歌系统（卡拉ok歌曲为主）和vod点播系统（电影为主）有着良好的市场前景。目前市场上已有不少ktv软件，经过考察比较，发现目前已有系统存在以下问题：成本偏高，市场竞争要求尽可能的降低成本；系统可靠性不高，客户端对服务器依赖性过高；软件易用性不好，上手慢；软件稳定性不够高，容易发生死机等现象；软件有些方面设计不合理，例如对最常用的消除原声操作复杂，应该做到自动实现。 受公司邀请，我主持开发了ktv点歌系统（基于硬件解压播放）和vod点播系统（基于软件解压播放）。其中我负责项目的总体分析，设计，以及主要的编码工作，并协调界面设计人员，硬件测试人员和软件测试人员的工作。
目前为止，其中的ktv点歌系统已经成功推广使用，并以稳定性，易用性受到用户好评。
先简要介绍一下ktv系统的布局：
服务器端采用多台服务器，作为无盘启动，数据库和节目源服务器，使用了故障转移技术，任意一台服务器失效，都可保证系统继续运行。
客户端使用无盘工作站，使用显示器作为点歌界面，电视机作为节目输出界面，用户使用遥控器或者鼠标进行操作。
系统要求在低成本的条件下实现比较高的可靠性，在比较目前市场上已有系统的基础上，我使用了如下方案：
1． 体系设计：
1）使用无盘工作站。服务器端为win200 server，使用raid硬盘阵列，客户端采用无盘win98。好处：每个客户端节省一块硬盘，在总量上也是比较可观的；客户端win98系统不会受到破坏，每次重起机器即完好如初，能够承受恶意操作（如故意重起等）；可以由服务器端统一控制。
2）使用client/server结构。客户端运行点歌系统，连接服务器端的数据库，从服务器读取节目。其实无盘工作站的设计已经基本决定了使用这种c/s结构，主要在数据库的选择上可以选用本地数据库，也可以使用网络数据库，经比较考虑后，采用了网络数据库。
3）使用软件进行负载平衡。Win2000 advanced server本身提供了负载平衡和故障转移策略，但并不完全适合我们的需要，以及硬件成本偏高（工程造价往往是硬件和软件一起算的，现在的市场上几千到几万的成本差价都不得不考虑），并且要求系统安装人员有较高的技术水平。出于以上考虑，并结合软件自身的特点，使用软件来进行负载的平衡。点歌系统对网络的要求是很高的，例如点播dvd时要求此客户端能保证得到1M/秒的数据流，播放过程中不得出现停顿，延迟等。服务器端存放了10000首歌曲（在谈项目时对方会比较注重歌曲的总数量），由于数据量大，采用分布式存放于多台服务器，另外对用户调查发现，用户点歌偏好基本满足正态分布，80％的点播集中在2000首歌曲上，为了平衡服务器的负载，对常用歌曲实行冗余存放（例如A机和B机都存放了此歌曲），所以歌曲可以分为两大类：唯一性歌曲（只有在某台机器上有一份文件）和冗余性歌曲（在多于一台的服务器上有此首歌曲）。对于唯一性歌曲，不进行负载平衡，只是简单的读取数据（当然也可以进行最高负载限制，例如A服务器最高只允许30个连接，超过此数时则拒绝，客户端跳过此歌曲，转向下一首）；对于冗余性歌曲，由点播软件进行负载平衡，先向服务器查询负载较小的服务器，然后连接此服务器读取节目。
4）失效控制。也是出于同上一条一样原因（适用性，成本和安装人员技术水平）的考虑，采用了软件自身的失效控制。由实际调查发现，主要失效为硬件失效。硬件失效又主要为硬盘损坏和网络损坏。虽然服务器使用了raid硬盘阵列，但由于承受着大量的数据读取工作（1首4分钟的dvd 平均130M，130M/首×15首/小时×15小时/天×30台＝877G/天），硬盘容易损坏。当机器出现故障时，需要进行停机检修，为了不影响客户端的正常点播，软件能自动发现失效的服务器，屏蔽失效服务器上的歌曲，对重复性歌曲也自动剔除失效服务器，只从正常服务器进行选择播放。如果系统的数据库服务恰好也在失效的服务器上，软件会根据预先的配置自动选择有效的服务器进行连接，所有过程对用户透明，用户可以在基本不受影响的情况下继续播放歌曲。对于网络损坏的失效控制与硬盘损坏类似，对于每个客户端，只要还能连接到其中的一台服务器，即可继续运行。
负载平衡和失效控制是本系统相对于目前市场上其他系统的一个比较大的优势，在比较低的成本上实现了比较高的可靠性。
2． 数据库设计：
1）数据库的选择。考虑到安装人员的技术水平，并参考市场上的已有系统，一开始考虑采用access数据库，access简单易用，安装人员能较快掌握，并能满足开始的基本需求。但后来经过调查发现，access数据库无法实现以后肯定会需要追加的其他功能（例如统一管理等），并且access在安全性和稳定性方面存在问题，决定舍弃access，采用 sql server 数据库。为了使用sql server数据库，我费了不少口舌，要说服项目的相关人员，对安装人员进行培训，向他们讲解sql server带来的好处（因为他们喜欢access的易用性，直接拷过去就能用）。最后，系统采用sql server 做为数据库。
2）数据库的使用。数据库安装在服务器端，客户端按照预先的设定去连接服务器的数据库。在数据库的连接上使用了动态搜索加载技术。例如有A , B , C三台服务器，均配置了数据库服务，设定优先顺序：A（主数据库）>B>C。客户端在启动时先搜索A B C服务器是否可以连接，如 A可用就连接上，并立即返回，否则查看B和C是否可用。由于进行了优化，在正常情况下（A可用），连接时间在0.5秒之内；在故障情况下（A不可用，B C 至少其中之一可用），在2秒之内连接完毕。在软件运行过程中，如果当前连接的数据库失效，软件能自动连接下一个可用的数据库，保证系统能最大限度的继续工作。Sql server提供了自动备份功能，并且在将来有需要的时候，可以进行数据库的同步热备份（我在另一个钢铁企业的项目使用了同步热备技术）。由于采用了以上技术，使系统能在比较恶劣的条件下（如服务器故障）继续工作，最大限度的保证了系统的不间断性。相比于目前市场上大部分的系统，服务器或网络故障则客户端全部瘫痪或者影响用户的正常操作，本系统有着明显的优势。
3． 问题和不足之处。
1） 项目的最大问题其实不在软件上，而在硬件上。尽管采用了故障转移策略，硬件故障仍然是非常可怕的（我想对每个系统都是如此）。开始安装人员在选用raid硬盘阵列的时候采用了raid 0 （他们对这个比较熟），阵列中一个硬盘故障则整个阵列无法使用，对于只采用2台服务器的系统则另一台服务器负载明显过重，为此我曾在半夜1：00坐车赶过去“救火”。后来我要求采用raid 5 ，阵列可在一块硬盘故障情况下继续工作，提高了系统的可靠性。
2） 曲目数据量大，整理，管理困难。近万首的歌曲，光是听一遍就要花一个多月（24小时工作），要整理好难度更大。为此我编了不少小程序，专门自动做整理工作。
3） ktv点歌系统是基于硬件解压播放的，使用了神龙dvd解压卡。解压卡只能播放mpeg-1 和mpeg-2 ，无法播放现在比较流行的如mpeg-4格式。不过这在vod系统中得到了改进,vod系统采用了软件解压，能播放目前流行的大多数格式的视频文件，并且能支持共享式播放和流媒体式播放，在系统架构上更加灵活。目前vod系统已经开发完毕，正在进入市场推广阶段。
总结我这几年软件设计和开发的经验，无论对哪类系统（娱乐的vod点播系统，工业的钢铁企业管理系统，商业的电子商务系统），系统的分析，设计，管理都是非常重要的。市场竞争激烈，投资者要求降低成本；用户需求多变，软件要禁得起变更；用户层次不同，软件的易用性尤为重要；硬件故障在所难免，软件要有最大的可靠性。要满足上述需求，光靠编程高手或者埋头苦干是不能解决问题的，需要的是系统分析，设计和管理能力，才能带领一个团队开发出满意的产品。目前，我正在学习管理，咨询，市场，经济，数学建模等内容，并聆听一些大公司管理者（例如utstarcom总裁，中兴，普华永道等高层人士）的演讲，虽然看上去这些和计算机软件没有直接关系，但是我觉得首先要有管理，有市场，才有软件，有了软件，也要懂得经济，懂得做企业，才能使软件有地方去发挥价值，才能形成软件开发的良性循环。一名软件开发人员，不能只知道软件开发，只知道技术，要学会高屋建瓴，提高自身的整体素质，在现代企业中有三要素：管理，市场，技术。在懂得管理，了解市场的基础上再来做技术，才能做出真正符合市场经济需要的产品。
扫一扫
243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
