这篇文章主要介绍“redis Cluster常见面试题有哪些”，在日常操作中，相信很多人在Redis Cluster常见面试题有哪些问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Redis Cluster常见面试题有哪些”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联公司公司2013年成立，先为张家界等服务建站，张家界等地企业，进行企业商务咨询服务。为张家界企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
在redis cluster集群架构中，可以由N个redis master node组成，每个master node都可以挂载多个slave node。
可以自动将数据进行分片，每个master上放一部分数据；
还提供内置的高可用支持，部分master不可用时，还是可以继续工作的，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master；
支持读写分离：对于每个master来说，都负责写请求，写就写到master，然后读就从mater对应的slave去读；
总结：redis cluster（多master + 读写分离 + 高可用）
我们只要基于redis cluster去搭建redis集群即可，不需要再手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用，不需要这样去搭了。
redis replication + Sentinal：redis的一主多从，读写分离+哨兵机制
如果数据量很少，主要是承载高并发高性能的场景，比如缓存一般就几个G的话，单机足够了。那就搭建主从复制的架构（redis replication），一个mater，多个slave，要几个slave跟你要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了。
而redis cluster 主要是针对海量数据+高并发+高可用的场景，如果是海量数据，如果你的数据量很大，那么建议就用redis cluster。
redis cluster有固定的16384个hash slot（哈希槽），对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。
redis cluster中每个master都会持有部分slot（槽），比如有3个master，那么可能每个master持有5000多个hash slot。
hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。每次增加或减少master节点都是对16384取模，而不是根据master数量，这样原本在老的master上的数据不会因master的新增或减少而找不到。并且增加或减少master时redis cluster移动hash slot的成本是非常低的。
redis cluster节点间采取gossip协议进行通信，所有节点都持有iFeng元数据，不同的节点如果出现了元数据的变更之后U不断地i将元数据发送给其他节点让其他节点进行数据变更。
节点互相之间不断通信，保持整个集群所有节点的数据是完整的。
主要交换故障信息、节点的增加和移除、hash slot信息等。
这种机制的好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力;
缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后。
首先，如果是读高并发的话，先看读并发的数量级是多少，因为redis单机的读QPS在万级，每秒几万没问题，使用一主多从+哨兵集群的缓存架构来承载每秒10W+的读并发，主从复制，读写分离。使用哨兵集群主要是提高缓存架构的可用性，解决单点故障问题。主库负责写，多个从库负责读，支持水平扩容，根据读请求的QPS来决定加多少个redis从实例。如果读并发继续增加的话，只需要增加redis从实例就行了。
因为Redis支撑海量数据的瓶颈在于单机容量，所以这个时候我会选择redis cluster模式，每个主节点存一部分数据，假设一个master存32G，那只需要n*32G>=1T，n个这样的master节点就可以支持1T+的海量数据的存储了。
Redis单主的瓶颈不在于读写的并发，而在于内存容量，即使是一主多从也是不能解决该问题，因为一主多从架构下，多个slave的数据和master的完全一样。假如master是10G那slave也只能存10G数据。所以数据量受单主的影响。
而这个时候又需要缓存海量数据，那就必须得有多主了，并且多个主保存的数据还不能一样。redis官方给出的 redis cluster 模式完美的解决了这个问题。
其实这是问到缓存必问的，因为缓存雪崩和穿透，那是缓存最大的两个问题，要么不出现，一旦出现就是致命性的问题。所以面试官一定会问你。
我先描述下如何出现的缓存雪崩吧。
举个例子，假设每天高峰期的时候系统每秒请求是5000次，缓存在高峰期可以分担每秒4000次请求，另外1000次请求落到数据库（假设数据库每秒可承担2000次请求）。如果此时过来5000请求，但是redis因为某些原因挂掉了，缓存整个就不能用了，那么这5000个请求就全部落到数据库。显然数据库扛不住，直接崩溃。此时，如果没用什么特别的方案来处理这个故障，只是很着急的重启数据库，结果因为缓存还没数据，立马数据库又被新的流量给打死了。这就是缓存雪崩。
对于缓存雪崩主要分为事前事中事后，事前：如果缓存不可用是因为缓存中的大部分数据集中失效，我们可以对缓存的失效时间加上一个随机值，使失效时间分散一点，尽量避免集中失效。另外如果是因为别的原因redis宕机导致缓存不可用，这时候我们就需要提前做好Redis高可用的架构，如主从+哨兵或redis cluster，来避免Redis出现故障时整个缓存不可用，全盘崩溃。
事中：可以将一小部分数据同样缓存到本地ehcache（本地缓存组件）缓存，另外加上hystrix限流&降级组件，避免MySQL被打死。
事后：如果真的发生雪崩，我们还可以用redis的RDB或AOF重启redis快速从磁盘加载缓存数据。这就需要我们提前打开Redis持久化机制，在雪崩发生的事后快速恢复缓存数据，一旦重启从磁盘中恢复数据到内存。
另外一个问题，缓存穿透，一般是黑客恶意攻击，或是自己系统出bug。例如黑客恶意伪造请求，这些请求都是数据库根本查不到的，所以缓存中也没用，那这些大量的恶意请求都会落到数据库去查询，数据库不就挂了吗？
解决办法就是
1、只要从数据库没查到，就写入一个空值到缓存里去。
2、使用布隆过滤器对请求的key进行一层过滤，过滤掉系统认为不存在不合法的key。
到此，关于“Redis Cluster常见面试题有哪些”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
