作者回复: 1 专栏2后半部分讨论过估算的思路，注册用户数->在线用户数->并发用户数，根据业务场景的不同，这个数据是逐级以几十倍到几百倍的比例递减，极客时间这个场景的话，500万注册用户，并发用户大概几千吧。 并发数 * 响应数据量 = 带宽 2 用户和存储是逐渐增加的，不是一致性投入1亿TB，稳定下来，每年实际投入百亿左右即可。这个成本不高的，百度网盘会员费每年300，我们十亿用户只要10%成为付费会员，营收300亿。 4 ceph是一个开源软件

作者回复: 网盘文件以小文件为主，HDFS的设计目标是大文件。如果用HDFS，需要进行文件合并，后面短视频架构探讨这种设计方案。

作者回复: 谢谢建议

作者回复: ceph已经实现多副本，所以网盘自己不需要考虑了

作者回复: 是的，应该在Physics_File，我修订下设计文档。 感谢你的评审意见。

作者回复: 会比较耗时，所以用户端上传时应该有两个进度条，一个是上传准备进度条，一个是上传进度条。 以block为单位进行秒传，并不能解决问题，一个大文件可以秒传，那么每个block都需要判断MD5是否存在，上传下载都更耗时。

作者回复: 1 Block服务器就普通的web应用，http协议，有API 2 文中的设计是检查user表，用token确实会更灵活、更低耦合一点，感谢建议 3 首先，physical文件不会在用户删除时立即删除，不管是不是有秒传关联。其次，网盘会定期清理垃圾文件，所以，physical文件需要有个引用计数器，每次有秒传关联，计数器+1，每次关联logical文件删除，计数器-1。这个关注点非常好，是关键实现细节，是架构评审要发现的要点。 4 好问题，我的想法，加标志位或者求size，操作都比较重，性能压力大。同时，从用户体验角度，我觉得文件的可见性应该以用户一次上传为单位，一次上传若干个文件，在全部上传未完成前，应该全部不可见。所以，我觉得用一个MySQL内存数据库，临时记录用户上传中的文件元数据，一次上传全部完成后，再将数据同步到MySQL元数据库。

作者回复: 可是查找的时候，是按照用户和文件名查找的，用MD5分片如何完成查找呢？

作者回复: 我也觉得不是很合适。 07提到了HBase替代方案。但是用HBase替代的话，存储结构如何设计呢？需要考虑下。