关于前端服务器负载均衡的问题

jietuan 2017-05-25 06:34:36

我现在帮客户开发一个文档存储系统，把文档上传到服务器并存储到服务器硬盘里面；现在的设计是应用服务器和文件服务器是同一个服务器，考虑到客户有20000个用户，应用服务器要做负载均衡；假定0001文件上传到应用程序服务器A，如果有另一台负载均衡应用程序服务器B来处理查看文件0001，那么0001就访问不到，因为它存储在A服务器里面。这样情况怎么处理？谢谢大家，集思广益

...全文

445 11 打赏收藏转发到动态举报

写回复

用AI写文章

11 条回复

切换为时间正序

请发表友善的回复…

发表回复

wanghui0380 2017-05-26

打赏
举报

看你们原始方案，基本都是在应用服务器做分流那么其实比较好办。你可以做一些索引同步工作，比如使用zookeeper去同步多台机器的文件索引，得到文件位置了用iscsi协议去访问文件，当然你也可以将文件索引分发的redis集群，发文件分发到hadoop集群，发一些经常频繁访问的文件调配到静态高速文件缓存等等（调度策略自己保证，如何判定文件需缓存，文件需逐出缓存是调度策略的事情）

以专业开发人员为伍 2017-05-26

打赏
举报

花钱买一个傻瓜化的现成的东西，当然“很爽”，程序员只要做点维护就行了，抽出时间来学点人家的理论文档而不用自己搞技术开发。但是这其实很危险。如果都是这样，这个世界上也不会有 google 等等互联网公司。你到任何一个最近10年的互联网创业公司就会发现，它们都是在做这些方面的设计开发工作，真正的投资应该给人而不是给机器，而不是靠花钱买 IBM 或者 Oracle 的硬件软来创业的。

以专业开发人员为伍 2017-05-26

打赏
举报

能够灵活地设计一个“调度系统”，这是核心技术。虽然看上去并不复杂。比如说你要求必须花几十万买什么别人的设备或者软件，才能实现这种系统，而且将来不能重构实现机制，那么这本身就危险。

以专业开发人员为伍 2017-05-26

打赏
举报

假设你有10个服务器，那么可能1个服务器有这个文件，也可能有2个，也可能是10个都有。这个是根据需求设计而来的。比如说需要频繁地操作、强度较高的系统，那么服务器当然是先到本地取更有效率。如果大量请求都跨服务器就不值当了。但是反过来说，这样的代价也很大，比如说刚水平扩展3个服务器，并不能保证它有全量备份。所以其实选择哪一种机制，并没有一定之规。可以重构。

wanghui0380 2017-05-26

打赏
举报

随便做，简单的，复杂的瞬间都能有10多种以上的方式比如上传写索引文件，查找根据索引文件查到具体位置，再代理访问比如现成的开源分布式文件系统比如基于iscsi协议的存储服务器（ps：现在window本身就支持iscsi协议服务，也就是你可以像访问本地硬盘一样访问远程的硬盘）

X-i-n 2017-05-26

打赏
举报

每台服务器复制一份文件的意义何在？存储的事，归存储。应该由存储角色提供统一的、健壮的文件存放服务，再由负载均衡的后端去访问这个共同的存储

mc_dv 2017-05-26

打赏
举报

不是经常改写数据文件的，就一个服务器，做个缓存

以专业开发人员为伍 2017-05-25

打赏
举报

要注意的是，这里根本用不着什么“复杂均衡”。尤其是有些国企花那几十万元冤枉钱买硬件负载均衡，我看着都心疼。

以专业开发人员为伍 2017-05-25

打赏
举报

我再具体说一下第一种。当要查询一个文件的位置信息，首先把命令发给 master 服务器，而 master 服务器把命令给所有的事先长连接上 master 的 worker 服务器，然后 workder 就会到本地去查找，如果找到返回 true，如果没有返回false。master 服务器对于那些返回 true 的服务器，选择最快的一个（实际上不用等第二、第三个返回） worker，发个命令让它进一步返回详细信息，然后 master 服务器把这个返回信息作为自己的返回而转发给当初提出查询请求的访问者。

以专业开发人员为伍 2017-05-25