19、怎么保证redis是高并发以及高可用的？

迈不过友情╰ 2022-04-02 04:39 210阅读 0赞

1、面试题

如何保证Redis的高并发和高可用？redis的主从复制原理能介绍一下么？redis的哨兵原理能介绍一下么？

2、面试官心里分析

其实问这个问题，主要是考考你，redis单机能承载多高并发？如果单机扛不住如何扩容抗更多的并发？redis会不会挂？既然redis会挂那怎么保证redis是高可用的？

其实针对的都是项目中你肯定要考虑的一些问题，如果你没考虑过，那确实你对生产系统中的问题思考太少。

3、面试题剖析

就是如果你用redis缓存技术的话，肯定要考虑如何用redis来加多台机器，保证redis是高并发的，还有就是如何让Redis保证自己不是挂掉以后就直接死掉了，redis高可用。

我这里会选用我之前讲解过这一块内容，redis高并发、高可用、缓存一致性。

redis高并发：主从架构，一主多从，一般来说，很多项目其实就足够了，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒10万的QPS。

redis高并发的同时，还需要容纳大量的数据：一主多从，每个实例都容纳了完整的数据，比如redis主就10G的内存量，其实你就最对只能容纳10g的数据量。如果你的缓存要容纳的数据量很大，达到了几十g，甚至几百g，或者是几t，那你就需要redis集群，而且用redis集群之后，可以提供可能每秒几十万的读写并发。

redis高可用：如果你做主从架构部署，其实就是加上哨兵就可以了，就可以实现，任何一个实例宕机，自动会进行主备切换。

01）、redis如何通过读写分离来承载读请求QPS超过10万+？
    
    1、redis高并发跟整个系统的高并发之间的关系
    
    redis，你要搞高并发的话，不可避免，要把底层的缓存搞得很好
    
    mysql，高并发，做到了，那么也是通过一系列复杂的分库分表，订单系统，事务要求的，QPS到几万，比较高了。
    
    要做一些电商的商品详情页，真正的超高并发，QPS上十万，甚至是百万，一秒钟百万的请求量。
    
    光是redis是不够的，但是redis是整个大型的缓存架构中，支撑高并发的架构里面，非常重要的一个环节。
    
    首先，你的底层的缓存中间件，缓存系统，必须能够支撑的起我们说的那种高并发，其次，再经过良好的整体的缓存架构的设计（多级缓存架构、热点缓存），支撑真正的上十万，甚至上百万的高并发。
    
    
    2、redis不能支撑高并发的瓶颈在哪里？
    单机
    
    3、如果redis要支撑超过10万+的并发，那应该怎么做？
    单机的redis几乎不太可能说QPS超过10万+，除非一些特殊情况，比如你的机器性能特别好，配置特别高，物理机，维护做的特别好，而且你的整体的操作不是太复杂。
    
    单机在几万
    
    读写分离，一般来说，对缓存，一般都是用来支撑读高并发的，写的请求是比较少的，可能写请求也就一秒钟几千，一两千。
    
    大量的请求都是读，一秒钟二十万次读。
    
    读写分离
    
    主从架构 -> 读写分离 -> 支撑10万+读QPS的架构
    
    
    4、接下来要讲解的一个topic
    redis replication
    
    redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构

![20181225133046700][]

redis单机的瓶颈.png

![20181225133046725][]

redis主从实现读写分离支撑10万+的高并发.png

02）、redis replication以及master持久化对主从架构的安全意义
    1、redis replication的核心机制
    
    （1）redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认自己每次复制的数据量
    （2）一个master node是可以配置多个slave node的
    （3）slave node也可以连接其他的slave node
    （4）slave node做复制的时候，是不会block master node的正常工作的
    （5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务;
     但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了
    （6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量
    slave，高可用性，有很大的关系
    
    2、master持久化对于主从架构的安全保障的意义
    
    如果采用了主从架构，那么建议必须开启master node的持久化！
    不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，
    可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了。
    master -> RDB和AOF都关闭了 -> 全部在内存中
    
    master宕机，
    重启，是没有本地数据可以恢复的，然后就会直接认为自己IDE数据是空的master就会将空的数据集同步到slave上去，
    所有slave的数据全部清空100%的数据丢失master节点，必须要使用持久化机制。
    
    第二个，master的各种备份方案，要不要做，万一说本地的所有文件丢失了; 
    从备份中挑选一份rdb去恢复master; 这样才能确保master启动的时候，
    是有数据的即使采用了后续讲解的高可用机制，slave node可以自动接管master node，
    但是也可能sentinal还没有检测到master failure，master node就自动重启了，
    还是可能导致上面的所有slave node数据清空故障。

文集：[https://www.jianshu.com/nb/32293473][https_www.jianshu.com_nb_32293473]

[20181225133046700]: /images/20220402/b03a1027dd4b470eb60fc111d819cccd.png
[20181225133046725]: /images/20220402/2e20640d54884f24968309a2c13f4584.png
[https_www.jianshu.com_nb_32293473]: https://www.jianshu.com/nb/32293473