爱奇艺本地实时 Cache 方案

高并发系统离不开 Cache，通过采用更多的本地 Cache 来提升系统吞吐量和稳定性是必然的，这其中的最大难点就是解决分布式本地 Cache 数据的实时性和一致性问题，否则本地 Cache 就无法更普遍应用于频繁变更的数据上。

没有最完美的方案，只有更合适的方案。本文将详细讲解爱奇艺 TV 后台分布式实时本地 Cache 实践方案，给大家解决高并发问题提供一个参考。

一、背景

目前互联网系统大多是读多写少的系统，面对读多写少的系统，大家一定会拆分为读系统、写系统，提高系统稳定性和吞吐量，今天我们所讲的 Cache 主要是面向读的系统。

爱奇艺拥有大量版权内容的 Metadata，在不同的业务场景都需要将这些 Metadata 和相应的关联数据作为基础数据返回，为了提高业务迭代速度，降低系统耦合，我们将这些基础数据的组装环节拆分为独立的服务，该服务提供包括通用和个性化逻辑的封装，所有用到基础数据的地方调用此微服务。每条数据大约几 KB 到十几 KB 不等，且数量不断增长。该服务作为基础服务对各子业务服务。

如何解决该服务对集中式 Cache 带来的高并发问题（高峰期支撑百万级 QPS）：比如集中式 Cache 内网带宽损耗、Cache 网络故障超时场景等问题。以下提供众多解决方案中的一个解决方案。

二、思路 &方案

首先对比一下本地 Cache 与集中 Cache 的优缺点：

1.本地 Cache

其优点有：

（1）热点缓存，每扩容一个实例就相当于扩容了一个热点数据库；

（2）命中率高；

（3）过期策略；

（4）业务逻辑速度快，机器损耗低；

（5）抗风险能力强。

其缺点有：

（1）一般是被动缓存，实时性差；

（2）存储量有限，配备 2GB~4GB，足矣满足当前大部分场景的热点数据。

2.集中 Cache

其优点有：

（1）方便实时更新 Cache；

（2）缓存一致性强。

其缺点如下：

（1）集群过大，依赖过重；

（2）并发量高时，IO 过重；

（3）易受应用机器到缓存机器之间的网络抖动影响；

（4）热点 Key 访问量过大时，容易将带宽跑满，需要多 Cache 集群来解决。

对比如上优缺点，大部分人都会采用本地热点 Cache，本地存储 4GB 一般都能满足常见的业务热点数据，但是本地 Cache 实时性差，如何解决实时性？如下为解决方案：

3.解决方案

通过统一的消息机制来触发本地 Cache 的实时更新，同时提供消息过滤机制，由业务方自行处理逻辑，这样可以实现本地 Cache 个性化更新方案。方案如下：

4.方案说明

（1）管理后台：管理使用该本地 Cache 的所有应用实例及缓存策略；

（2）数据变更：数据变更源头；

（3）消息总线：消息的集散中心；

（4）业务 Filter：业务方可以自行处理部分消息；

（5）监控统计：采用爱奇艺统一的日志收集系统，可以用来统计分析热点数据，为其它热点方案提供数据支持，监控采用统一监控，监控各个实例的 Cache 命中等指标

三、扩展

当单个集群本地 Cache 命中率低于可接受临界值（比如 70%）时，内存受限无法扩大本地 Cache 存储，可拆分成轻逻辑数据分片集群，即可提高命中率。

四、效果总结

（1）有效降低了集群雪崩的风险；

（2）解决了高并发读的问题；

（3）减少热点数据的网络穿透，降低集中式 Cache 的负担。