这是一个创建于 2682 天前的主题，其中的信息可能已经有所发展或是发生改变。
应用需要读取一些大文件，单个不超过 4G，如果应用和数据部署在同一台服务器，就不存在任何问题。
但是目前大多数情况下都是多台应用服务器+1 台数据服务器，这种情况怎么破？
我司都是 windows 系统，之前用 windows 共享文件夹的方式，但是被权限问题搞得苦不堪言，大家都是怎么破的？
另外，如果是 linux 环境，又有哪些方案呢？
第 1 条附言 · 2017-07-21 15:25:26 +08:00
总的数据量比较大，单一类型的数据都是几个 T 的，类型也比较多。
另外，我们的应用层一般是读取一个文件后，需要从这个文件中再解析（当然这个解析是又索引机制的）出一部分数据返回。
打个比方，我有 1000 张图片，然后合并成了一个大的图片文件，并且生成了一个索引，现在的数据就是这些一个个合并的大文件（单个最大 4G ），用户请求的时候，根据索引去大图片里面读出对应的小图片返回。只是举一个类似的例子，所以不要问为啥不直接存放单个小图片，直接返回这种。
另外，我们的应用层一般是读取一个文件后，需要从这个文件中再解析（当然这个解析是又索引机制的）出一部分数据返回。
打个比方，我有 1000 张图片，然后合并成了一个大的图片文件，并且生成了一个索引，现在的数据就是这些一个个合并的大文件（单个最大 4G ），用户请求的时候，根据索引去大图片里面读出对应的小图片返回。只是举一个类似的例子，所以不要问为啥不直接存放单个小图片，直接返回这种。
 |
1
jinhan13789991 2017-07-21 13:57:12 +08:00
一台作为主服务器，文件有更新就推送到其他从服务器。
|
 |
2
coolyujiyu 2017-07-21 14:30:32 +08:00
你可以在数据服务器上面弄个 FTP 服务嘛。
这样子应用服务器用 FTP 来读取好了。 linux 的话，直接把数据服务器的硬盘挂载到每一台应用服务器了。也可以用 FTP |
 |
3
wangxiaoer OP @jinhan13789991 总数据量都是几个 T 的，没法这么同步。
|
|
4
wangxiaoer OP @coolyujiyu 应用层能通过 ftp 的方式读取文件？比如 java 有这样的类库？
|
 |
5
YouXia 2017-07-21 15:40:34 +08:00
分布式，拆分数据后，下发到每台机器，返回数据后上游做 merge。
如果只允许一台数据服务器，那只能试试磁盘索引了。 |
 |
6
des 2017-07-21 15:51:03 +08:00
我觉得是你没弄懂 windows 共享的权限的机制。
要不看一下这个尝试下？ http://www.cnblogs.com/milantgh/p/3617852.html |
|
7
wangxiaoer OP @des windows 的这个权限机制的确没弄懂过，很多时候 windows 系统中设置正常后，IIS 里面就完犊子了，要通过配置用户密码的方式，有时候配了还不行，不想折腾了，所以问问有没有别的方案。
比如 NAS 啥的。 |
|
8
des 2017-07-21 16:13:43 +08:00
@wangxiaoer 要想匿名访问就要打开 guest 账户，然后允许无密码登陆。
所以最好还是新建个带密码的账户，然后给这个账户文件夹权限以及共享权限。记得把子文件（夹）的权限也改了，在安全-》高级里面可以直接递归。 |
 |
9
Colorful 2017-07-21 17:05:12 +08:00
Hadoop
|
 |
10
DCjanus 2017-07-21 17:17:03 +08:00
请问你们现有的方案是遇到了什么问题呢？权限控制过于复杂？文件共享有莫名其妙的 BUG ？还是性能跟不上？开发复杂度过高？
另外文件索引解析的流程是以下哪一个？ 1. 大文件读取到应用服务器，解析出所需数据，抛弃其它部分 2. 调用文件服务器接口，文件服务器完成解析后传输所需数据 3. 从文件服务器获取索引信息，然后利用 Windows 文件共享协议提供的随机访问功能读取所需数据。 另外所有服务器应该是在局域网环境吧，也就是相互之间带宽很高？ |
|
11
coolyujiyu 2017-07-21 17:20:37 +08:00
|
 |
12
loopio 2017-07-21 17:25:01 +08:00
可以参考一些镜像站的架构，中科大，清华的。大部分镜像文件都是几个 G 的。比较成熟点。
|
|
13
wangxiaoer OP @DCjanus 权限搞不定，莫名其妙不能用，莫名其妙又好了，当然这跟我们的水平有关。性能和开发难度倒没问题。
另外前阵子不是爆出 445 端口漏洞吗，有些客户就死活不开这个端口了。 目前解析流程用的是 1. |
|
14
wangxiaoer OP @loopio 不是这样的，这是纯静态大文件直接对外服务的。我们是应用层读写。
|
|
15
wangxiaoer OP @DCjanus 忘了补充一下，应用服务器和数据服务器在局域网内，G 口带宽。
|
 |
16
catror 2017-07-21 18:26:08 +08:00 via Android
用 NFS 远程挂载…
|
|
17
DCjanus 2017-07-21 19:16:09 +08:00
@wangxiaoer
还真是简单粗暴啊…… 如果是这个方案，那就很简单了，所有文件都用 HTTP 或者 FTP 拉取，比如 nginx 提供 HTTP 服务，一般 80 端口应该都会开吧？就算没开，随便找个端口开一下都可以提供服务。 按照一般的 web 应用做一下鉴权（如果你们需要的话）即可，反正内网环境带宽够高，HTTP 的性能可以接受。 虽然我更倾向于把文件的元信息保存在数据库，应用层查询数据库获取小文件的大小、偏移量以及宿主文件的 URL，然后用 HTTP 的 range 获取文件，性能上好太多，节省很多流量，当然，如果你们觉得麻烦，当我没说 233333 |
 |
18
sagaxu 2017-07-21 19:30:12 +08:00 via Android
没钱就买 nas，有钱就买 san，成熟方案很多，别折腾了
|
 |
19
yidinghe 2017-07-22 01:27:09 +08:00 via Android
要随机读取文件，FTP 是不行的，nfs 应该可以，因为挂载之后就和本地文件差不多了。
|
|
20
wangxiaoer OP @DCjanus 你说的这个思路（用 HTTP 的 range 获取文件）倒是不错，我之前没想到过，其实我们的文件适合索引存在一起的，比如 bigfile.dat 同目录会存在一个 bigfile.idx 文件，里面存放一些索引信息，我可以 http 先读取这个索引文件，解析出位置，然后 http range 读取 bigfile.dat 中指定位置的文件。
但是这样有一个前提，就是 bigfile.dat 里面单个文件是顺序存放的，这个我要下周确认一下。 |
Select Language