本博客是为了展示《多文件云模式并发传输》框架的效果;
实现效果
这是我给每个传输文件加了3秒延迟之后的效果,
多文件自平衡云模式文件传输
视频网址
下面这个是我没有加延迟之后的效果:
框架的架构:
整个框架涉及到的包和类:
有关文件信息存储的类:
上面介绍了一些关于信息的存储类,因为所涉及到的类太多,我把他们分成了不同的包,下面仅展示包的信息:
框架介绍:
传统的客户端和服务端来说,客户端面对的是单一的服务器,
服务器及网络的带宽决定了网络的性能,每台服务器提供的信息数量,受到自身存储空间的限制,而任意时刻它所能支持的客户端的访问数量,则受到自身处理能力和网络带宽的限制,一旦服务器崩溃,整个网络也随之瘫痪。
对于服务器来说,当拥有大量的客户端进行访问的时候,服务器将承受巨大的压力。
对我们的多文件传输来说,我们的客户端想要请求某一数据资源的时候,我们只能访问单一的服务器,如果存在其他的客户端需要请求的资源和之前某一个客户端请求的资源相同,那么对于服务器来说,就需要再次进行响应相同的请求,那无疑对服务器来说是一种压力。
所以我的多文件自平衡云传输框架,有一个显著的特点,那就是当某个客户端在进行服务器请求的时候,最开始只有服务器有资源,当某个客户端拥有资源后,自己同样可以充当一个服务端,那么当再有客户端请求相同的资源的时候,那就会存在两个服务端可以进行资源的发送,以此类推,在出现了大量客户端的请求是时,对于真正的服务器来说,压力有一定的降低。
对于真正的服务器来说,首先向注册中心服务器进行资源的注册,告知注册资源自己的信息以及自己拥有的资源,当某个客户端向服务器请求资源时,服务端只是响应相关资源的一些基本的信息,而不会直接将真正的资源发送给客户端,此时客户端根据资源的基本信息,去向注册中心请求相关拥有该资源的节点列表,客户端根据返回的节点列表的信息,进行负载均衡挑选合适的能够发送资源的节点,进行链接这些节点,由这些节点服务器进行资源不同片段的发送。客户端根据一定的方案,将分散的资源进行整合。同时在接收到完整的资源之后,自已同样也可以作为一个发送端。