场景
最近在生产环境遇到了下面这样一个场景:
后台在字典表中存储了一些之前需要前后端共同维护的枚举值,并提供根据 type/id 获取字典的 API。所以在渲染列表的时候,有很多列表的字段直接就是字典的 id,而没有经过后台的数据拼装。
起初,吾辈解决问题的流程如下
- 确定字典字段,添加转换后的对象类型接口
- 将对象列表进行转换得到其中字典字段的所有值
- 对字典 id 列表进行去重
- 根据 id 列表从后台获取到所有的字典数据
- 将获得的字典数据转换为 id => 字典 的 Map
- 遍历最初的列表,对里面指定的字典字段进行转换
可以看到,上面的步骤虽然不麻烦,但却十分繁琐,需要定义额外的类型不说,还很容易发生错误。
思路
- 使用 异步批处理 + LRU 缓存 优化性能
- 支持异步 formatter 获得更好的使用体验
实现异步批处理
参考实现:
import { wait } from '../async/wait' /** * 将多个并发异步调用合并为一次批处理 * @param handle 批处理的函数 * @param ms 等待的时长(时间越长则可能合并的调用越多,否则将使用微任务只合并一次同步执行的所有调用) */ export function batch<P extends any[], R extends any>( handle: (list: P[]) => Promise<Map<P, R | Error, ms: number = 0, ): (...args: P) => Promise<R> { //参数 => 结果 映射 const resultCache = new Map<string, R | Error>() //参数 => 次数的映射 const paramCache = new Map<string, number>() //当前是否被锁定 let lock = false return async function (...args: P) { const key = JSON.stringify(args) paramCache.set(key, (paramCache.get(key) || 0) + 1) await Promise.all([wait(() => resultCache.has(key) || !lock), wait(ms)]) if (!resultCache.has(key)) { try { lock = true Array.from( await handle(Array.from(paramCache.keys()).map((v) => JSON.parse(v))), ).forEach(([k, v]) => { resultCache.set(JSON.stringify(k), v) }) } finally { lock = false } } const value = resultCache.get(key)! paramCache.set(key, paramCache.get(key)! - 1) if ((paramCache.get(key) || 0) <= 0) { paramCache.delete(key) resultCache.delete(key) } if (value instanceof Error) { resultCache.delete(key) throw value } return value as R } }
实现批处理的基本思路如下
1.使用 Map paramCache 缓存传入的 参数 => 剩余调用次数(该参数还需要查询几次结果)
2.使用 Map resultCache 缓存 参数 => 结果
3.使用 lock 标识当前是否有函数正在执行
4.满足以下条件需要等待
Map 中不包含结果
目前有其它调用在执行
还未满最小等待时长(收集调用的最小时间片段)
5.使用 lock 标识正在执行
6.判断是否已经存在结果
如果不存在则执行批处理处理当前所有的参数
7.从缓存 Map 中获取结果
8.将 paramCache 中对应参数的 剩余调用次数 -1
9.判断是否还需要保留该缓存(该参数对应的剩余调用次数为 0)
不需要则删除
10.判断缓存的结果是否是 Error
是的话则 throw 抛出错误
LRU 缓存
参考: Wiki 缓存算法, 实现 MemoryCache
问:这里为什么使用缓存?
答:这里的字典接口在大概率上是幂等的,所以可以使用缓存提高性能
问:那么缓存策略为什么要选择 LRU 呢?
答:毫无疑问 FIFO 是不合理的
问:那为什么不选择 LFU 算法呢?它似乎能保留访问最频繁的资源
答:因为字典表并非完全幂等,吾辈希望避免一种可能–访问最多的字典一直没有删除,而它在数据库已经被更新了。
大致实现思路如下
1.使用一个 Map 记录 缓存 key => 最后访问时间
2.每次获取缓存时更新最后访问时间
3.添加新的缓存时检查缓存数量
如果超过最大数量,则删除最后访问时间距离现在最长的一个缓存
4.添加新的缓存
Pass: 不要吐槽性能很差啦,这个场景下不会缓存特别多的元素啦,最多也就不到 1000 个吧
结合高阶函数
现在,我们可以结合这两种方式了,同时使用 onceOfSameParam/batch 两个高阶函数来优化 根据 id 获取字典信息 的 API 了。
const getById = onceOfSameParam( batch<[number], Dict>(async (idList) => { if (idList.length === 0) { return new Map() } // 一次批量处理多个 id const list = await this.getByIdList(uniqueBy(idList.flat())) return arrayToMap( list, (dict) => [dict.id], (dict) => dict, ) }, 100), )
支持异步 formatter
原本想要支持 ListTable 的异步 formatter
函数,但后来想想,如果 slot
里也包含字典 id 呢?那是否 slot
也要支持异步呢?这可是个比较棘手的问题,所以还是不支持好了。
最终,吾辈在组件与 API 之间添加了 *Service 中间层负责处理数据转换。
以上就是详解JavaScript 中的批处理和缓存的详细内容,更多关于JavaScript 中的批处理和缓存的资料请关注其它相关文章!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]