refactor(core): unified memory cache

[Rongronggg9]

该 PR 相关 Issue / Involved issue

Close #

完整路由地址 / Example for the proposed route(s)

NOROUTE

新 RSS 检查列表 / New RSS Script Checklist

• 新的路由 New Route
  • 跟随 v2 路由规范 Follows v2 Script Standard
• 文档说明 Documentation
  • 中文文档 CN
  • 英文文档 EN
• 全文获取 fulltext
  • 使用缓存 Use Cache
• 反爬/频率限制 anti-bot or rate limit?
  • 如果有, 是否有对应的措施? If yes, do your code reflect this sign?
• 日期和时间 date and time
  • 可以解析 Parsed
  • 时区调整 Correct TimeZone
• 添加了新的包 New package added
• Puppeteer

说明 / Note

After bumping lru-cache to 7.x, we no longer need to maintain two LRU caches in the memory.

[Rongronggg9]

2ed9fd5 added a config MEMORY_MAX...
In fact, by just deleting the max parameter, the cache size can be set to infinite just like before.
However, if the cache size is limited, and the route cache and content cache share the same cache backend, the content cache may easily flush all the route cache away.

So @TonyRL, what is your opinion about that? I've come out four solutions:

1. Make the cache size unlimited again. (just like before)
2. Make the cache size unlimited again, meanwhile enable ttlAutopurge. (making memory cache behave nearly the same as Redis cache, but may significantly degrade performance)
3. Preserve pageCache used only for route cache, and making any route cache, no matter need or need not refreshing, go into memoryCache.
4. Increase the default value of MEMORY_MAX to a high enough number.
5. Close this PR and change nothing. (Hmmm, why not just choose 3 to prevent potential cache key collision?)

[TonyRL]

Option 1:
(node:77022) [LRU_CACHE_UNBOUNDED] UnboundedCacheWarning: TTL caching without ttlAutopurge, max, or maxSize can result in unbounded memory consumption.
With ENABLE_CLUSTER enabled + memory caching option, RSSHub can be OOM-killed easily on low-cost hosting plaform.

Option 2:
No warnings but may significantly degrade performance as said in lru-cache docs.

Option 4:
Memory are pre-allocated in lru-cache v7 instead of growing in v6. I would prefer having a low value and setting it to a high value manually if necessary.

Option 3+5:

Preserve pageCache used only for route cache, and making any route cache, no matter need or need not refreshing, go into memoryCache.

I think that's somehow what RSSHub is doing right now. One enforced cache for final RSS output, another optional cache for content or other things but doing it in two individual caches instead one.
Also, it has a cache keys of koa-redis-cache:md5(ctx.request.path) which I guess is quite less like to have a collision.

[Rongronggg9]

I think that's somehow what RSSHub is doing right now.

No, setting content cache with { refresh: false } makes it go into pageCache, otherwise routeCache. This behavior significantly brings two disadvantages:

1. Setting a lot of cache entries with { refresh: false } may flush all the route cache away. Though currently no routes were doing this, there do be necessary to make those routes with tons of formatting settings cache their initial entry with { maxAge: config.cache.routeExpire, refresh: false } to avoid being anti-crawled as already discussed in feat(route)(telegram/channel): major rewrite #9213 (comment). Once this PR is merged, it will start doing this.
2. When getting or setting content cache, an identical value of refresh is strictly needed. This is a really weird behavior because setting a cache always "refreshes" something. No one will think of this unless they have already been told or carefully read the code, however, the documents never mention this point. The best example is that both you (@TonyRL) and I, never noticed that I had forgotten to pass the refresh parameter to cache.set in the enhanced cache.tryGet. (I apologize for my negligence...)

So since other solutions are not acceptable, I will implement Solution 3.

[TonyRL]

I would prefer 3292af2 to further shrink memory usage(2 * MEMORY_MAX vs 1)
I also didn't notice lru-cache can do get(key, { updateAgeOnGet, allowStale } = {}) => value in v7 until this PR comes in.

[Rongronggg9]

I would prefer 3292af2 to further shrink memory usage(2 * MEMORY_MAX vs 1)

I see. Though 2 * MEMORY_MAX is exactly current behavior, I will follow your advice and reset this PR to 3292af2.

off-topic content

I also didn't notice lru-cache can do get(key, { updateAgeOnGet, allowStale } = {}) => value in v7 until this PR comes in.

I've noticed it before the migration to v7. At that time I'd planned to create a migration PR and implement a unified memory cache, but you finished the migration soon. You are absolutely a diligent and nice maintainer.