文件传输

EMQX
1

为了解决文件名冲突和单个目录下文件数量过多的问题，EMQX 在保存导出文件时，使用了分桶存储方案。该方案工作原理如下：

  • 先计算出文件 ID 和客户端 ID 的 sha256 哈希值，比如：ABCDEFG012345...。
  • 将文件存储在 6 级目录层次结构中，每一级定义如下：
    1. 哈希的前两个字节作为第一级目录名称；
    2. 接下来的两个字节作为第二级目录名称；
    3. 剩余的哈希作为第三级目录名称；
    4. 转义的客户端 ID;
    5. 转义的文件 ID;
    6. 元数据中的文件名作为最后一层。

例如，导出的文件会存储在这样的位置中：AB/CD/EFGH.../{clientid}/{file_id}/{filename}。

您好，此处有疑问：先计算出文件 ID 和客户端 ID 的 sha256 哈希值，比如：ABCDEFG012345...。文件ID和客户端ID是单独计算哈希还是怎么计算呢？单独计算的话就是两个哈希值。如果合并计算，是吧文件ID和客户端ID拼接成一个字符串再计算哈希值吗？期待您的答复

2

你好，请问原文的链接是来自哪个位置呢

3

你好，是这个：文件传输服务端配置 | EMQX 企业版文档

5

您好，是这个链接：文件传输服务端配置 | EMQX 企业版文档

服务端版本是EMQX Enterprise5.6.1，服务端生成的路径类似这样：79/90/556FD5C1162FAEAD5CDA9C26FBA77A1EE1FF，不论用文件ID还是客户端ID计算sha256得到的位数和值都和服务端都对不上（文件ID sha256哈希值： ce8457d59078a699acb70416f88155a96a906b7b7aad43708402e3a3bcc8a4b4，客户端ID sha256哈希值：94f8f7728ec58c9e74657399fa6e4a36439579849f90fee466e441d92b9182e1
）我们目前着急使用，麻烦能尽快答复一下吗？感谢！

6

目前你用不了，并不是简单的拼接：

他用了 erlang 的内部函数来构造 hash。得看看后续如何优化。

hash(term_to_binary({clientid,FileId}))

目前只能通过可以使用 http api 来访问文件。避开这个问题。
顺便问一下，为什么你们想使用这个目录的方式：是在自建 http 或者 ftp 下载文件么？

7

我们是上传完成后上报文件具体路径。如果这层走不通，就只能用考虑http去访问文件了。感谢您的解答