前端数据加载的优秀实践

朴素的模型明显存在一个问题：每个外部请求都会触发多次内部服务调用，这样的做法非常浪费资源，因为对于大多数内部微服务而言，请求的结果在一定的时间内都是 可缓存 的。

比如用户的头像可能几天几周甚至几个月才更新一次，这种情况下前端服务完全可以缓存用户的头像一段时间，这段时间内，读取用户头像可以从直接从缓存内读取，而不需要请求后台，很大程度上节省了后台服务的负担。

加入本地缓存

于是我们在前端服务中加入了本地内存缓存（Local Cache），让大多数请求都命中本地缓存，从而减少了后台服务的负担：

地缓存通常是放置在内存里的，而内存空间比较有限，所以我们需要引入 缓存淘汰 的机制，限制内存最大容量。具体的缓存淘汰算法就有很多了，比如 FIFO、LFU、LRU、MRU、ARC 等等，可以根据业务的实际情况来选择合适的算法。

引入本地缓存之后，依然会有一个问题：缓存只能在单个服务实例（服务实例可以理解为服务器、K8S Pod之类的概念）上生效，而大多数前端服务为了能够横向扩容，一般都是无状态的，所以会有大量并存的实例。

也就是说，本地缓存可能只会在某台服务器上生效，而其他平行的服务器上没有缓存，如果请求打到了没有缓存的服务器上，那么依然无法命中缓存。

't Repeat Yourself! 我们显然需要把这段缓存逻辑抽象出来，避免重复代码。

加入 Cache 层和中心化缓存

为了解决上面两个问题，我们继续改进我们的架构：

加入 中心化的远程缓存 （比如 Redis、Memcache），让远程缓存可以作用到所有实例上面；

将缓存、RPC 等非应用层的逻辑 抽象为单独的组件（Cache Layer） ，用来封装后台微服务的读写、本地缓存、远程缓存相关的逻辑。象出这样一层 Cache Layer 之后，我们便可以进一步演进我们的服务。

加入缓存刷新机制

虽然我们有了中心化的缓存，但缓存毕竟只是短期内有效的。一旦缓存失效，那就还是得向后台服务请求数据，在这种临界条件下，请求耗时就会增加，出现耗时的毛刺现象（每隔一段时间，有小部分请求耗时变大）。

那么 有没有办法可以让缓存一直保持“新鲜”呢 ？这就需要缓存刷新的机制了，大体上讲，缓存刷新分为主动刷新和被动刷新两种：

主动刷新

主动刷新即每当数据有更新的时候，刷新缓存，下游服务永远只读取缓存内的数据。

读多写少的后台服务非常适合这种模式，因为读请求永远不会打到数据库里，而是被分流到性能、扩展性高几个档次的缓存组件上面，从而很大程度上减轻数据库的压力。

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!