函数调用没有任何缓存策略

[moonrailgun]

目前看上去函数服务尚无任何缓存策略，每次请求都要访问数据库。

在可见的未来有无增加缓存机制的打算？以减少对数据库的负担

https://github.com/labring/laf/blob/11b5801dff2081015861926f305a966c59208225/packages/app-service/src/handler/invoke-func.ts#L24-L36

[maslow]

是的，加缓存是合理的，缓存会带来一些复杂度，就先简单化处理了。

有没有好的想法？

[moonrailgun]

是的，加缓存是合理的，缓存会带来一些复杂度，就先简单化处理了。

有没有好的想法？

• 首先增加缓存机制，优先从redis/memory 中获取某个函数方法下的funcData, 如果没有则fallback到mongodb中获取
• 增加refresh接口用于清理缓存
  • 发布函数时后端自动触发refresh接口
  • 用户可以在前端手动触发刷新缓存接口
• debug函数不走缓存

[maslow]

OK 应该没问题，需要做一些 trade off:

1. laf 整体要期望尽量保持轻量，非必要不引入更多中间件，所以 redis 的引入带来的成本会考虑；
2. laf app 的最小内存占用，也是优化的一个重点，使用 memory cache 需评估 100 个函数缓存到 memory 带来的内存增加；
3. refresh 的逻辑我觉得没问题，可同时适用于 db policy 的缓存（db policy cache 当前就是 memory cached）

我当前阶段倾向于 memory cache，比较简单，除非他的 memory 占用会增加很多（>10%）

[skyoct]

不建议所有函数都放入缓存中，应该有一个固定长度队列（可配置），每次请求来的时候先去队列请求，如果队列没有就把从数据库读取函数然后放入队列中，当队列满了后可以根据LRU等算法把使用频次低的函数淘汰出去。

[maslow]

不建议所有函数都放入缓存中，应该有一个固定长度队列（可配置），每次请求来的时候先去队列请求，如果队列没有就把从数据库读取函数然后放入队列中，当队列满了后可以根据LRU等算法把使用频次低的函数淘汰出去。

嗯，这样最好， 但是增加了这个事情的复杂度，当前优先级也并不高。

我建议是， 可以先缓存所有（不会带来过多内存占用的情况下），LRU队列可以做为 下一阶段的优化手段再上。