[FUTURE]</openbmclapi/files>文件列表分片

[zyxkad]

当我请求/openbmclapi/files时，至少需要等待20s
而这20s内请求的数据99%都是不必要的
所以我建议将/openbmclapi/files进行分片处理，以便于节点缓存

如:
2021年10月更新的数据存放至/openbmclapi/files/202110.json
文件格式如:

{
  "new": [{"size":1024, "hash":"00112233445566778899", "path":"/maven/com/***"},{"size":2048, "hash":"00221133445566778899", "path":"/00/221133445566778899"}],
  "del": ["[file hash]", "00112233445566779988"]
}

[zyxkad]

节点应保存最新一次请求所请求的数据日期，当下次节点重启时，读出此日期并按照向后请求所有列表直至当日日期

[bangbang93]

除了全量节点，每台节点持有的文件都可能是不一样的

[bangbang93]

你是否没启用gz或者json处理速度太慢，这个请求不应该卡20秒

[zyxkad]

你是否没启用gz或者json处理速度太慢，这个请求不应该卡20秒

可能是我网速较慢的原因吧

[zyxkad]

除了全量节点，每台节点持有的文件都可能是不一样的

这点不影响列表分片，对于主服务器来说，全量节点与分片节点的性质都是一样的

[zyxkad]

服务器理应保存了每个分片节点的数据，如果有新文件出现，必定会更新分片节点的文件列表。这与全量节点相同。不同之处只在于，全量节点可以共享列表，而分片节点不行

[bangbang93]

服务器理应保存了每个分片节点的数据，如果有新文件出现，必定会更新分片节点的文件列表。这与全量节点相同。不同之处只在于，全量节点可以共享列表，而分片节点不行

不是这样设计的，文件被划分为若干分片，节点也会随机持有若干分片，节点不会直接拥有文件。新文件会比根据平衡规则选择一个分片放入

你这样子搞还要单独给每个节点维护每次的文件差异

[bangbang93]

只要用好HTTP缓存，只有第一次请求会返回完整文件列表，后续请求只要文件没有变化都是304响应

[zyxkad]

只要用好HTTP缓存，只有第一次请求会返回完整文件列表，后续请求只要文件没有变化都是304响应

我明白，我的问题就是，一旦有一个字符发生变化，这20秒又要重新请求一遍。虽然相比于10分钟的轮询间隔来说这20秒算不上什么，但是总让人觉得很别扭

[zyxkad]

服务器理应保存了每个分片节点的数据，如果有新文件出现，必定会更新分片节点的文件列表。这与全量节点相同。不同之处只在于，全量节点可以共享列表，而分片节点不行

不是这样设计的，文件被划分为若干分片，节点也会随机持有若干分片，节点不会直接拥有文件。新文件会比根据平衡规则选择一个分片放入

你这样子搞还要单独给每个节点维护每次的文件差异

如果节点是每次上线的时候都会得到不一样的文件列表，那当我没说

如果不是，那就证明主服务器还是会为每个节点维护文件列表的

至于单独给每个节点维护差异我觉得并不是很难，每个节点的性质是相同的，只要你能给其中任意一个节点维护差异，必定也能给所有节点维护差异，并且非常简单

[bangbang93]

只要用好HTTP缓存，只有第一次请求会返回完整文件列表，后续请求只要文件没有变化都是304响应

我明白，我的问题就是，一旦有一个字符发生变化，这20秒又要重新请求一遍。虽然相比于10分钟的轮询间隔来说这20秒算不上什么，但是总让人觉得很别扭

如果文件没变化，那确实一个字符都不会变。只要有变化，那肯定是文件有变化，而且这20秒内，节点又不是不能工作

如果不是，那就证明主服务器还是会为每个节点维护文件列表的

不是，但是服务器也没有给每个节点维护文件列表

至于单独给每个节点维护差异我觉得并不是很难，每个节点的性质是相同的，只要你能给其中任意一个节点维护差异，必定也能给所有节点维护差异，并且非常简单

只有全量节点之间可以看做性质相同，而非全量节点各个之间文件分布都是不一样的 而且由于被动同步功能的存在，甚至不能保证一小时内的文件都是相同无变化的，你想如何维护这个差异表

[zyxkad]

如果不是，那就证明主服务器还是会为每个节点维护文件列表的

不是，但是服务器也没有给每个节点维护文件列表

如果没有给节点维护列表，如何保证两次请求到的文件都是相同的呢？节点并没有告诉主服务器自己都有哪些文件

[zyxkad]

只有全量节点之间可以看做性质相同，而非全量节点各个之间文件分布都是不一样的 而且由于被动同步功能的存在，甚至不能保证一小时内的文件都是相同无变化的，你想如何维护这个差异表

例如: 全量列表

{"new":["f1", "f2", "f3", "f4", "f5"]} // 2021-09 | latest

分片节点1:

{"new":["f1", "f2", "f3"]} // 2021-09 | latest

分片节点2: // 2021-09

{"new":["f4", "f5"]} // 2021-09 | latest

2021/09时新文件f6被检测到

全量列表

{"new":["f1", "f2", "f3", "f4", "f5", "f6"]} // 2021-09 | latest

分片节点1:

{"new":["f1", "f2", "f3"]} // 2021-09 | latest

分片节点2: // 2021-09

{"new":["f4", "f5", "f6"]} // 2021-09 | latest

2021/10时新文件f7, f8, f9被检测到

全量列表:

{"new":["f1", "f2", "f3", "f4", "f5", "f6"], "final":true} // 2021-09
{"new":["f7", "f8", "f9"]} // 2021-10 | latest

分片节点1:

{"new":["f1", "f2", "f3"], "final":true} // 2021-09
{"new":["f7", "f9"]} // 2021-10 | latest

分片节点2: // 2021-09

{"new":["f4", "f5", "f6"], "final":true} // 2021-09
{"new":["f8"]} // 2021-10 | latest

节点只用保存最后一个final分片的时间(如202109)然后向后请求202110, 或者如果节点长时间未启动, 则一直向后请求直到当月

如果节点是初始化状态，则应向服务器请求第一个文件分片的日期， 然后向后请求到当月

[bangbang93]

那么问题来了，删除的文件，你打算如何处理？ 一个9月出现的文件，可能10月就删了，但是在获取10月列表之前，并不知道10月要删这个文件，所以9月同步了也是白同步

[bangbang93]

如果不是，那就证明主服务器还是会为每个节点维护文件列表的

不是，但是服务器也没有给每个节点维护文件列表

如果没有给节点维护列表，如何保证两次请求到的文件都是相同的呢？节点并没有告诉主服务器自己都有哪些文件

你可以看做服务器上有一个负载均衡用的哈希算法，决定了每个文件该进入那个分片，分配给哪个节点，而没有一个明确的节点文件列表存储在服务器上的任何地方

[zyxkad]

那么问题来了，删除的文件，你打算如何处理？ 一个9月出现的文件，可能10月就删了，但是在获取10月列表之前，并不知道10月要删这个文件，所以9月同步了也是白同步

不是这样的, 节点应该先向后获取所有文件列表，处于"new"列表中的应该加入，处于"del"中的应该先判断是否存在与new列表中，如果存在即从中移除，不存在则删除现有文件（应该不会有哪个文件删了又重新回来的吧

[zyxkad]

如果没有给节点维护列表，如何保证两次请求到的文件都是相同的呢？节点并没有告诉主服务器自己都有哪些文件

你可以看做服务器上有一个负载均衡用的哈希算法，决定了每个文件该进入那个分片，分配给哪个节点，而没有一个明确的节点文件列表存储在服务器上的任何地方

主服务器会维护一个文件哈希值列表吗?还是说仅仅有一个缓存?

[zyxkad]

如果这样也不是没有办法，文件目录就是天然的文件列表，不同月份新增的文件放入不同目录应该是可行的

不过我不清楚主服务器是怎么判断文件被删除的（获取文件列表然后与现有文件列表判断?）如果为了节点实现方便，那么主服务器还可维护一个被删除的文件的列表

[bangbang93]

主要就是费大劲给每个节点维护一个增量列表并没有特别明显的收益，而实现有比现在复杂不少。随着节点增多，维护成本也会上升

[zyxkad]

好吧......