1
liprais 2017-07-07 17:22:14 +08:00 via iPhone
搞个 nfs 不就行了
|
2
derek80 2017-07-07 17:24:31 +08:00 via Android
用类似 aws s3 服务
|
3
notgod 2017-07-07 17:30:45 +08:00 via iPhone
以前弄过
最简单的方案 下载 尝试访问 1 的 如果文件存在 返回 不存在 反向代理到 2。反之亦然 因为使用内网 不存在带宽流量消耗 另外一个解决方案 就是 sersync 做实时同步即可 一般 lb 结构 后端提供 n 个 VIP 共同一个 san 存储 便于扩展 这样才是最佳的 主要将运算和存储分离 如果流量不大 业务规模小 没必要弄 lb 没瓶颈的 |
4
salmon5 2017-07-07 17:39:10 +08:00
一般瓶颈在带宽,不在 nginx,两种方法:
1,换成一台 nginx ; 2,两台 nginx 读写文件通过一个 nfs 盘实现。 最简单的两种方法,别造大轮子了。 |
5
ryd994 2017-07-07 21:28:18 +08:00
所以为啥你需要两台 nginx ?
|
7
t6attack 2017-07-07 21:46:10 +08:00
整个实现逻辑有问题
|
8
lightening 2017-07-07 21:52:47 +08:00
Load balancer 后面的系统一定要是 stateless 的。你的文件储存是 stateful 的,显然要单独拉出来集中处理。如果一台机器不够,就要上分布式储存,那就不是简单的 load balancing 问题了。一旦进入分布式系统的领域,就必须放弃 CAP ( consistency, availability, partition tolerance ) 中的一个。如果你的文件储存压力不是那么大,建议这部分不要没事找事搞分布式。
|
9
chih758 2017-07-07 21:53:50 +08:00
规模小用 nfs 就行了
|
10
gogohigh 2017-07-07 21:54:53 +08:00
每个文件对等 replication 吧,最简单的方案
|
12
akira 2017-07-07 22:42:17 +08:00
本来想说根据文件名做哈希算法,确定后端服务器地址什么的,想想,还是 3 楼的方案就好了,简单。
|
14
billlee 2017-07-07 23:43:00 +08:00
可以用 s3, 或者自建 GridFS
|
15
loopio 2017-07-07 23:48:54 +08:00 via Android
这不叫分布式存储吧,只能说是通过 nginx 把请求转发到不同的服务器而已。还谈什么 CAP ? 采用分布式存储文件系统 ceph 或者 hdfs 等。才疏学浅个人瞎猜,欢迎来喷。
|
16
bfbd 2017-07-08 11:16:51 +08:00
nginx 配置两种路由,一种通用的,后台自动负载均衡,一种特定的,指定从哪台服务器获取。
通用的那条检查下返回状态,404 就转向特定的,指定从另一台服务器获取文件。 |
17
banksiae OP 多谢各位回复,我参考下。以前文件存储都是直接扔给七牛的,没搞过文件存储
|