文件管理系统架构设计
相关技术知识：
1，背景概述
如何设计一套文件管理系统？这个文件管理系统经济实惠、可自部署、支持多人分享下载
或者换个方式来说，我如何设计一套百度网盘、夸克网盘，实现经济性、高速性、分享性、敏感文件封禁
同时，我2020年在hik从零设计过一套文件管理系统，有一些可借鉴的点。
2，需求拆分
| 需求 | 翻译 | 实现 |
|---|---|---|
| 经济性 | 花费的资源、钱少 | 使用资源少、最好只需要话费文件存储和网络的费用 没有内网部署要求的话，可以直接使用云厂商的对象存储服务 如果要求内网部署，那么可以使用开源的MinIO |
| 高速性 | 下载速度快 | CDN加速、PCDN加速等等，能否利用p2p技术？ 将对象存储服务的设置CDN加速 |
| 分享便捷 | 分享很简单，也有多种分享控制 | 1，链接分享 2，分享时间、次数限制 |
| 敏感文件封禁 | 发现敏感文件统一封禁 | 统一文件索引，抽象分离实体文件与文件对象 |
3，数据对象设计
最为核心的部分是文件对象，我在这里将文件对象拆分为2层
1️⃣抽象（文件）层
该对象是对外显示的文件数据对象，他主要记录文件与用户的绑定关系，与实体文件的1对1映射数据
2️⃣实体（文件）层
实体文件对象是直接与对象存储服务中真实存在的文件1对1映射
如果要分享一个文件给其他人，那么直接给被分享人新建一个抽象文件并添加索引至实体文件对象即可
如果要将一个已被确认的问题资源封禁，那么直接封禁实体文件层即可
实体文件无论被分享多少次，他在对象存储中都只需要一个副本即可，甚至用户上传重复文件时，只有比较其md5码与实体文件一致，那么直接退出，添加索引即可，这个也是百度秒传的实现原理，这样做也极大的节省了存储资源
4，服务架构
该文件系统是一个1️⃣查询文件、2️⃣下载文件、3️⃣上传文件、4️⃣删除文件，这四个操作频次依次降低（骤降）的情况。
同时查询、下载（可以归类到查询操作中）、上传要求实时性，就是用户操作了一定要有结果，虽然删除在用户眼里也需要实时性，但是我们可以标记逻辑删除，之后利用计算资源闲时进行资源删除。
考虑到系统的业务特点，整体业务拆分为3个服务，文件业务服务、文件上传服务、辅助服务
4.1，文件业务服务
我们将查询、删除逻辑整合，编写一个微服务，这个微服务需要部署很多个节点以达到高并发、高可用、高性能
进行查询时，先过布隆计数器、防止缓存穿透，然后查询redis-cluster集群中的目标数据，查询操作的访问基本是很少的概率会到PostgreSQL数据库查询，这极大的提升了响应速度。
4.2，文件上传服务
这里要分两种情况：
1️⃣文件流直接传递给对象存储服务（阿里云OSS、MinIO等）
如果是这种模式的话，完全可以把文件上传服务与文件业务服务整合到一起，因为上传文件操作必然是一种“多步骤”事务操作。
步骤：1，获取上传文件url地址；2，进行文件上传；3，主动或者被动感知上传事务完毕；
2️⃣文件流经由微服务本体透传给对象存储服务
这种适用于局域网（内网）的小文件的存储，之前我在hik的就是使用这种，上传文件的事务一步就搞定了，相较于“多步骤”的事务操作，更加简洁，事务原子性更强，脏数据少！但是这种操作也有缺陷就是，他是一种io密集型操作，一次上传操作耗时、耗费内存较多，所以，如果是这种情况的话，我倾向于将上传操作独立出来，单独按需分配资源。
4.3，辅助服务
将实体文件删除的事物以及其他非实时要求的操作整合到这个服务中，外部用户进行文件删除时，先调用“文件业务服务”将文件标记为逻辑删除，同时将异步删除操作丢给kafka消息队列，“辅助服务”可以选择在系统资源消耗的闲时启动去消费处理异步删除实体文件以及与之相关的业务逻辑。（你可以理解为这是一种空间换时间的操作）