多请求并发前端缓存方案

一、背景

  1. 项目中原本展示的导航距离是直线导航距离,因不符合实际故迭代为调用“电单车导航服务”;
  2. 地图侧提供的“电单车导航接口”只能单个调用,即一个接口只能获取 1 组(2 个坐标之间)的导航信息,而不能一次获取多组坐标的导航信息;

二、风险

同一门店在同一时刻必然存在大量订单和骑手,如果要批量获取导航信息,必定要同时并发大量请求,此时带来的问题有:

  1. 接口串行通信导致延迟大(可排除,线上采用 http2);
  2. 业务后端需要接受大并发考验,可能因为本需求而被迫扩张;
  3. 对于没有移动的坐标组重复调用导致经费的浪费(集团内的服务也要收钱);

三、方案

前端

  1. 最小请求原则,只请求运营人员观察内的订单或骑手对应的导航信息;
  2. 最大复用原则,未变更的坐标组,直接复用上次的结果,而不是重新请求;

后端

  1. 后端对二方服务进行封装,封装成批量调用接口暴露给前端;
  2. 响应 list 每一个 item 提供唯一标识符 serialNo,响应 listitem 同样带这个标识符,前端根据该标识符进行区分。

四、方案细节

页面状态流图

以下是页面的数据状态流图,红色部分是本次修改的内容:


数据状态流图

缓存方案流程图

image.png

编码细节

请求打包函数

因为后端对批量接口的长度进行了限制,限制为最多请求 50 组,所以前端这里需要把批量的请求按照 50 一组进行分割,请求完毕后再打包。

/**
 * 打包请求
 */
function zipFetch<ParamsType, FetchRes>(
    params: ParamsType,
    chunkFn: (params: ParamsType) => ParamsType[],
    fetchFn: (params: ParamsType) => Promise<FetchRes>,
) {
    const paramsArr = chunkFn(params);
    // HACK: Promise.allSettled
    return Promise.all(paramsArr.map((params) => promiseAllSettledWrapper(fetchFn)(params))).then((res) => {
        // 有一个 promise 成功则认为本次请求成功
        const isSuccess = res.some((promise) => promise.status === PromiseStatus.FULFILLED);

        if (!isSuccess) {
            // 如果失败,则把第一个错误抛出
            const errorRes = (res[0] as PromiseRejectedResult)?.reason;
            const msg = errorRes?.message;
            throw new Error(msg);
        }

        // 请求成功,把所有的 resolved 的值合并到一起返回
        return res.reduce((final, cur) => {
            if (cur.status === PromiseStatus.FULFILLED) {
                const { value } = (cur as PromiseFulfilledResult<FetchRes>);
                return {
                    ...final,
                    ...value,
                };
            }
            return final;
        }, {} as FetchRes);
    });
}

/*
 * 可以直接在业务代码内使用的请求函数
 */
function fetchNavData(params: FetchNavDataQuery) {
    return zipFetch<FetchNavDataQuery, NavigateData>(
        params,
        (params) => {
            const { coordinates } = params;
            const chunkedParams = chunk(coordinates, 50);

            return chunkedParams.map((chunk) => ({
                coordinates: chunk,
            }));
        },
        request,
    );
}
请求生成器

这里用函数实现主要为了实现每次调用时生成一个干净的闭包用来存放 query,至于为什么分别实现 pushQuery & fetch 则是为了关注点分离。

/**
 * 请求生成器
 */
function fetchCreator(
    succeedCallback?: SucceedCallback,
    failedCallback?: FailedCallback,
) {
    const query: CoordinateItem[] = [];

    const result = {
        pushQuery: (params: PushQueryParams) => {
            const { srcLocation, destLocation, serialId } = params;

            if (srcLocation && destLocation) {
                query.push({
                    serialId,
                    originCoordinate: srcLocation.join(','),
                    destinationCoordinate: destLocation.join(','),
                });
            }
        },
        fetch: () => {
            if (query.length) {
                return fetchNavData({ coordinates: query }).then((res) => {
                    succeedCallback?.(res);
                    return res;
                }).catch((e: Error) => {
                    failedCallback?.(e);
                    return {} as NavigateData;
                });
            }

            return Promise.resolve({} as NavigateData).then((res) => succeedCallback?.(res));
        },
    };

    return result;
}
带有缓存的请求生成器

该函数返回的 pushQuery 会对批量传入的坐标组进行检查,看是否有坐标组已经被缓存,如果已经有缓存,那么使用缓存内容,否则将坐标组放到 query 中进行请求,等待请求回来后,将请求内容和缓存内容 merge 到一起进行返回。

/**
 * 带有缓存的请求生成器
 */
export function fetchWithCacheCreator(
    cache: CacheManager<NavRoute>,
    succeedCallback?: SucceedCallback,
    failedCallback?: FailedCallback,
) {
    const { pushQuery, fetch } = fetchGenerator(undefined, failedCallback);

    let curRequestCache = Object.create(null);
    const pushCurRequestCache = (key: string, data: NavRoute) => {
        curRequestCache[key] = data;
    };
    const clearCurRequestCache = () => {
        curRequestCache = Object.create(null);
    };

    return {
        pushQuery: (params: PushQueryParams) => {
            const { serialId } = params;
            const cacheItem = cache.getCache(serialId);

            if (cacheItem) {
                pushCurRequestCache(serialId, cacheItem);
            } else {
                pushQuery(params);
            }
        },
        fetch: () => fetch().then((res) => {
            const mergeCachedData = { ...curRequestCache, ...res };
            cache.setCache(mergeCachedData);

            succeedCallback?.(mergeCachedData);
            return mergeCachedData;
        }).finally(clearCurRequestCache),
    };
}

五、改进点

骑手到门店 & 骑手到客户之前的导航信息没有使用缓存,其实这里前端也是可以缓存的,通过修改 CacheManager 可以判断骑手如果活动距离过短可以认为其没有移动,然后返回缓存内容。

interface ICacheManager<CacheItem> {
    /**
     * 设置缓存
     */
    setCache: (data: Record<string, CacheItem>) => void
    /**
     * 取缓存
     */
    getCache: (key: string) => CacheItem | undefined
    /**
     * 删除某个缓存
     */
    delCache: (key: string) => void
    /**
     * 清理缓存
     */
    clearCache: () => void

    /**
     * 新增
     * 判断骑手是否没有移动
     */
    isNotRemoved: () => boolean
}

export class CacheManager<T> implements ICacheManager<T> {
    private cacheMap: Record<string, T>

    constructor() {
        this.cacheMap = Object.create(null);
    }

    setCache(data: Record<string, T>) {
        forEach(data, (item, key) => {
            this.cacheMap[key] = item;
        });
    }

    getCache(key: string) {
        if (this.isNotRemoved()) {
            return this.cacheMap[key];
        }

        this.delCache(key);
        return undefined;
    }

    delCache(key: string) {
        delete this.cacheMap[key];
    }

    clearCache() {
        this.cacheMap = Object.create(null);
    }

    isNotRemoved() {
        // 实现判断逻辑
        return true;
    }
}
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,968评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,601评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,220评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,416评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,425评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,144评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,432评论 3 401
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,088评论 0 261
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,586评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,028评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,137评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,783评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,343评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,333评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,559评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,595评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,901评论 2 345

推荐阅读更多精彩内容