axios-cache-adapter与Redis用于API响应缓存的优劣势对比及选型建议

首先要明确二者的定位差异：axios-cache-adapter是基于axios封装的HTTP请求缓存中间件，本身自带完整的缓存判断、读写逻辑；ioredis是Node.js生态的Redis客户端驱动，本身不直接提供API响应缓存能力，需要你基于它自行封装缓存规则、请求拦截逻辑才能实现需求。

各自优劣势对比 #

axios-cache-adapter #

• 优势
  • 开箱即用，不需要额外手写缓存命中判断、请求拦截、响应落盘逻辑，仅需给axios实例增加少量配置项即可启用缓存，对现有axios请求的侵入性极低
  • 内置内存、localStorage等多种存储适配器，前端浏览器、单实例Node.js服务端都可以直接使用，小型项目不需要额外部署缓存服务
  • 原生支持按请求方法、响应状态码、URL规则自定义缓存策略，也支持自定义缓存key生成规则、过期时间配置
• 劣势
  • 默认内存缓存会随服务/页面重启丢失，内置的持久化存储容量上限低，不支持多实例共享缓存（比如多台Node服务分布式部署时，内存缓存各存各的，整体命中率很低）
  • 缓存淘汰策略灵活度低，不支持复杂的缓存主动失效、预热等定制需求，仅适合简单的GET请求缓存场景
  • 性能上限低，高并发大流量场景下内存缓存会占用大量服务内存，内置持久化存储的读写速度也跟不上需求

ioredis（搭配自行封装的缓存逻辑） #

• 优势
  • 缓存数据存储在Redis中，支持多实例共享，分布式部署场景下缓存命中率高，服务重启后缓存也不会丢失
  • 支持丰富的缓存操作能力：主动失效、自定义过期时间、缓存预热、LRU淘汰等，可以匹配复杂的业务规则，比如对应接口的源数据更新后可以主动清除相关缓存
  • 性能高，Redis本身是单线程内存数据库，读写QPS可达万级以上，完全可以支撑高并发场景的缓存查询需求
  • 支持缓存数据的持久化、备份，适合核心接口响应的缓存存储
• 劣势
  • 不能直接实现API缓存，需要自行在请求层封装拦截逻辑：请求发起前先查Redis是否有对应缓存key，命中就直接返回，未命中再请求源接口，拿到响应后写入Redis，对现有业务代码有一定侵入性
  • 需要额外部署、维护Redis服务，小型项目会增加运维成本
  • 存在网络开销：如果用远程Redis服务，每次缓存查询会有几毫秒的网络延迟，比本地内存缓存的响应速度慢

选型建议 #

• 如果你是前端单页应用或者单实例部署的小型Node服务，接口缓存不需要跨实例共享、缓存数据量不大、没有复杂的缓存主动更新需求，直接选axios-cache-adapter，开发成本最低
• 如果你是分布式部署的后端/网关服务，需要多实例共享缓存、缓存量较大、有主动清缓存、缓存预热等业务需求，或者接口流量很高，就选ioredis+自行封装缓存逻辑的方案，长期可扩展性更强
• 折中方案：也可以给axios-cache-adapter配置Redis存储适配器，把缓存落地到Redis中，兼顾axios-cache-adapter的低侵入性和Redis的分布式能力，适合不想自己写封装逻辑又需要分布式缓存的场景

内容的提问来源于stack exchange，提问作者nanquim