大到阿里，小到三线公司，缓存在大型分布式系统中的最佳应用( 五 ) _缓存

2、内存缓存
直接将数据存储到本机内存中，通过程序直接维护缓存对象，是访问速度最快的方式。
六、缓存架构示例

文章插图

职责划分：
CDN：存放html、CSS、JS等静态资源；
反向代理：动静分离，只缓存用户请求的静态资源；
分布式缓存：缓存数据库中的热点数据；
本地缓存：缓存应用字典等常用数据。
请求过程：
（1）浏览器向客户端发起请求，如果CDN有缓存则直接返回；
（2）如果CDN无缓存，则访问反向代理服务器；
（3）如果反向代理服务器有缓存则直接返回；
（4）如果反向代理服务器无缓存或动态请求，则访问应用服务器；
（5）应用服务器访问本地缓存；如果有缓存，则返回代理服务器，并缓存数据；（动态请求不缓存）
（6）如果本地缓存无数据，则读取分布式缓存；并返回应用服务器；应用服务器将数据缓存到本地缓存（部分）；
（7）如果分布式缓存无数据，则应用程序读取数据库数据，并放入分布式缓存。
七、缓存常见问题
1、数据一致性
缓存是在数据持久化之前的一个节点，主要是将热点数据放到离用户最近或访问速度更快的介质中，加快数据的访问，减小响应时间。
因为缓存属于持久化数据的一个副本，因此不可避免的会出现数据不一致问题。导致脏读或读不到数据的情况。数据不一致，一般是因为网络不稳定或节点故障导致。根据数据的操作顺序，主要有以下几种情况。
场景介绍
（1）先写缓存，再写数据库
如下图：

文章插图

假如缓存写成功，但写数据库失败或响应延迟，则下次读取（并发读）缓存时，就出现脏读。
（2）先写数据库，再写缓存
如下图：

文章插图

假如写数据库成功，但写缓存失败，则下次读取（并发读）缓存时，则读不到数据。
（3）缓存异步刷新
指数据库操作和写缓存不在一个操作步骤中，比如在分布式场景下，无法做到同时写缓存或需要异步刷新（补救措施）时候。

文章插图

此种情况，主要考虑数据写入和缓存刷新的时效性。比如多久内刷新缓存，不影响用户对数据的访问。
解决方法
第一个场景：这个写缓存的方式，本身就是错误的，需要改为先写持久化介质，再写缓存的方式。
第二个场景：
（1）根据写入缓存的响应来进行判断，如果缓存写入失败，则回滚数据库操作；此种方法增加了程序的复杂度，不建议采用；
（2）缓存使用时，假如读缓存失败，先读数据库，再回写缓存的方式实现。
第三个场景：
（1）首先确定，哪些数据适合此类场景；
（2）根据经验值确定合理的数据不一致时间，用户数据刷新的时间间隔。
其他方法
（1）超时：设置合理的超时时间；
（2）刷新：定时刷新一定范围内（根据时间，版本号）的数据；
以上是简化数据读写场景，实际中会分为：
（1）缓存与数据库之间的一致性；
（2）多级缓存之前的一致性；
（3）缓存副本之前的一致性。
2、缓存高可用
业界有两种理论，第一套缓存就是缓存，临时存储数据的，不需要高可用。第二种缓存逐步演化为重要的存储介质，需要做高可用。
本人的看法是，缓存是否高可用，需要根据实际的场景而定。临界点是是否对后端的数据库造成影响。
具体的决策依据需要根据，集群的规模（数据，缓存），成本（服务器，运维），系统性能（并发量，吞吐量，响应时间）等方面综合评价。
解决方法
缓存的高可用，一般通过分布式和复制实现。分布式实现数据的海量缓存，复制实现缓存数据节点的高可用。架构图如下：

文章插图

其中，分布式采用一致性Hash算法，复制采用异步复制。
其他方法
（1）复制双写：缓存节点的复制，由异步改为双写，只有两份都写成功，才算成功。
（2）虚拟层：一致性Hash存在，假如其中一个HASH环不可用，数据会写入临近的环，当HASH可用时，数据又写入正常的HASH环，会导致数据偏移问题。这种情况，可以考虑在HASH环前面加一个虚拟层实现。