Cache 相关变更

[NeverBehave]

背景

当前的缓存设定，由于基于中间件的想法，置入了ctx传递。这其实对于路由维护者而言并不是一个很好的决定。由于不能直接引入，他们不得不将在各处传递这个对象。同时也不方便解耦，让路由可以在更多场景发挥自己的作用。

另外一个比较值得一提的问题是当前RSShub在无缓存时路由的行为：会触发多次获取操作，给对方网站带来不必要的流量和压力。部分路由作者同时可能也需要自行控制并发设定，目前也没有较好的解决方案

动议

类似于修订后的时间处理，我们准备

1. 将缓存相关内容与上下文分离，单独导入使用

2. 自动限定作用域，避免路由之间处理有冲突。在对应的路由引入缓存时，我们将会自动附加其定义的路由名字作为其命名空间

3. 我们会划出一块区域作为路由锁，限定并发。如果有多个请求同时进行，我们将会等待当前执行结果进入缓存后返回内容。其余请求将会弹回503状态码，客户端遇到这类错误在后续可进行尝试重新获取

4. 这里我们发现一个社区比较成熟的包，可用于替代当前较为缓存设定，并提供更好地控制/性能： https://github.com/BryanDonovan/node-cache-manager#readme

影响范围

➜  lib git:(master) grep -r 'ctx.cache' | wc -l
1315

Q&A

为什么不缓存请求结果（原始HTML）？

因为对应的路由产生多个请求的时候，其最终结果会被缓存一段时间（全文内容缓存更长时间）。结果与网页内容（HTML）本身是对应的关系 -- 一方失效另一方也无效化。如果有路由需要共享原始内容，请给出例子作为参考

为什么并发不限制同网站（域名）？尤其是在单路由支持用户提供无限制参数的时候（比如快递单号，用户id）

这个问题其实和分散实例相关。如果我们限制同时并发对网站的请求，由于RSSHub本身还是可以自行部署，对于对方网站的唯一区别就是多个IP和单个IP请求。再没有实际数据和反馈的情况下我们想暂缓相关考虑，此处欢迎数据点

但是我们会提供工具类，方便路由作者需要控制并发的情况，作为官方的建议解决方案。我们同时考虑在方法tryGet的基础上增加可选参数方便使用

结语

本讨论是想邀请路由贡献者就当前路由编写体验提供建议，发现考虑不周之处

分支 cache-improvement 将会实施相关变更

[NeverBehave]

目前实现了第一步，针对路由路径的并发限制

[fengkx]

3. 如果有多个请求同时进行，我们将会等待当前执行结果进入缓存后返回内容。其余请求将会弹回503状态码，客户端遇到这类错误在后续可进行尝试重新获取

或许可以 cache 请求promise，进行中的请求则返回同一个 promise 对象。

Demo： https://runkit.com/fengkx/request-cache-throttle

分支 cache-improvement 将会实施相关变更

这个分支在哪里，有推到GitHub吗？ 🤔️