简介这份基于 Hadoop 的百度云盘项目适合计算机相关专业在校学生、毕业设计者以及大数据入门学习者可用作课程设计、毕设演示或项目初期立项的完整参考。资源内含全部源代码与详细的文档说明代码经过测试运行成功答辩平均分达到九十六分下载后即可快速部署体验。压缩包共 2000 个文件大小约 77.11MB文件构成以 png、js、html、css、java、jsp、jar 等类型为主覆盖了前端页面、交互脚本、后端业务逻辑及静态资源素材目录结构清晰便于按模块查看与二次开发。内容预览中能看到 easyui、bootstrap 等前端框架以及 Eclipse 工程配置文件有助于理解 Hadoop 分布式存储与 Web 网盘结合的典型实现方式。目前已有 535 人浏览学习对于需要完成类似选题或想上手大数据项目的人来说具备较好的借鉴价值。1. 基于Hadoop的百度云盘它解决的不是存储问题是文件管理问题把文件传上百度网盘后端到底发生了什么如果你接触过这类项目会发现真正的难点不在HDFS的分布式读写能力而在文件管理链路分块、断点续传、秒传、目录树、分享权限。“基于Hadoop的百度云盘源代码文档说明”这个组合是课程设计和毕业设计的常见题目——用HDFS当存储底座上面封装一个类网盘服务。适合正在学Hadoop、准备做课设的开发者也适合刚进分布式存储想找个能落地练手项目的人。判断它值不值得做的标准只有一个你打算投入多少时间以及完成后能带走多少关于HDFS生产环境的认知。2. Hadoop环境选型的实战脑回路伪分布、集群和Docker镜像怎么选不是所有云盘项目都要从三节点集群开始。伪分布式单节点跑着NameNode、DataNode和SecondaryNameNode验证功能完全够。课程设计、毕业设计用单机伪分布跑通一遍再把配置切到多节点这是最多人走的路径。只有一个例外要测真正的副本容错、数据均衡和机架感知这些依赖多节点伪分布只能模拟个样子临到答辩前再补集群就晚了。2.1 版本选型Apache还是CDH2.x还是3.x对这类项目我的选型顺序是Apache Hadoop 3.x 优先如果所在环境已经部署了CDH就用CDH最后才考虑Apache Hadoop 2.x。原因不复杂3.x的HDFS支持纠删码模式云盘场景核心操作是顺序读写3.x在IO路径上明显更顺。3.x的节点列表文件叫workers2.x叫slaves。网上大量教程还在写slaves照抄之后找不到文件来回折腾。从3.x起步可以避开这批过期内容。CDH安装依赖Cloudera Manager组件栈很重单机课程设计用不上。除非公司内网已经有一套CDH否则不要为了“看起来专业”去装它。另外只有配置HA两个NameNode自动故障切换时才需要ZooKeeper。很多人问“hadoop和zookeeper整合实战是不是这个项目的前提”答案是否定的。单NameNode架构ZooKeeper这一环可以先放一边把精力留给HDFS路径设计和代码封装。2.2 伪分布式搭建最小命令集与验证方法安装的核心配置只有三个文件core-site.xml、hdfs-site.xml、yarn-site.xml。改完做一次全流程验证确认HDFS本身稳定再开始写云盘代码。顺序和命令如下# 1. 配置免密登录HDFS脚本用ssh启动进程 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys # 2. 格式化NameNode只做一次重复执行会清空元数据 hdfs namenode -format # 3. 启动HDFS和YARN start-dfs.sh start-yarn.sh # 4. 检查进程是否齐全 jpscore-site.xml里两个参数最关键fs.defaultFS和hadoop.tmp.dir。前者决定云盘代码里所有hdfs://路径的前缀后者必须指向一个空间充足、不在系统盘的分区。默认的/tmp/hadoop-*会在系统重启时被清理这是很多人第二天节点起不来的头号原因。如果伪分布环境安装完成后连Web界面都打不开先检查hadoop.tmp.dir对应的目录还在不在再谈其他排查。hdfs-site.xml里伪分布必须设置dfs.replication1。只有一个DataNode时副本数大于1上传小文件正常、大文件卡在最后一步块一直处于PendingReplication状态。这是伪分布最典型的“玄学故障”其实参数就在眼前。# 验证建目录、传文件、读文件、删文件全走一遍 hdfs dfs -mkdir -p /user/hadoop/test hdfs dfs -put /etc/hostname /user/hadoop/test/ hdfs dfs -cat /user/hadoop/test/hostname hdfs dfs -rm -r /user/hadoop/test四条命令都通过HDFS基本就绪。put和copyFromLocal行为一样任选其一注意用hdfs dfs而不是老教程里的hadoop fs前缀3.x已经标准化为前者。# NameNode的Web界面2.x默认端口500703.x默认9870 curl http://localhost:9870/dfshealth.html#tab-overview我一般只看“Live Nodes”这个数字伪分布必须显示1集群模式下必须等于DataNode节点数。数字不对云盘上传链路一定出问题。提示如果用的是云主机记得在安全组里放行9000RPC和9870Web UI端口。很多环境搭好了但页面打不开多半是端口没放行。2.3 扩成3节点集群workers文件、格式化顺序和内存预算课程设计中途想扩成三节点要动的地方其实很少。准备三台机器或容器主机名分别为node01、node02、node03node01跑NameNode和ResourceManagerDataNode和NodeManager分布到三个节点。每次改完配置再同步到所有节点避免节点配置不一致。改两个文件就行。core-site.xml里的fs.defaultFS从hdfs://localhost:9000改成hdfs://node01:9000三台机器保持一致。hdfs-site.xml里把dfs.replication改成2或3具体看磁盘预算。然后修改DataNode节点列表# 3.x用workers2.x用slaves文件在$HADOOP_HOME/etc/hadoop/ cat $HADOOP_HOME/etc/hadoop/workers EOF node01 node02 node03 EOF重点在格式化顺序。伪分布如果已经写过元数据切集群前必须先清理旧数据目录再格式化。否则NameNode元数据里全是旧节点信息新节点连接时会对不上表现为DataNode反复注册失败。rm -rf /data/hadoop/tmp hdfs namenode -format sbin/start-dfs.sh sbin/start-yarn.sh内存预算也要算一下。NameNode堆内存默认1G文件数量多时不够使。经验值是每个块大概占150字节100万个块就是150MB加上JVM开销堆内存给4G比较稳。改的是HADOOP_NAMENODE_OPTS不是HADOOP_HEAPSIZE两个变量作用范围不一样踩坑时容易被误导。如果不想手动搭机器可以用现成的Hadoop镜像起容器。用Docker跑能省掉配置SSH和网络环境的步骤但要留个心眼容器重启后hadoop.tmp.dir里的数据是否能保留取决于镜像有没有声明VOLUME。没有持久化的话格式化完一重启又回到起点。解决办法是把/data/hadoop/tmp挂到宿主机目录容器重启后继续读同一份数据。3. 云盘系统分层设计上传路径上的每个组件都在干什么拿到“基于hadoop的百度云盘源代码文档说明”项目包第一件事不是打开IDE编译而是先看懂分层。这类网盘项目代码一般分四层Controller层接收HTTP请求Service层处理业务逻辑DAO层访问MySQL保存元数据HDFS适配层做文件读写。业务代码和HDFS的耦合度决定项目后来能不能平滑地从伪分布迁移到集群。3.1 模块职责边界为什么文件内容进HDFS文件列表进MySQLHDFS不适合为网页端小文件设计。文件平均大小几百KB、每秒创建几百个NameNode先扛不住——元数据全在内存里。所以网盘项目的正确姿态是文件内容进HDFS文件目录树、大小、MD5、分块位置进MySQL。MySQL承受“文件数量级”的记录HDFS承受“真实大文件”的读写两边各管一段。数据存储位置原因文件二进制内容HDFS分布式、多副本、流式读取文件目录、文件名、大小MySQL查询方便、索引支持、事务可靠分块元数据第几块、偏移量MySQL秒传和断点续传依赖它用户信息、登录态MySQL/Redis和HDFS无直接关系没必要进HDFS这个分层还有一层用意云盘页面展示的文件列表必须能模糊搜索、按时间排序HDFS的ls拿不到这些而文件内容流式读取必须快MySQL存大字段不划算。业务层面对的问题不是“HDFS慢不慢”而是“MySQL和HDFS的数据如何保持一致”。3.2 用Java API操作HDFSFileSystem的建立与关闭时机代码里最容易改不动的地方在适配层。核心对象只有三个FileSystem、FSDataOutputStream、FSDataInputStream。建立连接和写文件的代码import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FileSystem; import org.apache.hadoop.fs.Path; import org.apache.hadoop.fs.FSDataOutputStream; import java.io.InputStream; import java.net.URI; public class HdfsStorageAdapter { private FileSystem fs; public void init(String hdfsUri, String user, String hdfsCoreSitePath) throws Exception { Configuration conf new Configuration(); // 读入服务器上的core-site.xml否则fs.defaultFS不生效 conf.addResource(new Path(hdfsCoreSitePath)); // 第三个参数指定以哪个用户身份操作HDFS fs FileSystem.get(new URI(hdfsUri), conf, user); } public void upload(InputStream input, String hdfsPath) throws Exception { Path dst new Path(hdfsPath); FSDataOutputStream out fs.create(dst, true); // true表示覆盖 byte[] buffer new byte[8192]; int len; while ((len input.read(buffer)) 0) { out.write(buffer, 0, len); } out.close(); // 这里不关闭fsfs是长连接 } }这段代码有两个容易忽略的细节。conf.addResource(new Path(...))很多人只传一个hdfs://node01:9000的URI然后报AccessControlException。原因是HDFS的RPC握手会校验版本和客户端配置配置不一致直接拒绝。把服务器的core-site.xml读进来这个问题就不见了。第二个细节是FileSystem实例必须复用。FileSystem.get对同一个URI会缓存实例整个进程维护一份配置即可。这里只关闭FSDataOutputStream不关闭fs否则下次上传直接报“Filesystem closed”。3.3 元数据表设计file_info、chunk_info与秒传指纹的配合不管代码写得多复杂网盘的核心表就三张。file_info表一个文件一条记录字段类型说明file_idbigint文件ID主键user_idbigint文件属于哪个用户file_namevarchar(255)原始文件名file_sizebigint字节数用于显示和配额hdfs_pathvarchar(500)文件在HDFS中的完整路径md5char(32)文件内容MD5秒传判断依据statustinyint0上传中1已完成2已删除chunk_info表分块上传时一个块一条记录字段类型说明chunk_idbigint块IDfile_idbigint关联file_infochunk_indexint第几块从0开始chunk_sizeint块大小tmp_pathvarchar(500)临时目录中的块路径user_info表存空间配额。计算已用空间时按file_info表status1的记录累加file_sizeHDFS侧再核对实际大小两边对不上说明有碎文件需要定时任务清理。业务代码给file_info加一个唯一索引(user_id, file_name)。同目录下重名文件通过“重命名加序号”落库。HDFS路径全部按/user/{userId}/{yyyymm}/{fileId}组织其中fileId是MySQL主键与原始文件名完全隔离。修改文件名、移动目录只改MySQLHDFS路径不用动。直接把文件名拿来当HDFS路径后患无穷——文件一改名路径断了引用关系全乱。4. 核心代码落地上传、下载、秒传和项目文档的检查顺序这一章是能“抄作业”的部分。基于Hadoop的百度云盘最简单可用的实现不复杂核心代码全部围绕FileSystem展开。下面给出最主流的Spring Boot后端实现思路代码按生产环境的落点写重点是链路结构和参数。4.1 上传接口从MultipartFile到HDFS的完整写路径正常上传流程Controller接收文件先落到本地临时目录再写HDFS最后插MySQL元数据。MD5计算不能在同一个网络输入流上重复读两遍先把MultipartFile转存到本地临时文件再从临时文件算MD5、写HDFS。PostMapping(/upload) public String upload(RequestParam(file) MultipartFile file, RequestParam(userId) Long userId) throws Exception { String fileId IdGenerator.nextId(); String hdfsPath /user/ userId / fileId; // 1. 保存本地临时文件为MD5和HDFS写入各读一次 Path localTmp Files.createTempFile(upload, .tmp); file.transferTo(localTmp); // 2. 计算MD5和文件大小 String md5; long size; try (InputStream in Files.newInputStream(localTmp)) { md5 DigestUtils.md5Hex(in); size Files.size(localTmp); } // 3. 写HDFS先保证父目录存在 FileSystem fs hdfsAdapter.getFileSystem(); Path dst new Path(hdfsPath); fs.mkdirs(dst.getParent()); try (InputStream in Files.newInputStream(localTmp); FSDataOutputStream out fs.create(dst, true)) { IOUtils.copyBytes(in, out, 8192, false); } // 4. HDFS写成功后插MySQL元数据 fileInfoDao.insert(new FileInfo(fileId, userId, file.getOriginalFilename(), size, hdfsPath, md5, 1)); return fileId; }逻辑顺序是强制的先把文件完整写入HDFS再更新MySQL元数据。反过来一旦MySQL先写了记录HDFS写失败这条记录就是脏数据占空间、占配额还要额外机制清理。create(dst, true)的第二个参数表示覆盖已存在文件。业务层HDFS路径由fileId生成正常情况不会重名覆盖保留这个参数是为了清理上一次失败残留的同名文件。常见的掉坑点是直接把/upload/xxx.pdf当目标路径完全不建父目录。HDFS的create在父目录不存在时抛FileNotFoundException。所有HDFS路径操作前先保证父目录存在这算是最典型的“血泪经验”。4.2 下载与断点续传seek定位和Range请求的配合下载逻辑比上传简单因为HDFS本身支持偏移量读取。Web层接收Range头把偏移量传给FSDataInputStream.seek。GetMapping(/download) public void download(RequestParam(fileId) Long fileId, RequestHeader(value Range, required false) String range, HttpServletResponse response) throws Exception { FileInfo fileInfo fileInfoDao.findById(fileId); FSDataInputStream in hdfsAdapter.getFileSystem().open(new Path(fileInfo.getHdfsPath())); long start 0; if (range ! null range.startsWith(bytes)) { start Long.parseLong(range.substring(6).replaceAll(-.*, )); } in.seek(start); response.setContentType(application/octet-stream); response.setHeader(Content-Disposition, attachment; filename\ fileInfo.getFileName() \); response.setContentLengthLong(fileInfo.getFileSize()); byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) 0) { response.getOutputStream().write(buffer, 0, len); } in.close(); }seek只修改“下一个要读的字节位置”不重新发起RPC也不重新定位块。必须在同一个FSDataInputStream实例上先seek再连续读不能每读一段都新建连接再seek——那会把单个文件的下载放大成几十次RPC握手。伪分布环境下这个做法看不出区别。到了三节点集群客户端要按块去对应DataNode取数据每次新建连接都要重新定位块位置20个块的文件就是20次额外握手下载慢到让人怀疑人生。断点续传的前端逻辑就是每次请求带上不同的Range头后端固定用同一个seek接口几十秒超时这类问题基本消失。4.3 秒传的实现MD5指纹表与HDFS路径复用秒传的本质不是“飞快上传”而是“发现文件已在HDFS里不再做第二次写入”。public String quickUpload(String userId, String fileName, String fileMd5) { // 1. 按MD5全表查重 FileInfo old fileInfoDao.findByMd5(fileMd5); if (old null) { return null; // 没有相同文件走普通上传 } // 2. 有相同文件只插一条新元数据复用旧文件的hdfs_path String newFileId IdGenerator.nextId(); fileInfoDao.insert(new FileInfo(newFileId, userId, fileName, old.getFileSize(), old.getHdfsPath(), fileMd5, 1)); return newFileId; }秒传的关键是MD5必须在客户端算服务端不能为了判断去读大文件否则秒传就不存在了。前端本地算好MD5提交给后端后端只负责查表和插记录。一个HDFS文件被多人秒传后file_info表会出现多条hdfs_path相同的记录。删除时不能直接删HDFS路径要先查还有没有其他file_info引用它只有最后一个引用才真正清理HDFS内容。否则一个用户删文件其他人的秒传文件立刻变成0字节这是最常见的“翻车现场”。秒传和分块上传是两条路。分块上传适合大文件分段写入每块单独算MD5、按顺序写到临时分区全部传完再合并。复杂度更高文件超过1GB时才有必要。入门项目用“整文件写HDFS 秒传”这一个组合已经覆盖大多数课程设计和面试要求。4.4 源代码与文档说明拿到项目压缩包先确认的四件事标题里的“源代码文档说明”是我们拿到项目包之后最需要梳理的信息。现实中这类包质量参差不齐有的能直接跑通有的少配置文件有的半成品。我拿到手之后的固定检查顺序如下。第一目录结构里有没有pom.xml或build.gradle。有Maven/Gradle项目直接按依赖列表恢复环境没有构建文件光找jar包就能耗掉半天。文档说明里如果写了“本项目为Maven工程”这一步就跳过。第二application.yml或hdfs-site.xml里的参数是否和你的环境一致。数据库连接地址、HDFS的端口、账号密码每套环境都不同。文档里出现的192.168.1.100不能直接用先确认自己的HDFS地址。用Windows下IDEA开发时也不直接连集群通常代码放Windows本地运行环境指向Linux服务器这个组合没问题但要做对两个前提HDFS端口对远端开放且HDFS配置里不写localhost。第三有没有数据库初始化SQL。有schema.sql或init.sql直接确认表结构是否和代码里DAO层的字段对得上。对不上运行时会各种Unknown column报错。第四文档说明里“部署步骤”和“环境要求”章节是落地的第一手依据。没有这两章就得自己根据代码逆推环境变量时间成本直接翻倍。这套检查逻辑比上来就把代码塞进IDEA跑一遍靠谱得多。没有配套源码的时候照着前三节的核心逻辑自己写一个最简版也比到处求资源更实在。5. 搭建和运行避坑覆盖新手前两周的5条异常排查记录下面5个问题按“现象 → 原因 → 解决”来拆。它们是从多个项目复现里提炼出来的每一条都值得在遇到时对照看。5.1 NameNode起不来端口被占、元数据冲突、配置没生效现象start-dfs.sh后jps看不到NameNode日志报Address already in use或者格式化两次后进程卡在启动状态。原因三种可能。端口被占用通常是之前残留的JVM进程没杀干净元数据冲突二次格式化没有清空旧数据目录配置没生效改的是hdfs-site.xml系统却从HADOOP_CONF_DIR读取了另一份配置。解决先停掉所有进程清空临时目录再格式化再启动stop-all.sh rm -rf /data/hadoop/tmp hdfs namenode -format start-all.sh如果还起不来检查环境变量echo $HADOOP_CONF_DIR echo $HADOOP_HOME确认HADOOP_CONF_DIR指向你真正改配置的那个目录。很多人配完参数结果进程用的不是同一份配置日志翻了几遍都找不到原因属于典型的“黑匣子”问题。5.2 写大文件报Pipe closed超时参数和失败替换策略现象Web上传超过100MB文件时报org.apache.hadoop.ipc.RemoteException: java.io.IOException: Pipe closed小文件正常异常消息很吓人日志看半天也定位不到具体节点。原因客户端写数据速度低于DataNode的socket超时阈值或本地防火墙拦截了长时间TCP连接。还有一层隐藏因素dfs.client.block.write.replace-datanode-on-failure.policy用默认值时低副本环境下失败后不会替换DataNode一个节点故障就直接断掉整个写管道。解决先确认没有坏节点执行hdfs dfsadmin -report看所有DataNode的Last contact是否为0再调大超时并明确失败替换策略# hdfs-site.xml 中追加以下参数单位是毫秒 dfs.client.socket-timeout600000 dfs.datanode.socket.write.timeout600000 # 允许失败时替换DataNode避免单点故障直接断掉整个写入管道 dfs.client.block.write.replace-datanode-on-failure.policyALWAYSALWAYS的意思是“客户端偏好在失败时继续用其他DataNode”不代表不报错。课程设计调成它能减少很多无意义的网络抖动重试生产环境我会保留默认值让故障暴露出来再说。5.3 页面看不到文件MySQL与HDFS的数据一致性误区现象HDFS命令行直接-put有数据能看云盘页面登录后文件列表却为空。原因页面文件列表查的是MySQL的file_info不是HDFS。命令行-put是直接往HDFS写数据不经业务层自然不产生MySQL记录。两类数据不一致不是Bug是设计如此。解决不要用命令行验证云盘功能。页面上传后用下面两条命令确认两边都有数据hdfs dfs -ls /userSELECT COUNT(*) FROM file_info WHERE status 1;如果两边数量差很多优先看业务层的上传日志重点确认MySQL插入是否成功。常见反例是HDFS写入完成后事务失败回滚HDFS里多了一个孤儿文件。这时候需要定时任务把“HDFS存在但MySQL不存在”的文件清理掉反过来也要把status0超过一天的文件标记为失效。status字段设计成tinyint前后端判断起来都方便。提示清理孤儿文件不要直接rm -fHDFS路径先查MySQL引用。尤其是秒传功能上线后同路径多引用的情况会越来越多。5.4 浏览器下载大文件卡死或超时现象下载超过200MB的文件浏览器转圈很久最终报Error或直接下载0字节。原因HTTP响应没有设置Content-Length也不走分块传输Tomcat把整个响应缓冲在内存里再发内存不够就连接超时。文件越大这个问题越明显。解决下载接口边流式读取HDFS边直接写入response.getOutputStream()并且设置Content-Length为元数据里的file_sizeresponse.setContentType(application/octet-stream); response.setHeader(Content-Disposition, attachment; filename\ fileInfo.getFileName() \); response.setContentLengthLong(fileInfo.getFileSize());Content-Length对下载很关键浏览器拿到它才能显示进度条下载工具才能做断点续传。设置后大文件在客户端会有明确进度前端请求失败时也更容易区分是网络中断还是服务端异常。5.5 并发上传拖垮NameNodeFileSystem复用与连接泄漏现象用户量起来后NameNode日志频繁出现连接相关告警界面操作卡顿GC时间变长。原因每个上传请求都执行FileSystem.get但没复用连接数爆炸。典型错误写法是每个Controller方法内部都new Configuration()再FileSystem.get()用完不关也不主动释放最终把NameNode的RPC线程池打满。解决把FileSystem定义成Spring的单例Bean整个进程维护一份配置、一个实例。文件流操作完只关FSDataOutputStream和FSDataInputStream不关FileSystemComponent public class HdfsStorageAdapter { private FileSystem fs; PostConstruct public void init() throws Exception { Configuration conf new Configuration(); conf.addResource(new Path(/etc/hadoop/core-site.xml)); fs FileSystem.get(new URI(hdfs://node01:9000), conf, hadoop); } public FileSystem getFileSystem() { return fs; } }如果确实要创建独立实例用FileSystem.newInstance而不是FileSystem.get并且必须用try-with-resources手动关闭。但云盘这种单一集群场景newInstance基本用不上。另外JVM里FileSystem关闭后连接不会自动恢复误关了就要重启应用这也是“一关就全断”的教训。6. 用压测确认Hadoop云盘的真实边界再决定要不要继续投入项目做成什么样才算能交付不是能传文件就行而是要知道它在多少并发、多大文件下开始出问题。一个最小压测花不了半小时值得在做完功能后跑一轮。6.1 一个最小并发上传压测脚本用Python的requests库和threading模拟20个用户同时上传文件统计每个请求的耗时分布import threading import time import requests URL http://localhost:8080/upload FILES {file: (test.bin, open(/tmp/test64m.bin, rb))} results [] def upload(): start time.time() try: resp requests.post(URL, filesFILES, data{userId: 1}, timeout600) cost round(time.time() - start, 2) results.append((cost, resp.status_code)) except Exception as e: results.append((-1, str(e))) threads [threading.Thread(targetupload) for _ in range(20)] for t in threads: t.start() for t in threads: t.join() costs [r[0] for r in results if r[0] 0] print(f20个并发请求成功{len(costs)}个耗时中位数{sorted(costs)[len(costs)//2]}秒)压测结果先看两条成功数量是否等于20耗时分布是否均匀。如果单次耗时忽高忽低说明某个环节在排队。继续把测试文件从64MB改成512MB观察同一数量级并发下的响应差异很快就能判断瓶颈在HDFS写入还是Web层。6.2 找到瓶颈后再调参块大小、Handler数、副本数值得动哪些HDFS侧能调的参数集中在hdfs-site.xml和core-site.xmldfs.blocksize268435456把块从128MB提到256MB大文件顺序读场景下降低DataNode和NameNode的交互频率。小文件为主的话别动它块太大反而浪费。dfs.namenode.handler.count100默认值偏低多客户端并发时提高RPC线程数有直接效果。调整后要观察GC和CPU不能盲目加。dfs.replication2如果只是为了演示功能副本数从3降到2能省磁盘但生产环境的可靠性打了折扣。课程设计降到2可以真实业务不建议。到这里我的个人习惯是接真实用户前必跑一轮压测看到NameNode的RPC压力数据才敢上线。这个体系里HDFS反而不是最先卡住的那层——MySQL的file_info表忘了给status加索引查询慢到页面列表3秒打不开那才叫尴尬。压测这个习惯能把这类隐藏问题提前暴露。希望帮到你。本文还有配套的精品资源点击获取