云盘开发日志1

云盘是一个比较笼统、含糊的概念。作为自开发的系统，习惯的口头就是在不使用互联网的前提下，以自己的经验和理解去分析自己感知的几点云盘的重要概念。

1. 云盘内部应该有永久保存，可能保存，暂时保存的三种存储方式
2. 文件保存时，对文件的存储方式应该分为两种状态：一是物理保存，直接存储硬盘；二是逻辑保存，经过逻辑转换等保存在特定的某些媒介中。
3. 所有的规则校验应该都在云盘中完成。
4. 用户表和云盘系统中的表关联不多，用户只做记录操作。

简单的得出以上几点自我分析的概念后，经过互联网上对云盘知识的探索，发现了自己的一些理解偏差。

1. 云盘和网盘不同，除了用户端自我内存中的文件列表外，云盘还要偏重于展示分享当前云盘中的文件。
2. 作为云盘应用，应该拥有简略的在线游览功能，而不是简单的进行文件上传和下载的交互。
3. 云盘的安全极为重要。

在脑中有了这些简单的概念后，一个简单功能的云盘就可以进行需求分析准备了。

准备

技术选型

首先云盘应用很难作为一个独立系统展现，它往往都是云技术下的一个衍生产物，理所当然的将整个系统当成一个服务看待。 通过自己当前的毕生所学，想用的技术有下：

1. nacos，服务注册
2. fegin，服务调用
3. sa-token，令牌管理
4. springboot，项目基石
5. redis，缓存管理，某些文件的存储媒介

需求分析

1. 文件上传
2. 文件下载
3. 文件展示
4. 文件展示

第一阶段的功能，无非围绕这四个展开。其中，文件这个名词极为重要，所以我们需要设计一张fileinfo，文件信息表，用来开荒。 简单的设计如下：

有了文件信息表，可以开始以上功能的分析。

请求上传[文件上传的前提]

• 这个接口的存在意义：分摊文件上传接口的压力，和服务器io流的负荷。

在用户上传文件前，应该会有三种特殊情况，只有当条件合法时，才允许上传文件接口的调用。

1. 第一情况：文件或用户非法，返回失败，禁止上传
2. 第二情况：文件和用户合法，返回成功，继续上传
3. 第三情况：文件在服务器中有物理层面和逻辑层面完成一样的数据，所以直接在服务器端进行复制操作，返回成功，终止上传。

上传文件

• 上传接口，因为三种存储概念的影响所以需要走三套逻辑，

1. 永久保存时，直接将文件信息和用户使用情况进行记录，保存在服务器端的物理硬盘上
2. 可能保存时，在第一种的情况下，另拉一条数据线进行时间和使用情况的权重标记，在逻辑可行下，未来的某个时间里进行逻辑上或物理上的删除。
3. 暂时保存，打上时间标记，到时清除。

• 一个重点，是否可以将文件进行转换，以另一种状态保存在服务器中。

我想的是用一些媒介，比如对于文件大小偏小的，将文件转换为base64的字符串直接存储在redis缓存中。 但是这种模式只好适用在暂时保存的流程中。 还可，就是将文件转换为二进制数组，在服务端适用某个文件，或是常数记录。

下载文件

• 下载文件，需要着重的点是，文件在服务器内部，到用户端前端这过程中，文件的流通形式。

1. 因为是web应用，所以除开包装后端到前端的文件下载请求头和参数外，文件应该以是初始以二进制数组-》文件流的变化。
2. 因为每个文件的存储形式和模式不同，所以需要分类讨论。

文件展示

• 文件展示功能，着重在页面的感观优化上

1. 页面文件的展示直观，并且所有文件列表，通过文件类型进行分类
2. 提供包含但不限于，模糊查询，时间排序这些影响查询因素的功能。
3. 和用户表联动，在上传文件和下载文件等等，操作文件时，动态的变化当前用户在云盘中可用内存的大小。

文件删除

• 无论什么系统，删除功能都要注意，数据很重要，只做逻辑上的删除。

1. 注意redis中，需要删除文件的缓存遗留问题。
2. 删除文件过程中，业务回滚的考虑。
3. 删除文件时，上传文件和当前删除文件的物理冲突，需要考虑到删除文件这个应该可能需要上锁的操作对其他功能的影响。