这周遇到了一个新需求，产品反馈地图瓦片服务的图片资源没有Http缓存，每次移动地图范围都会向后台发处请求/响应数据，影响了客户端的地图加载体验。所以需要增加这样一种缓存：1）针对同一个请求资源地址URL，首次加载需要缓存数据，后续加载直接读取缓存；2）后台数据发生更新时，需要实时更新缓存；
在完成这个需求之前，我借机补习了一下前端的缓存体系：
一 HTTP缓存
提起前端缓存，首先第一反应就是浏览器自带的缓存机制，通过在Http报文头部中设置一些属性字段，告知浏览器对本次请求响应的资源进行缓存，之后对于相同URL的资源请求则直接从缓存中读取。这个思路没错，那具体应该如何实现呢？这就需要我们对这些属性进行简单介绍一下：
1 强缓存
首次请求资源A设置缓存，再次请求资源A时直接查找缓存，如果缓存命中，则不发送新的请求；否则发送新请求；
控制强缓存的主要属性字段：
【Expire】：HTTP1.0标准下的字段，指定一个日期或时间，在时间过期前执行上述逻辑，时间过期后重新执行
【Cache-Control】：
field description
private 仅客户端缓存
public 客户端和代理服务器缓存
max-age=xxx 缓存内容将在xxx秒后失效（相对请求时间）
s-max-age 仅适用于public共享缓存
no-cache 需要使用协商缓存来验证缓存（会发送新的请求）
no-store 所有内容都不缓存
must-revalidate
2 协商缓存
顾名思义，由服务端协助客户端实现缓存机制：即在资源B已缓存的前提下，再次请求资源B时，会继续想服务器端发送请求，通过服务器发送请求，获取资源B是否失效的信息，如果未失效，返回未失效Flag告知前端，从而在缓存中获取资源B，如果失效，则返回新的数据和报文缓存头设置；
常用的协商缓存包括：
【Cache-Control的must-revalidate】：标识每次必须向服务端请求验证资源
【Etag】-【if-none-match】：资源的唯一标识，即在第一次请求资源C时，会计算一个能够唯一标识当前资源Ｃ的tag值，并放在response的Etag属性字段中，当资源C缓存在前端后，后续的每一次请求资源C都会将tag值设置在请求request的if-none-match中，服务端根据tag值进行判断当前请求资源C是否发生变化，如变化这表示缓存未命中，返回新的资源C，否则返回缓存命中标识，直接返回304获取资源C在前端的缓存。
【last-modified】-【if-modified-since】：同上Etag，只不过此处一般以时间戳作为判断依据，服务端则需要获取资源C的文件最后修改时间（这个在JAVA中File提供了getLastModified方法），并将时间戳赋值给response中的last-modified属性字段，后续的每一次请求会将时间戳放在if-modified-since中，与后台的新时间戳对比，如果时间戳不同，则表示缓存未命中，返回新的资源C，否则返回缓存命中标识，前端获取缓存值；
3 实现
OK，梳理完上述的Http缓存机制后，我们很容易发现如果要满足需求（即客户端缓存数据，且能够在数据发生变化后请求返回新的数据，更新缓存），应当选择协商缓存。
策略选择好之后，实现还是比较简单的，我们这里以时间戳为例：
3.1） 后台在返回数据时增加时间戳判断：
Public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ //......
String filePath = ""; // File fileC = new File(filePath); long lastNew = fileC.lastModified(); String lastNewStr = Long.toString(lastNew); //获取当前资源的最后修改时间 String lastOldStr = request.getHeader("if-modified-since"); //获取当前资源缓存的最后修改时间 if(lastNewStr.equalsIgnoreCase(lastOldStr)){ Response.setStatus(304); //返回304 not modified }else{ //获取新的数据 } // ...... }
3.2） 验证效果
效果比较尴尬，因为在实现了这类缓存后，请求响应资源的效率提高并不明显，虽然实现了缓存，但是每次资源校验依然要经过一次完整的请求响应过程，其中的连接开销应该是耗时的主要部分，而非数据的传输。所以，只能临时更改策略，采用期限强缓存，后台如果更新数据，则需要客户端手动刷新缓存。
实现方法如下，采用Cache-Control的max-age，以一天时间为缓存期限：
Public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ //… response.setHeader("Cache-Control", "max-age=86400"); //… }
二 前端数据库缓存
在完成这个任务后，我突然想起来之前在完成矢量地图渲染时，为了提高前端中文字体加载效率，曾经使用过前端数据库indexDB作为缓存技术，这个和Http缓存又有什么不同呢？一般来说，前端数据库主要有一下几种：
1 cookie
常用场景：用户个人信息保存（用户名/密码）
存在问题：
容量：4KB
数据安全问题
2 localStorage/sessionStorage【键值对】：本地浏览器数据库，根据浏览器不同，缓存容量不同，一般5MB左右，适合存储一些常用结构简单的数据；
localStorage.setItem("key", "value")
localStorage.getItem("key")
localStorage.removeItem("key")
localStorage.clear()
优势场景：
兼容性好，易操作
缺点：
容量小，每个域名分配3-5M空间
3 indexedDB【结构化对象】：本地数据库存储，使用索引高效检索，异步处理；
优势场景：
a 异步操作，可大量读写数据而不阻塞浏览器主线程
b 支持事务
c 存储空间大（250MB->更多）
d 支持二进制存储ArrayBuffer和Blob
缺点：
操作比较繁琐复杂，不如localStorage方便
实现：
var databaseName = "test"
var version = "20191121"
var request = window.indexedDB.open(databaseName, version) //创建一个indexedDB数据库
具体操作略微有些复杂，需要熟悉相关API接口，此处就不作详细介绍了，具体可以参照阮一峰的教程；
三 比较
比较Http缓存和前端数据库缓存，暂时没有发现这些缓存有什么明显的差异，只是针对应用场景不同而已：
1）Http缓存一般能够缓存一些前端请求的一些公共资源，减少一些不必要的请求响应开销，提高web端的体验
2）而前端数据库缓存则能够缓存一些高频常用的业务数据，提高业务请求的数据返回速度，比如高德地图和百度地图： 【高德地图】：打开Chrome控制台的Application选项卡，可以查看IndexedDB中的数据，其中包含了road/region等矢量瓦片数据； 【百度地图】：打开IndexedDB空空如也，但是在LocalStorage中发现了一些POI搜索记录；并且百度地图的矢量数据服务利用了Cache-Control属性强缓存了矢量数据，从而减小实时的数据请求。