App 数据缓存方案

    技术2022-07-31  88

    策略1:规则缓存(单纯App本地缓存)

    App根据接口数据特性,本地规定缓存以及更新数据策略(例如:登录后更新数据)。即特定场景下指定特定数据源(local,remote)。有些数据不会经常变更,例如用户权限,可以规定在特殊场景下触发Request获取remote数据,其余场景下从本地缓存获取。

    减少网络访问次数,数据实时性达不到。

    策略2:时效缓存(单纯App本地缓存)

    App(或者服务端)根据接口数据特性,规定特定接口缓存时效。即根据不同接口,设置Cache-Control的不同时长。同时根据网络情况,定义断网和联网场景下的缓存时效。

    接口1:.header("Cache-Control", "max-age=" + 1000)

    接口2:.header("Cache-Control", "max-age=" + 2000)

    接口2:.header("Cache-Control", "max-age=" + 3000)

    缓存方式:Cache

    减少网络访问次数,数据实时性达不到。

    策略3:时间戳缓存(参数形式,完全自定义)

    App本地缓存接口数据,同时缓存最新接口访问时间戳

    (1)每次访问,上次request时间戳传参给后台(协议定义第一次访问参数形式,例如:“-1”)

    (2)由后台判断该时间戳开始,到当前时间点截止,该接口数据有无变更,有:返回data,同时返回本次请求响应的时间戳;无:返回data = null(或协议其他形式)。

    (3)App判断响应data是否为空数据(或者定义其他形式的协议),是,获取本地缓存;否,获取响应data,同时更新本地缓存以及本次接口访问时间戳

    说明:

    (1)App负责缓存接口数据,最新的接口访问时间戳。

    (2)后台负责记录接口数据最新的变更时间戳updateTime,负责对比终端请求参数中,上一次请求时间戳oldRequestTime 和 updateTime:

    if(oldRequestTime > updateTime) {

        return null; } else {     return data; }

    (3)本策略,App需自定义并管理Cache。

    策略4:Last-Modified-Date(Headers形式,OkHttp缓存策略)

    App本地缓存接口数据,同时缓存remote接口数据最后一次变更时间戳。

    (1)App第一次请求时,服务器返回接口数据最后一次变更时间点(Headers):

    Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT

    (2)App二次请求时,头部加上如下header:

    If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT

    (3)服务器判断在If-Modified-Since ~ 当前,资源是否被二次修改,否:服务器返回code = 304告知客户端直接复用本地缓存(OkHttp内置缓存拦截器已实现相关策略);是:服务器正常返回data,同时返回Last-Modified

    说明:

    App可完全采用OkHttp内置缓存拦截器机制,并自定义CommonHeaderInterceptor拦截器,在每次请求前,把If-Modified-Since添加到Request的Headers中。

    策略5:全服务端策略

    由服务端记录每个用户(每台设备)对每个数据接口的最后一次访问时间戳lastRequestTime,以及该数据最新update的时间戳lastUpdateTime。当每个用户再次访问数据接口时,服务端对比lastRequestTime和lastUpdateTime的先后顺序,判断是否返回data。

    if(lastRequestTime> lastUpdateTime) {

        return null; } else {     return data; }

    App判断响应data是否为空数据(或者定义其他形式的协议),是,获取本地缓存;否,获取响应data。

    特殊情况:用户强制使用remote data,服务端不做时间戳对比,直接返回相应数据。

    说明:

    该策略对端无感知,适合多个团队合作,一个服务器,多个端的情况。但同时服务端需要对每个用户n,每个接口m做最后一次访问时间戳的记录,复杂度n*m。

    总结:

    策略3,4性能无差,策略4对App而言更容易管理,但要充分考虑Cache大小设置;策略3App需要自己封装一套缓存代码,相应滴,也可以达到自定义缓存方式(sql,cache,文件,等等)的效果。

    不同场景下,其实可以考虑把策略1,2,(3,4,5)综合运用,根据业务场景不同,定义相应的接口调用规则(策略1);再由后台根据接口数据的update实际情况,指定App对不同数据的缓存时效(Cache-Control控制)(策略2),从而减少网络访问次数;同时记录data update time,配合App实现缓存与数据实时性并存(策略3,4)的效果。

    说白了,策略1,2缓存的目的是减少网络访问次数,节约网络资源。策略3,4缓存的目的是最大限度节约数据流量,减少带宽压力,同时保证数据实时性。

    扩展

    对于策略5,服务端可以对接口数据变更时间戳,和用户所有接口访问时间戳同时保存(扩展),为后续用户行为分析,数据安全性等方面提供支持。

    Processed: 0.014, SQL: 9