一，需求简介
在已有的文件上传功能基础上，实现大文件上传，影像文件那种
二，背景介绍
已有文件上传是最简单的实现，1个映射服务，1个存储中间件，如下图所示
应用服务上传字节流，映射服务负责上传到存储中间件，并返回文件id，类似uuid这种随机串。
查询也很简单，根据id，获取字节流
这样缺点1：不能存储大文件，因为会超时，也不支持太多并发，映射服务有限流，会超时。 因为服务的并发度并不是很高，所以一直这么跑
三，需求处理
先进行数据切分，如图所示
应用服务拿到用户上传的文件时，先生成md5，后面要做数据验证用。
然后对字节流进行切割，进行并行上传， 如图所示
上传结束后，触发一个异步任务进行校验：若干文件流进行合并，计算md5看是否和原始文件的md5相等，如果不等，说明有损坏，在文件上传中心提示重新上传。
四，思考
到了这一步，需求已经实现了。 但如果想建立一个支持高并发、大型文件综合管理中心，该如何设计呢？
以下内容纯属虚构，按需阅读
首先将系统拆分为三部分：接收服务器、转发服务器、存储服务
1，接收服务器用于接收请求，前置nginx，进行路由转发，生成文件的md5，按照优先级队列给到转发服务器，资源用于高优先级的文件存储 2，转发服务器进行文件分片、选择存储服务、记录存储位置 3，存储服务负责存储、同步和校验
如图所示
关键点阐述：
1，用户请求路由到接收服务器，计算md5，转发至分发服务器
2，分发服务器掌握存储服务的心跳监控，发现心跳问题，进行下线处理，响应服务时，优先选择就近、低负载的存储器存储分片并记录存储位置
分发服务器可进行动态扩展，上线以后和所有存储器建立连接，进行监控，对接入层提供访问。
3，文件经过分发处理器切片，选择不同存储器存储，比如1、3、5由存储器1，2、4、6由存储器2分别存储。
分片1、3、5后续会同步至存储器2,分片2、4、6会同步至存储器1，这样同一文件会有多副本，经过md5检测，这样副本都是可用的。
这样就构成、高可用、高可靠的大型文件管理中心。
