千万级别音频文件存储设计[转]

Trackbacks

发表评论

Player

日志分类

最新评论

日志归档

搜索文章

博客信息

友情链接

技术支持

                    千万级别音频文件存储设计

一操作系统，文件系统建议使用suse10 默认reiserfs 文件系统；

二存储目录设计
   前提，现有20万个音频文件，
   要求，保证每个目录下文件数量不超过300个（一个目录超过300个文件影响检索性能）；
URL 例子如下:
http://192.168.0.1/01/9f/789123456.mp3
说明:
1 789123456.mp3为音频文件名称,必需确保唯一性,可以对音频文件文件名按照数字递增进行命名.
2 第一级目录01和第二级目录9f 分别是对唯一的文件名做 hash 后产生的字符串,取最前面两位为一级目录,取最后面两位为二级目录。
3 192.168.0.1 为音频文件存储的服务器ip地址。
4 按照此规则,最大可容纳用户 256*256*300=19660800 个音频文件
5 对应上面图片访问url,物理路径是: /data/01/9f/789123456.mp3

三业务流程说明
1 音频文件上传时
   每个音频文件在数据库有唯一记录,至少有以下字段(和音频文件的存储和访问有关):
   音频文件唯一文件名，音频文件所在服务器ip地址.
2 图片页面显示时
   从数据库取得音频文件唯一文件名和服务器ip地址,再对文件名做md5(参照第二部分第2小节),就可构造出完整的图片访问url.

四系统扩展性考虑
1 原有服务器存储空间满；
增加多一台存储服务器，例如 192.168.0.2,存储目录和192.168.0.1 一样，
音频文件上传的时候做一定流程处理存放到192.168.0.2的相应目录下。
2 单台服务器并发点播压力过大。
增加点播服务器一台，例如192.168.0.3 ,存储目录和192.168.0.1 一样，
数据库音频文件表增加字段一个，用于记录音频文件的点播次数，把点播次数最高的一批（例如 1万个音频）
传到服务器 192.168.0.3,同时把这台服务器的ip地址和音频文件存储位置入库。
用户点播的时候，检索出某个热门音频文件在哪几台服务器上面（例如192.168.0.1和192.168.0.3），
通过傻瓜轮循或者其他更加智能手段可达到用户点播的负载均衡。

五防止盗琏
1 apache 简单，但性能低，只能防住入门级别用户；
2 lighttpd 基本不影响性能，页面输出代码需要做小调整，能完全防止住盗琏；
3 不定时重新构造音频文件存储物理路径和访问url
完全不影响性能，需要做好系统流程设计，存储目录，数据库结构和上传程序都需要做些调整。
这招比较绝，能让自以为盗琏成功者痛不欲生！
4 DRM 数字版权控制，这只是用来忽悠客户或者老板的技术解决方案，实际应用中可行性不大。
100％防止盗琏，完全不影响性能，但是带来的是系统设计和部署建设的很高复杂性。

« 2010年09月 »