@asdgsdg98 一般都是用来做 DNS 劫持来切到缓存服务器的 如果你换到别的 DNS 这个其实就很难起作用了 所以有的学校会有这个限制 要不也没别的手段可以强制学生用这个缓存服务器了

缓存里面其实不只是常用软件 还有大家看的优酷啥的 那才是大头

所以有时候会觉得速度慢 其实就是缓存服务器有问题 我当年就遇到过某软件缓存服务器就缓存了一部分……

多半是因为学校内部有缓存服务器 你可以自己解析一下一些资源的 ip 地址 应该都被解析到缓存服务器了

实际上绕过限制也很简单 换成 tcp 协议就行了 一般好像不封 tcp

@alexanderchiu 对 第一层其实存具体的节点和文件位置就行 止痒方便你在 vfs 或者 fuse 上面写的时候能生成具体的目录结构 然后 storage node 上面再去具体负责单个文件的存储 然后用 key-value 的数据库来做索引 负责把文件从具体位置捞出来

用 Hash 得话稍微注意一下文件目录的数量就行 或者你可以换个别的方式 Hash 的问题就是在于你的一些参数变了可能所有文件的位置都要重新来一遍 不过因为是毕业设计所以应该也不用去考虑这些复杂的问题 但是如果文件数目多的话你要注意具体的 Node 上面单个目录下文件的数量 具体的设计可以参考 Ceph 的 Filestore 的实现

开源的话有个符合你要求的
https://github.com/chrislusf/seaweedfs

LevelDB RocksDB 不要直接拿来存文件 用来存你具体文件的 block 的索引就好 Ceph 的 BlueStore 底层就是用 RocksDB 来存文件块索引的 相当于 XFS 里面 inode

分布是的话你套两层就行了 第一层是分布式的 key-value 数据库 用来记录所有文件的记录以及这些文件存在哪些节点上方 在单个节点上你可以直接把文件按照一定规则写入到不同的目录下面 然后有一个 daemon 一类的帮你存取文件 如果真的是真海量的话 你具体的 storage node 上面其实也需要一套 RocksDB 来帮你缓存具体的文件位置来加快索引速度 如果问减少的话其实按照一定 hash 来存就行 你甚至可以在每个机器上面跑一个 Minio 然后再用一个集中化的数据库来管理那些文件存到那个 Minio 上面都行……

套个 rocksdb 也没啥不好的 参考 Ceph 的 OSD 部分 实现 用 rocksdb 去缓存整个存入文件的索引 可以看看老版本基于 Filesystem 的实现

基本就是文件切块直接存盘到系统 fs 上面 然后按照一定规则生成目录 避免 fs 在某个目录下太多文件导致效率降低 然后利用 key-value 一类的数据库来存文件的具体索引 分布式的话就在上面再套一个 你可以试试 Cassandra 或者选其他的分布式 key-value 数据库 记录一下某个文件具体落到某个那个位置去就行 然后具体位置再由具体的 key-value 去把文件块找出来返回就行

简单点的实现可以参考下 Minio ？但是那个是对象存储 不知道是不是符合你导师的意思就是了…… 看你导师的意思应该是让你实现个基于块存储吧

You don’t need to be a nice person, but you need to be professional.

不过超过十万人了应该是 Apple 吧……

盲猜不是 Apple 就是 Netflix

然而美帝除了圣诞节 一堆假都是一天……

Epic 的上架渠道远没有 Steam 透明 绿光一堆游戏是上不到 Epic 的