后端缓存抽象【免费下载链接】dataloaderDataLoader is a generic utility to be used as part of your applications data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching.项目地址https://gitcode.com/gh_mirrors/da/dataloader点击查看免费下载导读Knex.js 是 Node.js 生态中流行的 SQL 查询构建器统一封装了 PostgreSQL、MySQL、MariaDB 等数据库客户端。本文以仓库中的 examples/Knex.md 为骨架讲解如何用 DataLoader 的批量加载batching能力与 Knex 的whereIn查询结合在不手写任何 SQL 的前提下将同一事件循环内的多条按 ID 查询合并为单次数据库请求同时结合 src/index.js 的源码实现与 src/tests/dataloader.test.js 的测试用例深入剖析批量函数顺序约束、缓存行为与调度机制帮助你构建一套可复用的 SQL 数据加载层。为什么用 Knex 实现 DataLoader 批量加载DataLoader 的定位为后端提供一致的加载 APIDataLoader 是一个通用的数据加载工具用于在应用的数据获取层提供一个简化的、一致的 API 来访问各类后端数据源数据库、Web 服务等其核心手段是批量化batching与缓存caching。正如 README.md 所述它最初源自 Facebook 2010 年开发的 Loader API并成为其 GraphQL 服务实现的基础。DataLoader 天然适配键值存储后端一批 key 对应一批 value。而 SQL 数据库并非键值存储但 SQL 本身提供了天然的批量机制——WHERE ... IN (...)子句。这正是 examples/SQL.md 与 examples/Knex.md 两个示例的核心思路当查询保持简单、仅按 ID 取整行数据时DataLoader 同样适用。Knex 相比手写 SQL 的优势examples/Knex.md 明确指出与 SQL 示例相同你同样可以用 where in 子句按 ID 列表批量取回多条记录唯一区别是不用手写任何 SQL 代码。Knex 将查询构建为链式调用并抹平了不同数据库方言的差异对比维度手写 SQLexamples/SQL.mdKnexexamples/Knex.md查询写法SELECT * FROM users WHERE id IN $ids字符串db.table(users).whereIn(id, ids).select()链式 API参数绑定手动传参对象{ $ids: ids }whereIn自动处理参数化数据库差异方言差异需自行处理如$ids占位符统一 API支持 PostgreSQL、MySQL、MariaDB 等回调风格db.all(sql, params, callback)返回 Promise可直接链式.then()核心示例用whereIn构建 SQL 批量加载器完整代码与逐段解读以下是 examples/Knex.md 的完整示例const DataLoader require(dataloader); const db require(./db); // an instance of Knex client // The list of data loaders const loaders { user: new DataLoader(ids db .table(users) .whereIn(id, ids) .select() .then(rows ids.map(id rows.find(x x.id id))), ), story: new DataLoader(ids db .table(stories) .whereIn(id, ids) .select() .then(rows ids.map(id rows.find(x x.id id))), ), storiesByUserId: new DataLoader(ids db .table(stories) .whereIn(author_id, ids) .select() .then(rows ids.map(id rows.filter(x x.author_id id))), ), }; // Usage const [user, stories] await Promise.all([ loaders.user.load(1234), loaders.storiesByUserId.load(1234), ]);逐段解读const db require(./db)db是已配置好的 Knex 客户端实例如require(knex)({ client: pg, connection: ... })示例假设它位于项目./db模块中。user加载器按users表主键id批量取整行。whereIn(id, ids)会生成WHERE id IN (?, ?, ...)的参数化查询。story加载器模式与user完全相同针对stories表。storiesByUserId加载器这是按外键author_id批量查询的一对多场景rows.filter(...)返回数组而不是单行——即一个作者 ID 可能对应多篇故事。用法部分在同一事件循环帧内并发调用loaders.user.load(1234)与loaders.storiesByUserId.load(1234)DataLoader 会将这两个调用分别合入各自的批量函数最终只发出 2 次数据库请求。结果重排批量函数的顺序约束注意示例中.then(rows ids.map(id rows.find(x x.id id)))这一步——它是整个 SQL 集成中最关键的一步。原因在于 src/index.js 中的硬性校验批量函数返回的 values 数组长度必须与传入的 keys 数组长度完全一致values 的每个索引必须对应 keys 的相同索引。而 SQL 的WHERE IN查询并不保证返回顺序与传入 ID 顺序一致数据库可能按索引、存储顺序返回且可能缺失某些 ID 的行。因此必须用ids.map(id rows.find(x x.id id))将数据库返回的行重新映射到请求 ID 的顺序上。若某个 ID 无对应行rows.find(...)返回undefined——此时更严谨的做法是像 examples/SQL.md 那样补一个new Error(\Row not found: ${id})兜底让调用方通过.catch 感知缺失数据。src/tests/dataloader.test.js 中大量用例也验证了这种 重排 补齐 模式例如keys.map(key (key bad ? new Error(Bad Key) : key))之类的写法与 SQL 示例的rows.find(...) || new Error(...)属于同一思路。批量调度原理为什么同帧的 load 会被合并事件循环帧内的合批DataLoader 的默认行为是单个事件循环帧single frame of execution内所有.load()调用被合并为一次批量函数调用。README 中明确指出这与 Facebook 2010 年原始 PHP 实现的调度行为一致。src/index.js 中的enqueuePostPromiseJob揭示了其底层机制Node.js 环境中通过Promise.resolve().then(() process.nextTick(fn))将一个后置任务排到 PromiseJobs 微任务队列之后、下一轮宏任务之前浏览器环境则回退到setImmediate或setTimeout存在一定性能代价。getCurrentBatchsrc/index.js负责复用尚未派发的当前批若已有未派发批且未达到maxBatchSize上限则直接追加 key。测试 src/tests/dataloader.test.jsbatches loads occuring within promises专门验证了这一特性即使load(B)、load(C)、load(D)发生在多层 Promise.then()嵌套之中最终批量函数也只被调用一次且 keys 为[A, B, C, D]。这说明依赖加载loader 内部再调用 loader也能被正确合批非常适合 GraphQL 等嵌套解析场景。批量函数的两大约束根据 README.md 的 Batch Function 一节与源码校验逻辑批量函数必须满足长度一致返回数组长度 传入 keys 长度索引对齐返回数组第 i 项对应 keys 第 i 项。若后端返回顺序不同如数据库按自身最优顺序返回或缺失某 key视为该 key 无值批量函数必须自行重排并用null或new Error(...)补齐。Knex 示例中的rows.find(...)/rows.filter(...)正是为了满足这两条约束而存在。常见进阶配置与缓存行为选项参数一览在 Knex 示例基础上可通过构造函数的第二参数控制批量与缓存行为。下表整理自 README.md 的 API 表格实现细节可在 src/index.js 的getValid*系列函数中确认选项键类型默认值说明batchBooleantrue设为false禁用批量化等效于maxBatchSize: 1maxBatchSizeNumberInfinity限制单次传入批量函数的 key 数量设为1可禁用批量化batchScheduleFnFunctionenqueuePostPromiseJob自定义批量派发调度函数如延迟 100ms 收集请求cacheBooleantrue设为false禁用记忆化缓存等效于cacheMap: nullcacheKeyFnFunctionkey key由加载 key 生成缓存 key对象作为 key 时可自定义等价判定cacheMapObjectnew Map()自定义缓存实例需实现get/set/delete/clear设为null禁用缓存nameStringnull实例名称供 APM 工具使用注意禁用缓存cache: false时批量函数收到的 keys可能包含重复项——每次.load()都会产生一个独立的新 Promise 并对应一个 key 实例批量函数需为每个重复 key 都返回值。缓存与批量协同缓存命中不阻断合批.load()命中缓存时该 key 不会出现在批量函数 keys 中但其返回的 Promise 会等待当前批次完成后再一起 resolve源码中通过batch.cacheHits队列实现见 src/index.js。这使得后续依赖加载仍能在同一帧内合批。批量失败不缓存若整个批次派发失败批量函数抛错或返回 rejected Promise该批所有 key 会被clear不会污染缓存src/index.js 的failedDispatch但批量函数为单个 key 返回Error实例时该 Error 会被缓存避免反复加载同样的错误。写后失效同请求内发生 UPDATE 等变更后需调用loader.clear(key)使缓存失效若涉及多个未知 key 的变更直接loader.clearAll()。load、clear、clearAll、prime等方法的具体实现在 src/index.js。每请求新建实例DataLoader 的缓存是无限增长的 Map本质是单请求级记忆化缓存不能替代 Redis/Memcache 等共享缓存在 Web 服务中应为每个请求新建实例按认证 token 区分避免不同用户串读缓存。典型写法是把多个 loader 放进一个对象随请求传递function createLoaders(authToken) { return { users: new DataLoader(ids genUsers(authToken, ids)), stories: new DataLoader(keys genStories(authToken, keys)), }; } // 处理每个 HTTP 请求时 const loaders createLoaders(request.query.authToken); const user await loaders.users.load(4);在 GraphQL 服务中的落地DataLoader 与 GraphQL 是经典组合GraphQL 字段是独立的解析函数若不引入批量/缓存机制一个嵌套查询可能触发大量重复数据库请求。README 中给出的示例请求me、bestFriend、friends嵌套朴素实现最多需要13 次数据库请求而接入 DataLoader 后最多4 次且命中缓存时更少。Knex 加载器可直接在字段解析器中使用const UserType new GraphQLObjectType({ name: User, fields: () ({ name: { type: GraphQLString }, bestFriend: { type: UserType, resolve: user userLoader.load(user.bestFriendID), }, friends: { args: { first: { type: GraphQLInt } }, type: new GraphQLList(UserType), resolve: async (user, { first }) { const rows await queryLoader.load([ SELECT toID FROM friends WHERE fromID? LIMIT ?, user.id, first, ]); return rows.map(row userLoader.load(row.toID)); }, }, }), });注意friends解析器中返回的是rows.map(row userLoader.load(row.toID))——一个 Promise 数组它们会在同一帧内被userLoader合批为一次WHERE id IN (...)查询。这正是 examples/Knex.md 中storiesByUserId式一对多加载器与user式主键加载器协同的典型场景。更多后端示例与延伸阅读SQLiteexamples/SQL.md 展示了手写SELECT * FROM users WHERE id IN $ids的等价实现其中rows.find(row row.id id) || new Error(\Row not found: ${id}) 是结果重排与缺失兜底的完整范本可作为理解 Knex 版本内部机制的对照。Redisexamples/Redis.md 展示了键值存储场景利用MGET命令天然按 key 顺序返回结果的特性批量函数写法更为直接。其他后端仓库 examples 目录还包含 CouchDB、GoogleDatastore、RethinkDB 等示例可对比不同数据源的批量加载模式。源码与测试核心实现见 src/index.js类型定义见 src/index.d.ts行为验证见 src/tests/dataloader.test.js。小结将 DataLoader 与 Knex.js 结合是通用批量加载工具 SQL 查询构建器的典型集成方案DataLoader 负责在同一事件循环帧内合批所有.load()调用并按序对齐结果Knex 负责把 ID 数组转化为参数化的WHERE IN查询并抹平数据库差异。实践中需始终牢记两条铁律——返回数组与 keys 等长且索引对齐用ids.map(...)重排、按请求维度管理缓存生命周期每请求新建 loader变更后及时clear。掌握这套模式后你可以轻松将其推广到 GraphQL 解析器、REST 聚合接口乃至任意需要按主键/外键批量取数的后端场景。赞分享后端缓存抽象【免费下载链接】dataloaderDataLoader is a generic utility to be used as part of your applications data fetching layer to provide a consistent API over various backends and reduce requests to those backends via batching and caching.项目地址https://gitcode.com/gh_mirrors/da/dataloader点击查看免费下载相关推荐DataLoader 与 Redis 集成实战基于 MGET 的批量加载与缓存策略DataLoader 与 Redis 集成实战基于 MGET 的批量加载与缓存策略 DataLoader 是一个通用的数据加载工具通过批处理batchin后端缓存抽象inngest 中的 GraphQL DataLoader 实战基于 graph-gophers/dataloader 的批量加载与缓存机制解析inngest 中的 GraphQL DataLoader 实战基于 graph gophers/dataloader 的批量加载与缓存机制解析 导读 本文以后端任务调度工作流自动化微服务Graphene 数据加载优化使用 DataLoader 实现 GraphQL 批量加载与缓存Graphene 数据加载优化使用 DataLoader 实现 GraphQL 批量加载与缓存 导读 在 GraphQL 服务中每个字段的 resolver后端API设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考