现在，缓存零碎的利用十分宽泛，可能用来进步并发数、数据吞吐量，进步疾速响应能力。那么当数据量达到肯定水平，单机环境可能就显得有些力不从心了，就须要一个分布式缓存零碎。
1. 缓存零碎的抉择
1.1 缓存分类
如上图所示，首先缓存大抵能够分为四大类。
- CDN 缓存：CDN 即内容散发网络，CDN 边缘节点将数据缓存起来。
- 反向代理缓存：如 Nginx 的缓存。
- 本地缓存：代表的有 EhCache 和 Guava Cache。
- 分布式缓存：各缓存零碎。
1.2 分布式缓存
本文次要探讨各分布式缓存零碎，如图 1-1 所示，列出了五种：
其中 EvCache 和 Aerospike 应用场景不是那么通用和宽泛。
- EvCache：是 Netflix 的基于 Memcached & Spymemcached 的缓存计划。
- Aerospike：是可基于 SSD 的 KV NoSQL 数据库。
除此之外，还有三种常见缓存零碎。
- Tair：阿里开源，跨机房、性能随结点增加线性回升、实用大数据量。Tair 还有三种引擎。
-
- LDB: 基于 google levelDB，反对 KV 和类 HashMap 构造，性能稍低，长久化可靠性最高。
- MDB: 基于 Memcache，反对 KV 和类 HashMap，性能最优，不反对长久化存储。
- RDB: 基于 Redis。
- Memcache: 不反对数据同步、分布式反对较差。
- Redis: 社区沉闷、应用最多。
综上所述，在个别状况下，思考到适用性和稳定性，Redis 是搭建缓存零碎的最优抉择。以下将基于 Redis 介绍。
2. Redis 集群缓存计划
如顶部图 1-1 所示，列出了 Redis 的集群高可用的计划，根本能够分为三种。
2.1 主从机制
常见的集群架构，搭建简略，次要实现读写拆散和备份，能够由 Master 负责读写，Slave 负责备份。但存在故障复原简单、程度拓展难、写能力受限等问题。结构图如下：
2.2 哨兵机制
Redis Sentinel 是社区版本推出的原生高可用解决方案。由一或多个哨兵实例监督任意个主从服务器，且在 Master 宕机时，主动将宕机服务器属下的 Slave 服务器降级为 主服务器，从而保证系统的可用性。较主从实现的监控、选主。但问题次要是要保障 Master 的 HA 切换。结构图如下：
2.3 “ 分布式 ”
到这里以上两种机制其实只能算作“集群”，并非严格意义上的“分布式”。接着来看看分布式计划。
集群强调高可用，分布式在集群的根底上又强调合作。
3. Redis 分布式缓存计划
任何分布式存储系统，首先面临的就是 sharding（分片）问题，如顶部图 1-1 所示该问题有为三种解决办法。
3.1 客户端分片
顾名思义，将数据分片的路由性能交给客户端，但这是一种动态分片，维护性差。根本是不予考虑的。
3.2 代理分片
通过代理散发到具体的 redis 实例。有两个罕用解决方案。
- Twemproxy：Twitter 开源，轻量级，不再保护，无奈平滑地扩容 / 缩容，运维也不是很敌对，性能个别。
- Codis：豌豆荚开源，反对程度拓展，运维平台欠缺，性能较 Twemproxy 快。Codis 在国内应用的较多，同时代理分片的思路也有很多公司在此基础开发了本人的二次计划。不过 Codis 也不再保护。
其实，这两种代理分片的计划，都是在 Redis 官网未推出良好的分布式计划时的产生的，在官网更新提供更优策略后都不再保护。
3.3 服务器端分片
这就要谈到 Redis 官网计划 Redis-cluster。
在 Redis 3.0 之前是没有较好的分布式计划的，这也是第三方计划呈现的起因。3.0 开始，官网推出了去中心化的分布式计划。集群中蕴含 16384 个散列槽，每个节点负责其中一部分。
先看下拓扑图：
每个节点关上两个 TCP 连贯，一个负责给客户端提供服务，一个负责节点间通信。
此刻要说说 CAP 了：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）。对分布式系统而言，CAP 必须就义一者。Redis Cluster 的设计指标次要是高性能、高可用和高扩大，只好摈弃一部分数据一致性。
- 数据一致性：因为 Redis Cluster 应用异步复制，在某些状况下如 Master 宕机但未同步至 Slave，可能会导致失落写入。在相对须要反对同步写入时，可通过 WAIT 命令实现，可使得失落写入的可能性大大降低。
- 可用性：当集群中一部分节点故障后，集群整体能响应客户端读写申请。
-
- 节点间定时互 ping，当超过一半 Master 断定某节点失败，则标记为 FAIL，且会向集群播送节点下线的音讯。如下线节点是带有槽的主节点，则要从它的从节点选出一个替换。
- 高性能和拓展：操作某个 key 时，不会先找到节点再解决，而是间接间接重定向到该节点，同时相较代理分片也少了 proxy 的连贯损耗。
-
-
然而在进行 multiple key 操作时须要 keys 位于同一个 slot 上，须要应用 hash tags，应用 {} 强制将某些 key 映射到每个 slot，以便进行 multiple。
- 在拓展方面，Redis Cluster 最大反对线性拓展 1000 个节点，将新节点退出集群后能够通过命令指定和均匀的从已有节点调配 slot。
-
4. 缓存常见问题
以上介绍了简略介绍了常见缓存零碎，并具体列出了基于 Redis 的集群计划。上面谈一谈缓存零碎常见的问题。
如下图所示，列出七个常见问题。
4.1. 缓存穿透
指拜访不存在的数据，从而绕过缓存，间接申请到了数据源，当申请过多，就会对 DB 造成压力。
- 空 key：指对于不存在的数据也将 key 存空值入缓存零碎，这样下次访问也会失去返回。但只实用于空数据 key 无限、key 反复申请概率高，如果量大且不反复，就会造成很多无用 key 的创立。
- 布隆过滤器：布隆过滤器是一个很长的二进制向量和一系列随机映射函数。可用于检索一个元素是否在一个汇合中加一层对空值的过滤器，空间和工夫效率都很高。但因为 hash 产生的碰撞可能存在误判，以及因不存储 key 导致的无奈删除。实用于空数据 key 各不同、反复申请概率低。
4.2. 缓存击穿
缓存击穿理论是缓存雪崩的一个特例。指当某些热点 key 过期时，就会有大量的申请击穿到 DB。
- 互斥锁：在缓存生效的时候，不立刻 load db，能够先用如 SETNX 等命令去 set 一个 mutex key，当操作返回胜利时，阐明拿到锁，此刻该线程进行 load db 的操作并更新缓存；否则未拿到锁就（可休眠一段）重试 get 缓存的办法。但要留神死锁危险。
- 不过期
-
- 这里的不过期有两个概念，一个指未设过期工夫，那是真的不过期，那没事了。
- 另一个是指通过业务逻辑，将 key 的过期工夫进行存储，申请是判断是否小于值，是则后盾异步更新。
4.3. 缓存雪崩
同一时刻大量缓存生效（故障）, 申请到了 DB。
- 随机工夫：在设置过期工夫时，能够在根底工夫上 + 一个随机的工夫，等于实现了分批过期。
- 后盾更新：将更新生效的工作交给后盾定时线程。
- 限流 + 本地缓存：如 ehcache 本地缓存 + Hystrix 限流。
- 双缓存：相似于设置主从缓存，从 key 不过期。
4.4. 缓存更新与一致性
如果保证数据一致性。列出四种更新策略：
- Cache Aside：最罕用的。生效时回源取数据，更新；命中时，返回缓存数据；更新时先数据源更新，再更新缓存。
- Write Back：更新数据时，只更新缓存，不更新数据源。缓存异步批量更新数据库。
- Read/Write Through
-
- Write Through：当有数据更新时，如未命中缓存，间接更新数据库，并返回。如命中缓存，则更新缓存，再由 Cache 本人更新数据库。
- Read Through：更新数据源由缓存零碎操作，读取数据时如缓存生效，则取回源数据更新缓存。
4.5. 热点数据
对于热点数据的解决办法。
- 拆分简单构造：如二级数据结构，进行拆分，这样热点 key 就被拆为若干个的 key 散布到不同节点。
- 迁徙热点：对于 Redis Cluster 而言能够将热点 key 所在的 slot 独自迁徙到一个节点，升高其余节点压力。
- 多正本：复制多份缓存正本，将申请扩散到多个节点上，加重单台缓存服务器压力，适宜多读少写。
4.6. 缓存预热
指能够将某些的缓存数据提前加载到缓存零碎，提前防止在如热点数据大量申请到库。
4.7. 缓存降级
指当访问量剧增、服务呈现问题或非核心服务影响到外围流程的性能时，仍需保障主服务可用。可依据一些要害数据主动降级，也可配置开关人工降级。
5. Redis Cluster 应用
对于 Redis Cluster 环境的搭建和根底应用非常简单。
无论基于何种形式，只有搭建好 n 台 redis 服务并保障各服务间能够相互通信后，任意进入一个 redis 服务键入：
redis-cli --cluster create IP1:port1 IP2:port2 IP3:port3 IP4:port4 IP5:port5 IP6:port6 ... --cluster-replicas 1即可。之后能够应用 cluster node 和 cluster info 命令查看集群、节点信息。
而对于宽广 JAVA 开发，Spring Data Redis 从 1.7 起即反对 Redis Cluster，只需配置 Master 节点地址（和明码）。
spring.redis.cluster.nodes=ip1:port1,ip2:port2,ip3:port3退出依赖
compile("org.springframework.boot:spring-boot-starter-data-redis")即可通过 RedisTemplate 应用。
6. 总结
本文从缓存零碎的抉择登程，基于 Redis 介绍了几种集群计划并重点阐明了 Redis Cluster 计划。之后列出缓存零碎常见问题及常见解决方案，最初对应用做了简略阐明。
当然，如何去落地，如何解决这些问题还须要依据理论场景具体分析和解决。
参考资料
- Redis Cluster Specification：https://redis.io/topics/clust…
- 深刻了解分布式系统中的缓存架构：https://juejin.im/entry/5b514…
- 缓存更新的套路：https://coolshell.cn/articles…
- 一种高效的 Redis Cluster 的分布式缓存零碎[J]. 计算机系统利用,2018,27(10):91-98：https://kns.cnki.net/KCMS/det…
原文链接：https://mp.weixin.qq.com/s/cO…
欢送关注公众号【码农开花】一起学习成长
我会始终分享 Java 干货，也会分享收费的学习材料课程和面试宝典
回复：【计算机】【设计模式】【面试】有惊喜哦