| 失效链接处理 |
|
Redis Cluster：缓存的数据量太大怎么办？ PDF 下载
本站整理下载：
相关截图：
主要内容：
来来来！⼀起来盘盘 Redis Cluster 常⻅的问题。如果你的项⽬⽤到了 Redis 的话
（⼤部分⼈的项⽬都⽤到了 Redis 来做分布式缓存），为了能⽐别⼈更有亮点，
Redis Cluster 是⼀个不错的选择。
这篇⽂章原本写了接近 8000 字，有点写嗨了，后⾯删减到了现在的 5000+ 字。
为了帮助理解，我⼿绘了很多张图解，尽可能⽤⼤⽩话的语⾔来讲。
建议带着下⾯这些重要的问题（⾯试常问）阅读：
为什么需要 Redis Cluster？解决了什么问题？有什么优势？
Redis Cluster 是如何分⽚的？
为什么 Redis Cluster 的哈希槽是 16384 个?
如何确定给定 key 的应该分布到哪个哈希槽中？
Redis Cluster ⽀持重新分配哈希槽吗？
Redis Cluster 扩容缩容期间可以提供服务吗？
Redis Cluster 中的节点是怎么进⾏通信的？
⾼并发场景下，使⽤ Redis 主要会遇到的两个问题：
1. 缓存的数据量太⼤ ：实际缓存的数据量可以达到⼏⼗ G，甚⾄是成百上千
G；
2. 并发量要求太⼤ ：虽然 Redis 号称单机可以⽀持 10w 并发，但实际项⽬中，
不可靠因素太多，就⽐如⼀些复杂的写/读操作就可能会让这个并发量⼤打折
扣。⽽且，就算真的可以实际⽀持 10w 并发，达到瓶颈了，可能也没办法满
⾜系统的实际需求。
主从复制和 Redis Sentinel 这两种⽅案本质都是通过增加主库（master）的副本
（slave）数量的⽅式来提⾼ Redis 服务的整体可⽤性和读吞吐量，都不⽀持横向
扩展来缓解写压⼒以及解决缓存数据量过⼤的问题。
对于这两种⽅案来说，如果写压⼒太⼤或者缓存数据量太⼤的话，我们可以考虑
提⾼服务器硬件的配置。不过，提⾼硬件配置成本太⾼，能⼒有限，⽆法动态扩
容缩容，局限性太⼤。从本质上来说，靠堆硬件配置的⽅式并没有实质性地解决
问题，依然⽆法满⾜⾼并发场景下分布式缓存的要求。
通常情况下，更建议使⽤ Redis 切⽚集群 这种⽅案，更能满⾜⾼并发场景下分布
式缓存的要求。
简单来说，Redis 切⽚集群 就是部署多台 Redis 主节点（master），这些节点之
间平等，并没有主从之说，同时对外提供读/写服务。缓存的数据库相对均匀地分
布在这些 Redis 实例上，客户端的请求通过路由规则转发到⽬标 master 上。
为了保障集群整体的⾼可⽤，我们需要保证集群中每⼀个 master 的⾼可⽤，可以
通过主从复制给每个 master 配置⼀个或者多个从节点（slave）
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
