# kami-cloud **Repository Path**: applesack/kami-cloud ## Basic Information - **Project Name**: kami-cloud - **Description**: 基于vertx和kotlin实现的文件服务器 - **Primary Language**: Unknown - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 1 - **Forks**: 1 - **Created**: 2022-02-05 - **Last Updated**: 2022-06-06 ## Categories & Tags **Categories**: Uncategorized **Tags**: 个人网盘, 文件服务器, Vertx ## README # **kami-cloud** #### 介绍 **KamiCloud**是一个面向个人和小型团队的网盘应用, 可以用于在局域网或者一些场景下共享和管理文件系统. 除了提供基本的上传下载功能, 它还提供了如下特性. - 支持细粒度的配置文件或文件夹的权限, 控制各种访问规则, 如只允许特定的用户对某文件夹内的文件上传, 下载, 浏览, 编辑等操作; - 不限制上传文件的大小, 但是允许配置某文件夹的容量限制, 支持断点续传; - 实时更新文件视图, 当多个用户同时浏览同一个目录时, 其中一个用户修改了某文件, 其他用户能实时观察到更新; - 轻量级的架构 > *README.md 创建于 2022/3/11* > 为什么项目名称叫`KAMI`? #### 软件架构 - 后端部分: `jdk11`, `kotlin`, `gradle`, `vertx`, `sqlite`, `协程` - 前端部分: `angular`, `ant-design`, `typescript`, `rxjs` #### futures & bugs | 组件 | 描述 | 状态 | |---------|----------------------------|-----------| | 1. 权限系统 | 根据用户的等级和文件的访问规则决定是否拦截用户的操作 | 已完成 | | 2. 缓存服务 | 内部通用的线程安全的键值对缓存, 支持定时删除 | 已完成 | | 3. 定时任务 | 定时任务管理器, 可以管理和定时执行提交的任务 | 已完成 | | 4. 断点续传 | 上传任务的暂停和恢复 | 已完成; 需要优化 | | 5. 日志系统 | 当发生文件系统修改事件时, 记录日志 | 开发中 | | 6. 广播服务 | 将事件分发到各个客户端 | 未开始 | | bug | 描述 | 状态 | |--------------------------------|-----------------------------------------------------------|-----| | 1. 空文件无法上传 | 由于当前文件上传实现是根据文件大小来切片分段上传的, 但是空文件无法切片导致逻辑上无法执行切片导致不能执行上传流程 | 未开始 | | 2. 同时上传多个文件时, 文件只能排队上传, 不能并行上传 | | 解决中 | | | | | 部分已经实现的功能不统计在内 | 功能 | 描述 | 状态 | |-------------|---------------------|-----| | 1. 右键文件属性 | 显示文件的详细信息 | 未开始 | | 2. 文件的curd | 对文件的创建, 删除, 重命名, 移动 | 未开始 | | 3. 实时更新文件视图 | | 未开始 | | | | | #### 安装教程 编译此源码需要`IDEA`作为开发环境, 同时需要有java11, gradle等编译环境; 由IDEA拉取项目, 按照提示进行编辑, 然后等待编译完成即可; > 有概率因为jdk和gradle的版本问题导致编译失败, 这个自己解决吧 > 参考: 编译项目时, gradle使用的jdk版本是11 --- #### 日志 ##### 2022/3/11 优化内存占用 在应用启动后, 和上传任务开始前, 上传任务结束后, 主动调用GC ![内存占用优化](.\docs\img\jprofile_内存视图.png) ##### 2022/3/12 修改前端文件上传逻辑 之前的上传逻辑是, 预先将所有的文件块信息保存在Map中(包括包含文件切片的FormData), 当用户点击上传按钮后, 将Map中是所有文件块顺序 发送出去, 这样做的问题是, 当同时上传多个文件, 由于后面的任务执行顺序晚与前面的任务, 导致后面的任务需要进行排队... 直观的感受是同时只能进行一个任务, 其他任务处于等待状态, 进度条没有更新 修改后的逻辑 不一次性保存所有的文件分块信息, 只保存需要上传的文件块的ID, 将这些ID信息保存在一个数组中, 这样多个任务就产生多个ID序列, 开始上传时, 循环的遍历任务列表, 每次取一个子任务的一个文件块发送, 然后立刻转到下一个任务 ![多文件并行上传](.\docs\img\多文件并行上传.png) ##### 2022/3/22 文件视图同步 当多个用户同时访问同一个文件夹时, 其中某个用户创建/删除某文件时, 其他用户能同时接收到更新 基于sockjs和eventbus实现 ##### 2022/3/26 - 3/28 对系统内底层的一些api重新设计, 将部分原来的挂起方法修改为返回Future的异步方法, 将是否同步执行的主动权交给api的调用者; 当多个用户同时使用web界面时, 当其中某些用户对文件系统进行修改(上传文件, 删除文件)时, 用户之间能同步存储容量信息;