简介这是基于Hadoop实现的百度云盘风格文件管理项目附完整源代码与文档说明主要面向大数据、软件工程等方向的在校生和毕业设计开发者用来学习分布式文件存储与Web系统设计。压缩包共收录2000个文件约77.11MB以Java、JSP等服务器端代码为主配合HTML、CSS、JavaScript构建前端界面其中854张PNG图片与195个GIF动图直观展示界面效果和操作过程JAR依赖库包含Hadoop相关组件还有数据库、配置及说明文档辅助运行。已有535人学习/下载代码经过功能测试能够稳定运行。通过阅读源码和配套文档可以掌握Hadoop HDFS在文件上传、下载、目录组织中的典型用法也能理清云盘系统中用户权限、资源管理和页面交互的设计思路项目模块划分清晰适合作为课程设计、项目演示或毕业设计的修改蓝本。1. 基于Hadoop的百度云盘为什么这个课程设计值得认真做每年毕业季都有大量学生选“基于Hadoop的百度云盘”这类题目但多数人做到一半才发现真正的难点不是写上传下载接口而是让一个分布式文件系统稳定跑起来。这个标题的本质是让你用HDFS做底层存储自己实现一套网盘服务端和前端功能对标百度云盘的上传、下载、断点续传和文件管理。它适合两类人一是正在做课程设计或毕业设计、需要一套能演示且能写进论文的完整项目的学生二是想熟悉Hadoop生态、但不想只跑WordCount的入门工程师。做完这套东西你对HDFS的写流程、NameNode职责、数据副本机制的理解会比看十篇教程都扎实。2. 先想清楚架构HDFS存文件MySQL存索引缺一不可2.1 为什么文件的二进制流必须进HDFS而不是MySQL很多人第一次设计这个项目时第一反应是把文件用Blob类型直接塞进MySQL。小文件没事一旦超过几十MBMySQL的写入性能会断崖式下跌一张表几GB之后备份和查询都成了灾难。HDFS的定位是“一次写入、多次读取”的大文件存储它把文件切成128MB的块每个块复制多份散落在不同节点天生就不怕单机磁盘满。我见过不少翻车案例都是用HBase去存文件二进制。HBase适合的是随机读写的小记录用它存几十MB的视频片段Region分裂和Compaction会把集群拖垮。所以这里有一条明确的选型结论文件数据进HDFS文件的索引信息文件名、大小、上传者、存储路径、分片信息进MySQL。两边各干各的活互不干扰。2.2 元数据表怎么设计三张表就够网盘的元数据设计我一般控制在三张表。第一张是用户表字段就五个user_id、username、password_hash、created_at、quota_used。第二张是文件表记录用户视角下的文件信息file_id、user_id、file_name、file_size、file_md5、storage_path、upload_time、status。第三张是分片表因为大文件要分片上传一张分片表记录每个分片在HDFS上的位置chunk_id、file_id、chunk_index、hdfs_path、chunk_size。storage_path 存的是HDFS上的完整路径比如/user/netdisk/upload/2024/11/09/abc123.jpg这样下载时直接拼接路径不用再查一次数据库。file_md5 用来做秒传判断——用户上传时先传MD5如果数据库里已有相同MD5就不重复存HDFS直接把文件记录指过去。这套逻辑抄百度云盘但实现成本很低。2.3 操作HDFS的核心工具类骨架代码在写业务接口之前先把HDFS操作封装成一个工具类后面Controller和Service都复用它。我给一个最小可用的版本Component public class HdfsStorageService { private final FileSystem fileSystem; public HdfsStorageService() throws IOException { Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfs://node01:8020); conf.set(dfs.replication, 2); // 为了让远程客户端也能连上集群必须显式指定这个值 conf.set(dfs.client.use.datanode.hostname, true); this.fileSystem FileSystem.get(conf); } public void upload(InputStream inputStream, String hdfsPath) throws IOException { Path path new Path(hdfsPath); if (fileSystem.exists(path)) { fileSystem.delete(path, false); } try (FSDataOutputStream out fileSystem.create(path, true, 4096)) { IOUtils.copyBytes(inputStream, out, 4096, true); } } public void download(String hdfsPath, OutputStream outputStream) throws IOException { Path path new Path(hdfsPath); if (!fileSystem.exists(path)) { throw new FileNotFoundException(HDFS文件不存在: hdfsPath); } try (FSDataInputStream in fileSystem.open(path)) { IOUtils.copyBytes(in, outputStream, 4096, true); } } public boolean delete(String hdfsPath) throws IOException { Path path new Path(hdfsPath); return fileSystem.delete(path, true); } }这段代码里有两个参数值得单独说。第一个是fs.defaultFS它必须和集群里core-site.xml的配置一致否则客户端根本不知道往哪连。第二个是dfs.client.use.datanode.hostname很多初学者在这里踩坑——客户端从NameNode拿到的DataNode地址是内网IP如果你的客户端不在集群内网读写会一直卡在超时。把这个参数设为true客户端会尝试用主机名解析再配合/etc/hosts里的映射问题就解决。IOUtils.copyBytes是Hadoop自带的方法省去手动写缓冲循环的麻烦。这里buffer size设为4096字节对网盘场景够用如果你传的是上百GB的大文件可以调到1MB减少系统调用次数。3. 搭建Hadoop集群伪分布式只是起点三节点才是网盘的底线3.1 伪分布式、完全分布式与HA的选型判断标题里“百度云盘”这个目标决定了伪分布式只能用于本地功能调试不可能扛住真正的上课演示压力。伪分布式只有一台机器NameNode和DataNode是同一个进程副本数只能设为1这时候你在答辩时根本说不出“数据冗余”这个卖点。我建议直接搭三节点完全分布式一台NameNode三台DataNodeNameNode也兼任DataNode。如果你要冲高分再往上加两个ZooKeeper节点做NameNode自动故障转移。我做过“Hadoop和ZooKeeper整合实战”这个方向ZooKeeper负责监控NameNode状态主节点宕机后自动切换到备节点这个过程在网盘项目里非常好演示——直接把主NameNode进程 kill 掉系统十几秒自动恢复这个演示画面在答辩现场是能直接打动评委的。3.2 三节点最小集群的搭建步骤下面的步骤适合CentOS 7/8或Ubuntu ServerJDK用1.8或11都行Hadoop版本选3.2.4这类稳定版。先在每台机器配好Java环境和SSH免密登录然后统一修改三个文件!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://node01:8020/value /property !-- 配置ZooKeeper时的必要参数 -- property nameha.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name value/data/hadoop/namenode/value /property property namedfs.datanode.data.dir/name value/data/hadoop/datanode/value /property !-- 把安全模式的阈值调低避免启动后长时间只读 -- property namedfs.namenode.safemode.threshold-pct/name value0.99/value /property /configuration这份配置里dfs.replication设为2意思是每个数据块存两份。三节点集群存两份是合理的因为NameNode会尽量把两个副本放到不同机器上只要不同时坏两台就丢不了数据。副本数设成1是伪分布式时代的习惯在真实集群里千万别省。dfs.namenode.safemode.threshold-pct是新手最容易忽略的参数。它表示HDFS启动时DataNode上报的数据块达到多少比例才自动退出安全模式。默认是0.99如果你的DataNode启动慢NameNode会一直卡在安全模式里表现为“客户端能连上但所有文件操作报SafeModeException”。把这个值调成0.99并配合手动退出命令最稳妥# 格式化NameNode只能在第一次启动时执行执行后数据目录会被清空 hdfs namenode -format # 启动HDFS start-dfs.sh # 查看状态和是否存在块缺失 hdfs dfsadmin -report hdfs dfsadmin -safemode leave启动完成后用hadoop fs -ls /验证一下根目录能正常访问。接下来验证“写文件 → 数据到底分了几个块、落在哪几台机器上”这个关键链路这也是答辩时最值得演示的部分hadoop fs -mkdir -p /user/netdisk/upload hadoop fs -put /var/log/syslog /user/netdisk/upload/test.log hadoop fs -stat %o /user/netdisk/upload/test.log # 查看块大小 hdfs fsck /user/netdisk/upload/test.log -files -blocks -locationsfsck这条命令会列出文件的每个块分别存在哪台DataNode上。当你看到一份文件的两个块落在不同主机时你在写论文时就能理直气壮地写“本系统通过多副本机制实现了数据容灾”。3.3 三个必调的Hadoop参数这里三个参数直接影响网盘的性能无论哪个版本的Hadoop都得调dfs.blocksize控制块大小网盘场景建议设成64MB或128MB块越小越适合小文件并行读取dfs.namenode.handler.count控制NameNode处理RPC请求的线程数默认10在三节点集群够用但并发上传超过50个文件时建议调到64否则客户端会频繁报超时fs.trash.interval设置回收站保留时间设为1440分钟用户删除文件后还能找回这个功能对标百度云盘的回收站也是答辩时的一个功能亮点。4. 客户端实现分片上传、断点续传与秒传的核心逻辑4.1 技术栈选择和工程结构客户端我推荐Spring Boot Vue这是目前最快出活且答辩时不容易被质疑的组合。Spring Boot负责暴露REST接口给前端前端用Vue的Element-UI拖一套管理界面上传组件用它的el-upload。工程结构按功能拆包controller放上传下载接口service放业务逻辑storage放HDFS和MySQL的数据访问层config放CORS和拦截器配置。这里先给一张文件清单后续写代码时对号入座FileController.java负责上传下载路由FileService.java处理分片合并、秒传判断、断点续传ChunkService.java维护分片的合并与校验HdfsStorageService.java是第2章写过的HDFS操作类前端Upload.vue负责分片读取和并发发送。4.2 分片上传接口设计分片建议每块5MB到10MB太大单请求失败重传成本高太小请求数量暴增。前端的el-upload通过http-request覆盖默认上传方式用js-file.slice() 手动切分每片一个请求发到后端。后端接收后先存临时目录全部到齐再合并。RestController RequestMapping(/api/file) public class FileController { Autowired private FileService fileService; PostMapping(/upload) public Result uploadChunk(RequestParam(file) MultipartFile file, RequestParam(fileMd5) String fileMd5, RequestParam(chunkIndex) int chunkIndex, RequestParam(totalChunks) int totalChunks, RequestParam(fileName) String fileName) { try { // 保存分片到本地临时目录 String tempDir /data/netdisk_tmp/ fileMd5; File dir new File(tempDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(tempDir, String.valueOf(chunkIndex))); // 如果是最后一片触发合并 if (chunkIndex totalChunks - 1) { fileService.mergeChunks(fileMd5, fileName, totalChunks); } return Result.success(分片上传成功); } catch (IOException e) { return Result.error(分片写入失败: e.getMessage()); } } }这段代码的核心是把网络IO和存储IO分开。MultipartFile是Spring封装的上传文件对象transferTo把请求体直接写磁盘没有二次复制内存对大文件友好。fileMd5是前端计算出来的文件指纹前端在文件选择后先读一遍算MD5后端拿它判断秒传和分片归属。分片合并的mergeChunks方法在另一个Service里public String mergeChunks(String fileMd5, String fileName, int totalChunks) throws IOException { String tempDir /data/netdisk_tmp/ fileMd5; // 输出流直接指向HDFS String hdfsPath /user/netdisk/upload/ fileMd5 _ fileName; try (FSDataOutputStream out hdfsStorageService.openOutputStream(hdfsPath)) { for (int i 0; i totalChunks; i) { File chunkFile new File(tempDir, String.valueOf(i)); try (FileInputStream in new FileInputStream(chunkFile)) { IOUtils.copyBytes(in, out, 1024 * 1024, false); } } } // 合并完成后清理临时分片 File tempDirFile new File(tempDir); for (File f : tempDirFile.listFiles()) { f.delete(); } tempDirFile.delete(); return hdfsPath; }合并的逻辑是按索引顺序把分片拼成完整文件流再写入HDFS。这里有个坑合并时如果用IOUtils.copyBytes的第四个参数传true它会自动关闭输入输出流如果后面还要写分片文件就会报StreamClosedException。必须传false交给后续代码统一关闭。4.3 下载与断点续传下载接口需要注意大文件的内存占用。很多初学者直接用Files.readAllBytes()把整个HDFS文件读进内存再返回给前端200MB的文件就会把JVM堆撑爆。正确做法是用InputStreamResource配合ResponseEntity做流式输出通过设置HTTP的Content-Length和Accept-Ranges响应头让前端拿到支持范围请求的流GetMapping(/download/{fileId}) public ResponseEntityInputStreamResource download(PathVariable String fileId) throws IOException { FileMeta meta fileMetadataService.getById(fileId); String hdfsPath meta.getStoragePath(); FileSystem fs hdfsStorageService.getFileSystem(); Path path new Path(hdfsPath); long fileSize fs.getFileStatus(path).getLen(); FSDataInputStream in fs.open(path); InputStreamResource resource new InputStreamResource(in); return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, attachment; filename\ meta.getFileName() \) .header(HttpHeaders.ACCEPT_RANGES, bytes) .contentLength(fileSize) .contentType(MediaType.APPLICATION_OCTET_STREAM) .body(resource); }断点续传在网盘里分两层一是底层HTTP协议支持范围请求设置了Accept-Ranges: bytes之后前端可以带上Range头从指定偏移量继续下载二是应用层的断点续传我把已上传分片的索引存到Rediskey是upload:progress:{fileMd5}value是已上传分片的Set上传前先查这个Set只传缺失的分片。这个方案的代码不复杂但写进文档里“断点续传”四个字就有了真实的技术支撑。5. 避坑手册Hadoop网盘项目的四个常见翻车点5.1 现象客户端连不上NameNode一直报连接超时原因有两类一是core-site.xml的fs.defaultFS写的是localhost:8020但客户端在另一台机器这个地址解析不到你的服务器二是集群机器上的防火墙开着8020/9870/9864端口没放行。解决方法是统一用主机名配置fs.defaultFS在每台机器和你的开发机/etc/hosts里加上集群所有节点的IP映射。防火墙方面要么在安全组和iptables里放行这三个端口要么干脆在实验环境里systemctl stop firewalld。注意9870是NameNode Web UI端口9864是DataNode数据传输端口少了任何一个都会造成“Web能看但程序连不上”的诡异场景。5.2 现象上传文件成功但用HDFS命令查看到副本数始终是1这是伪分布式环境最经典的坑。你在hdfs-site.xml里明明配了dfs.replication2但格式化NameNode之前没有统一同步配置文件导致DataNode启动时读到的是旧配置。运行hdfs dfsadmin -report可以看到每个DataNode的配置版本不匹配的节点不会接收新的副本写入。解决方法是改完配置后删掉每台机器的datanode数据目录和namenode数据目录重新执行hdfs namenode -format再start-dfs.sh。这个操作等于把集群重置了不要在有重要数据的集群上随便执行。5.3 现象上传大量文件后NameNode内存持续飙升甚至OOMNameNode把所有文件的元数据都放在内存里一个文件大概占用150字节到500字节的堆内存。网盘项目里最典型的错误是把每个分片都直接建成一个HDFS文件100个分片就生成100个文件元数据立刻翻倍。解决方法是分片在HDFS之外合并永远不要让HDFS直接管理碎片文件。我一般把合并前的工作全部放在本地临时目录只有合并后的完整文件才写入HDFS。如果确实需要把小文件归档用Hadoop的har打包机制可以显著减少NameNode压力。5.4 现象秒传功能时好时坏有时能秒传有时文件损坏秒传的判断标准是文件MD5一致就认为内容相同但MD5碰撞在理论上是存在的更实际的问题是分片上传的文件在合并时错了序。前端切分文件时如果遇到中文文件名文件名在传递过程中编码不一致可能导致分片编号错位。我的解决方法是不再用文件名判断分片归属改用fileMd5 chunkIndex作为分片的唯一标识秒传判断增加文件大小校验MD5相同并且大小一致才走秒传路径。另外前端计算MD5在低端手机上可能算得很慢我一般先把文件大小判断前置大小不同直接走普通上传流程给用户更好的交互反馈。6. 把项目做成能答辩的样子验证方法、文档组织与三个进阶方向项目写完不等于毕设做完。先做一轮系统性验证用脚本批量上传100个不同大小的文件1MB到200MB逐个下载校验MD5是否一致模拟断电重启NameNode观察恢复时间让两个用户同时上传同名文件确认不会互相覆盖。把这些验证过程截图存下来就是论文中“系统测试”一章的原始素材。文档说明按三个维度组织一是部署文档写清楚每台机器的IP、JDK版本、Hadoop版本、配置文件变更点确保照着文档能在新机器上复现环境二是设计文档画清楚上传和下载的时序图写明每个接口的入参出参和异常码三是操作手册给老师看的演示脚本包含“启动集群 → 登录网盘 → 上传大文件 → 查看分片信息 → 下载校验MD5”五个步骤。三个加分项我按投入产出比排序第一给HDFS路径加一层目录权限控制让不同用户只能访问自己的目录这对应HDFS的ACL机制代码量不大但能大幅提升“安全设计”得分第二引入HDFS的Quota配额功能限制每个用户的最大存储空间第三做一个简单的WebHDFS对接通过HTTP方式访问HDFS。一个血泪教训是答辩前一定要在干净的机器上按部署文档走一遍环境搭建而不是在自己已经调好的环境上演示。因为现场网络环境不同Cluster、Hosts和防火墙的差异随时可能让系统起不来。我上次就是吃了这个亏现场NameNode一直连不上DataNode最后只能放录屏。如果你把部署文档当回事提前走两遍这个风险就能压到最低。希望这个方向能帮你在毕设答辩现场少踩几个坑。本文还有配套的精品资源点击获取