大文件读取的方案

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

V2EX 提问指南

这是一个创建于 2674 天前的主题，其中的信息可能已经有所发展或是发生改变。

应用需要读取一些大文件，单个不超过 4G，如果应用和数据部署在同一台服务器，就不存在任何问题。

但是目前大多数情况下都是多台应用服务器+1 台数据服务器，这种情况怎么破？

我司都是 windows 系统，之前用 windows 共享文件夹的方式，但是被权限问题搞得苦不堪言，大家都是怎么破的？

另外，如果是 linux 环境，又有哪些方案呢？

第 1 条附言 · 2017-07-21 15:25:26 +08:00

总的数据量比较大，单一类型的数据都是几个 T 的，类型也比较多。

另外，我们的应用层一般是读取一个文件后，需要从这个文件中再解析（当然这个解析是又索引机制的）出一部分数据返回。

打个比方，我有 1000 张图片，然后合并成了一个大的图片文件，并且生成了一个索引，现在的数据就是这些一个个合并的大文件（单个最大 4G ），用户请求的时候，根据索引去大图片里面读出对应的小图片返回。只是举一个类似的例子，所以不要问为啥不直接存放单个小图片，直接返回这种。

服务器

读取

文件

Windows

20 条回复 • 2017-07-22 08:37:26 +08:00

jinhan13789991

2017-07-21 13:57:12 +08:00

一台作为主服务器，文件有更新就推送到其他从服务器。

coolyujiyu

2017-07-21 14:30:32 +08:00

你可以在数据服务器上面弄个 FTP 服务嘛。
这样子应用服务器用 FTP 来读取好了。

linux 的话，直接把数据服务器的硬盘挂载到每一台应用服务器了。也可以用 FTP

wangxiaoer

2017-07-21 15:21:14 +08:00

@jinhan13789991 总数据量都是几个 T 的，没法这么同步。

wangxiaoer

2017-07-21 15:21:57 +08:00

@coolyujiyu 应用层能通过 ftp 的方式读取文件？比如 java 有这样的类库？

YouXia

2017-07-21 15:40:34 +08:00

分布式，拆分数据后，下发到每台机器，返回数据后上游做 merge。

如果只允许一台数据服务器，那只能试试磁盘索引了。

des

2017-07-21 15:51:03 +08:00

我觉得是你没弄懂 windows 共享的权限的机制。
要不看一下这个尝试下？ http://www.cnblogs.com/milantgh/p/3617852.html

wangxiaoer

2017-07-21 15:58:51 +08:00

@des windows 的这个权限机制的确没弄懂过，很多时候 windows 系统中设置正常后，IIS 里面就完犊子了，要通过配置用户密码的方式，有时候配了还不行，不想折腾了，所以问问有没有别的方案。
比如 NAS 啥的。

des

2017-07-21 16:13:43 +08:00

@wangxiaoer 要想匿名访问就要打开 guest 账户，然后允许无密码登陆。
所以最好还是新建个带密码的账户，然后给这个账户文件夹权限以及共享权限。记得把子文件（夹）的权限也改了，在安全-》高级里面可以直接递归。

Colorful

2017-07-21 17:05:12 +08:00

Hadoop

DCjanus

2017-07-21 17:17:03 +08:00

请问你们现有的方案是遇到了什么问题呢？权限控制过于复杂？文件共享有莫名其妙的 BUG ？还是性能跟不上？开发复杂度过高？

另外文件索引解析的流程是以下哪一个？
1. 大文件读取到应用服务器，解析出所需数据，抛弃其它部分
2. 调用文件服务器接口，文件服务器完成解析后传输所需数据
3. 从文件服务器获取索引信息，然后利用 Windows 文件共享协议提供的随机访问功能读取所需数据。

另外所有服务器应该是在局域网环境吧，也就是相互之间带宽很高？

coolyujiyu

2017-07-21 17:20:37 +08:00

@wangxiaoer 当然有啦，FTP 操作是最基本的。。。随便一百度

http://blog.csdn.net/dzy784858512/article/details/41279709

loopio

2017-07-21 17:25:01 +08:00

可以参考一些镜像站的架构，中科大，清华的。大部分镜像文件都是几个 G 的。比较成熟点。

wangxiaoer

2017-07-21 18:09:32 +08:00 via Android

@DCjanus 权限搞不定，莫名其妙不能用，莫名其妙又好了，当然这跟我们的水平有关。性能和开发难度倒没问题。

另外前阵子不是爆出 445 端口漏洞吗，有些客户就死活不开这个端口了。

目前解析流程用的是 1.

wangxiaoer

2017-07-21 18:10:27 +08:00 via Android

@loopio 不是这样的，这是纯静态大文件直接对外服务的。我们是应用层读写。

wangxiaoer

2017-07-21 18:11:22 +08:00 via Android

@DCjanus 忘了补充一下，应用服务器和数据服务器在局域网内，G 口带宽。

catror

2017-07-21 18:26:08 +08:00 via Android

用 NFS 远程挂载…

DCjanus

2017-07-21 19:16:09 +08:00

@wangxiaoer
还真是简单粗暴啊……
如果是这个方案，那就很简单了，所有文件都用 HTTP 或者 FTP 拉取，比如 nginx 提供 HTTP 服务，一般 80 端口应该都会开吧？就算没开，随便找个端口开一下都可以提供服务。
按照一般的 web 应用做一下鉴权（如果你们需要的话）即可，反正内网环境带宽够高，HTTP 的性能可以接受。

虽然我更倾向于把文件的元信息保存在数据库，应用层查询数据库获取小文件的大小、偏移量以及宿主文件的 URL，然后用 HTTP 的 range 获取文件，性能上好太多，节省很多流量，当然，如果你们觉得麻烦，当我没说 233333

sagaxu

2017-07-21 19:30:12 +08:00 via Android

没钱就买 nas，有钱就买 san，成熟方案很多，别折腾了

yidinghe

2017-07-22 01:27:09 +08:00 via Android

要随机读取文件，FTP 是不行的，nfs 应该可以，因为挂载之后就和本地文件差不多了。

wangxiaoer

2017-07-22 08:37:26 +08:00

@DCjanus 你说的这个思路（用 HTTP 的 range 获取文件）倒是不错，我之前没想到过，其实我们的文件适合索引存在一起的，比如 bigfile.dat 同目录会存在一个 bigfile.idx 文件，里面存放一些索引信息，我可以 http 先读取这个索引文件，解析出位置，然后 http range 读取 bigfile.dat 中指定位置的文件。

但是这样有一个前提，就是 bigfile.dat 里面单个文件是顺序存放的，这个我要下周确认一下。