顶点云为我 2016 年的某个课程设计，旨在基于北邮校园网搭建一个小规模的云存储、共享平台。本文简单介绍顶点云应用程序服务器设计目标，分析需求。此文章发布时项目尚未编写完成，与此项目相关的文章将随项目同步更新，并收集在专栏 《顶点云设计与实现》 中。

写在前面

• 顶点云为我 2016 年的某项课程设计，项目题目为自拟，目标是基于北邮校园网搭建一个小规模的云存储、共享平台。项目在 GitHub 托管仓库的网址是：https://github.com/Forec/zenith-cloud。
• 此部分文章主要介绍顶点云的应用程序服务，同时附带了一个用于测试的客户端（无GUI）。顶点云正式的客户端目前正在由 non1996 编写。在我写下这篇文章时，顶点云的应用程序服务器已经实现了文件传输以外的多数逻辑功能，以及文件的并发下载。
• 在接下来的文章中，代码的具体实现均使用 Golang 代码表示，我将假设读者掌握 Golang 的基本语法（或者 C/C++ 的基本语法），并且了解 channel、goroutine 的概念。
• 作为本科阶段的一项小型课程设计，且时间紧迫，我很遗憾此项目中很多实现非常幼稚，许多地方为了简化实现，我采用了一些闭门造车的、很愚笨的、且与主流实现方案相悖的方式。在将基本功能实现后，如果还有空余时间，我会尽量修正这些糟粕，简化代码。这个项目的 BETA 版本预计完成时间在 11 月底，12 月上旬将完成客户端的图形界面，12 月中旬将完成 Web 版本。如果还有空余时间，可能会考虑实现一个 Android 客户端。

项目介绍

面向用户功能

• 文件存储：用户可将文件上传至云服务器
• 文件下载：用户可从云服务器下载文件
• 文件传输状态保存（视项目进度快慢考虑）：支持用户下载/上传文件过程中暂停
• 文件共享：用户间可分享资源，通过共享链接和提取码获取其他用户的私有分享文件
• 文件秒传：云存储空间存在相同文件时直接 Fork
• Fork：用户可 Fork 其他用户分享的文件至自己的存储空间
• 文件操作：用户可对自己上传的文件/Fork的文件进行管理，包括最基本的拷贝、移动、删除
• 目录操作：用户可对自己存储空间中的文件目录进行管理，包括最基本的拷贝、移动、删除、新建
• 在线编辑：用户可在客户端/Web端即时新建并编辑一个文本文件，并随时更新至云服务器
• 图片在线浏览：用户可在线浏览云服务器上的图片
• 视频在线播放：用户可在客户端播放云服务器上的视频文件
• 基本用户交流：用户间可以发送消息，可进行时延不高的延时通讯
• URL导入数据（视项目进度快慢考虑）：用户可从 URL 导入文件至云存储，即实现类似迅雷离线下载功能

系统功能

• 文件分块、重用：将文件分块存储，不同文件的相同块仅存储一次，节省物理存储空间。在要实现的云存储系统中，为了降低复杂度，文件将不分块存储，仅仅实现相同文件的重用
• 文件压缩存储、传输：用户上传、下载的文件应采用某种压缩算法以节省带宽
• 文件并发下载：用户下载多个文件时，在允许线程内应支持并发下载
• 文件传输状态保存（视项目进度快慢考虑）：用户下载/上传文件过程中触发终端操作时，传输进度的保存
• 用户目录管理：系统应当对每个用户分别维护文件目录结构
• 用户权限管理：用户文件只能被用户自己或其他持有文件提取码的用户查看、下载、Fork，用户文件只能由用户自身管理（移动、删除、设置私有/分享）
• 用户消息推送：管理员可以向用户推送消息
• 用户消息传递：系统应提供渠道使用户间的消息在短时延内交互，如用户间分享文件提取码
• 用户认证管理：同一时刻允许且仅允许一个用户客户端在线，后登录的客户端应当使先登录的客户端下线。数据库中应存储用户密码的不可逆加密值，用户登录及文件传输过程应使用随机密钥加密（保险的方式是对随机密钥采用非对称加密，但为了简化实现难度，要实现的云存储系统将使用对称加密算法，因此安全性有很大隐患，在后面的文章中将分析对我实现的云存储系统进行中间人攻击的可行性）

原理分析

存储逻辑

• 要实现重复文件的非冗余存储，需要对每个上传的文件块（在要实现的云存储系统中，因为去除了文件分块操作，因此下面所有“文件块”实际上是文件）计算该文件块的 MD5 值，与数据库中已存在的 MD5 值对比，相同则直接 Fork 并取消用户的上传操作（文件秒传）。
• 相同的文件块仅存储一次，每个文件块应当维护一个“引用值”。“引用”的定义为：当多个用户在各自的存储空间中分别保存同一个文件一次或多次，则实际上这些文件均指向同一个文件块 B，而在物理存储中，文件块 B 仅存储一次。我们称这些用户各自存储空间中的文件记录引用了 B，称这些用户在各自存储空间中指向 B 的文件记录为 B 的引用。
• 根据引用的定义，只要存在某个用户在自己的云存储空间中保存了文件块 B 的引用，该文件块就不能删除。当某个用户对文件块 B 的引用做复制、Fork操作时，文件块 B 的引用值应当随操作数增加；当某个用户删除文件块 B 的某个引用时，文件块 B 的引用值应随删除次数减少。
• 存储逻辑对用户不可见，即用户可以修改自己用户空间中的引用（引用实际就是用户所看见的文件），如重命名、移动、复制等，但修改的对象仅仅是用户空间中的引用，而非真实的文件块。只有用户对引用的内容做修改时（例如此引用指向一个文本文件，用户修改了文本文件的内容并试图保存），系统才应当创建新的文件块以记录修改。在下面的介绍中，“引用”和“文件”等价，均为数据库中指向文件块的一条记录，而“文件块”才代表真正物理存储中的文件。
• 用户目录维护：为了简化用户存储空间的目录维护，我将每个目录均视作一类特殊的引用，关于这一点的原因、实现和分析将在后面的文章中讨论。举个例子，用户云存储空间中有一个文件 /home/forec/run.sh ，则在数据库的引用表中，有四条记录属于该用户，分别是 /，/home/，/home/forec/ 和 run.sh。

数据库结构

根据存储逻辑和之前的功能介绍，我们需要五个表分别记录：文件块、文件块的引用、用户、用户消息、用户操作记录。

文件块表

• 文件块的 ID：此列应为该表的主键，自增，INTEGER PRIMARY KEY AUTOINCREMENT
• 文件块的 MD5值，VARCHAR(32)
• 文件块的大小，单位为字节：INTEGER
• 文件块的引用数：INTEGER
• 文件块的创建时间：DATE

文件块引用表

• 文件块引用的 ID：此列应为该表的主键，自增，INTEGER PRIMARY KEY AUTOINCREMENT
• 文件块引用的所属用户 ID：INTEGER
• 引用的文件块的 ID：INTEGER
• 引用在用户目录下的绝对路径：用户根目录为 /，此列类似 /home/work/cloud/，VARCHAR(256)
• 引用的外链：当用户试图共享此引用时，其他用户可以通过外链访问此引用（Web端，客户端应当可以解析此外链并在客户端中打开）。如果该引用为私有，其他用户需要输入提取码才可查看，VARCHAR(128)
• 引用创建的时间：DATE
• 引用的分享数：当一个用户分享该引用时，如果其它用户 Fork 了该引用，则该引用的分享数应增加。与 GitHub 上的 Fork 操作不同的是，如果用户 B Fork 了用户 A 的某个引用，用户 C 又从用户 B Fork 了这个引用，则 A 的引用分享数增加 1（B 的 Fork 操作），用户 B 的引用分享数增加 1（C 的 Fork 操作），INTEGER
• 引用的下载数：当一个用户从此引用下载对应的文件块时，此引用下载数增加，INTEGER
• 引用的文件名：此项为用户所看到的文件名，可能有多个不同名的引用指向同一个文件块，VARCHAR(128)
• 引用的私有性：此引用是否对其它用户可见，默认为私有，即仅用户个人可见，BOOLEAN
• 引用的提取码：在用户设置引用为私有的情况下，可以生成外链，持有该外链提取码的其它用户可以查看该引用，VARCHAR(4)
• 引用是否为目录：此引用是一个目录（文件夹）还是一个文件，BOOLEAN

用户列表

• 用户的 ID：此列应为该表的主键，自增，INTEGER PRIMARY KEY AUTOINCREMENT
• 用户名：此列应唯一，VARCHAR(64)
• 用户密码加密后的值：VARCHAR(128)
• 用户创建时间：DATE

用户消息列表

• 消息的 ID：此列应为该表的主键，自增，INTEGER PRIMARY KEY AUTOINCREMENT
• 接收消息的用户的 ID：INTEGER
• 发送消息的用户的 ID：INTEGER
• 消息内容：VARCHAR(512)
• 消息发送时间：DATE

用户操作记录列表

• 操作记录的 ID：此列应为该表的主键，自增，INTEGER PRIMARY KEY AUTOINCREMENT
• 用户的 ID：INTEGER
• 操作内容：VARCHAR(128)
• 操作时间：DATE

专栏目录：顶点云（应用）设计与实现
此专栏的下一篇文章：顶点云（应用）的认证、传输协议设计

原创作品，允许转载，转载时无需告知，但请务必以超链接形式标明文章原始出处(http://blog.forec.cn/2016/11/12/zenith-cloud-0/) 、作者信息（Forec）和本声明。