[RFC] Cache API

[shigma]

鸽了挺久没做，现在差不多是时候了。

koishi-core 内部使用了 lru-cache 作为缓存以提高性能。然而这种实现方式存在一些问题：

• 不能显式地读取缓存中的数据，可能造成数据同步不一致的问题
• 能进行缓存的不仅有用户和频道数据，还抽象出更一般的形式供更多插件使用

为此，我计划设计一套 Cache API，并于之后的版本实装。

Cache 接口

Cache API 完全基于 table-key-value 架构设计，因此接口相对简单：

ctx.cache.get(table, key)
ctx.cache.set(table, key, value)

但是用户数据可能基于不同的键值查询，怎么办呢？我们需要把用户表按照键值拆分为多个子表：

const id = ctx.cache.get('onebot', '123456789')  // 获取内部用户 ID
const user = ctx.cache.get('user', id)           // 获取用户数据

定义缓存表

插件可以定义缓存表来自定义访问 Cache API。

// 比如搜图插件想要缓存 saucenao 的搜索结果
ctx.cache.extend('saucenao', options)

const value = ctx.cache.get('saucenao', 'https://image-url')

实现形式

为了确保向下兼容性，koishi-core 仍然会自带一个 lru-cache 作为内部的实现。同时，也可以通过插件定义其他的 Cache API 实现。插件的好处在于可以使用专业数据库提升存储能力，同时支持持续存储（当应用重载时，内存中的缓存会被清除，但是本地数据库中的数据并不会）。目前计划率先支持的实现是：

• koishi-plugin-level

[purerosefallen]

Something like koishi-plugin-redis?

[shigma]

Sure, but I currently have no plan to officially support redis. The reason is as follows.

We discussed about redis support before. According to my knowledge, redis can only be connected through network. If one runs Koishi and its database in separate servers, redis may help optimizing performance. But if one doesn't, an in-memory cache will be much better.

And currently in fact, many users of Koishi runs Koishi together with its database. So it may not be of great need to implement such plugin. But I will be grad if you can write one after cache API is implemented.

[purerosefallen]

Redis could run on the same server with Koishi itself. In addition, it would be much better if cached data could survive between restarts. In addition, small-memory servers could also run Koishi by moving Redis instance away from this server.