最后
俗话说，好学者临池学书，不过网络时代，对于大多数的我们来说，我倒是觉得学习意识的觉醒很重要，这是开始学习的转折点，比如看到对自己方向发展有用的信息，先收藏一波是一波，比如如果你觉得我这篇文章ok，先点赞收藏一波。这样，等真的沉下心来学习，不至于被找资料分散了心神。慢慢来，先从点赞收藏做起，加油吧！
另外，给大家安排了一波学习面试资料：
以上就是本文的全部内容，希望对大家的面试有所帮助，祝大家早日升职加薪迎娶白富美走上人生巅峰！
（2）多进程启动：此时系统有且仅有一个Master进程，至少有一个Worker进程工作。
（3）Master进程主要进行一些全局性的初始化工作和管理Worker的工作；事件处理是在Worker中进行的。
1、Redis的的用途和场景
高性能与高并发 各种业务场景如何利用Redis秀操作，可以参考《Redis数据说明》
2、使用不当的后果
缓存与数据库的数据一致性
缓存雪崩
缓存穿透
缓存并发竞争
3、redis为啥高性能
绝大部分请求是纯粹的内存操作（非常快速），数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
数据结构简单，对数据操作也简单
采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
非阻塞IO - IO多路复用，“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
4、redis的数据类型
string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。
5、redis的过期策略
两种策略组合，保证过期的key一定能删掉。
定期删除，每隔100ms随机抽取设置过期时间的key，检查是否过期。（避免过多数据的轮询耗时）
惰性删除，key查询时再判断是否过期，过期了再进行确认，过期则删除。
LRU内存淘汰策略，进行过期key（最近最少使用）的内存释放。可以用LinkedHashMap自己手写一个.
6.redis如何支持高并发
单机redis的并发在几万(高性能的主机可以支撑到10w+)，一般会采用主从架构+读写分离，一般是一主多从，主负责写并将数据同步复制到其他的slave节点上去，从节点负责读，所有的读请求都要走从节点，这样可以支撑起一个水平扩展的读高并发架构。
7、redis replication主从复制的核心原理
当启动一个salve节点时，它首先会发送一个psync的命令给master节点，如果是第一次连接，就会触发全量同步，master会异步的生成一份rdb快照文件（无磁盘化复制，内存中创建不会落盘），同时还会将这段时间从客户端收到的所有写命令缓存在内存中。rdb生辰后，发送给slave节点，slave写入磁盘再加载到内存中，然后master会讲内存中缓存的写命令也同步给slave，slave也会去同步这部分增量数据。
master和slave都会维护一个offset，不仅仅用于全量复制，让master和slave都知道相互之间一个数据一致性情况。
8、断点续传
全量主从复制支持断点续传，master节点在内存中维护了backlog，记录了一个同步的偏移量，如果断线重连以后，会从backlog中记录的偏移量位置开始进行同步，如果没有找到offset就会触发全量同步。
9、redis的高可用机制
redis的高可用是通过哨兵机制来保障的。类似zk，可以实现集群监控、消息通知、故障转移和配置中心的作用。哨兵本身也是分布式的：
故障转移，判断一个master挂了，需要多数哨兵同意才行，需要重新选举。
哨兵本身也是集群模式，部分节点挂了，还是能工作，同时为了方便选举哨兵的节点数最好设置成奇数个。
a.社区版本推出的原生高可用解决方案
Redis哨兵架构
当故障转移的工作流程就是，当Master宕机的时候，Sentinel会选举出新的Master，并根据Sentinel中client-reconfig-script脚本配置的内容，去动态修改VIP(虚拟IP)，将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可！
缺陷: (1)主从切换的过程中会丢数据 (2)Redis只能单点写，不能水平扩容
b.开源Proxy+Replication+Sentinel
前端使用Twemproxy+KeepAlived做代理，将其后端的多台Redis实例分片进行统一管理与分配
HA proxy+KeepLive
每一个分片节点的Slave都是Master的副本且只读；Sentinel持续不断的监控每个分片节点的Master，当Master出现故障且不可用状态时，Sentinel会通知/启动自动故障转移等动作；Sentinel 可以在发生故障转移动作后触发相应脚本（通过 client-reconfig-script 参数配置 ），脚本获取到最新的Master来修改Twemproxy配置。
缺陷: (1)部署结构超级复杂 (2)可扩展性差，进行扩缩容需要手动干预 (3)运维不方便
10、redis哨兵的选举算法
判断master失败的两种状态：
sdown，主观宕机，一个哨兵ping不同一个master，超过一定时刻就主观认为sdown了。
odown，客观宕机，如果有quorum数量的哨兵都认为master宕机了，就客观认为master宕机了。
如果一个master被认为odown，且majority哨兵都允许了准备切换，选举一个slave为一个master。
slave priority越低，选举为master的优先级越高
slave priority相同，replica offset越靠后，优先级越高（从master同步数据越多）
上面都相同，就选择一个run id较小的slave。
source: 史上最全 Redis 高可用解决方案总结
11、redis挂掉以后的数据恢复（持久化机制）
redis持久化主要功能就是为了保证灾难恢复，数据恢复。可以归类于高可用。关于持久化的AOF和RDB，二者区别介绍如下：
RDB持久化是通过将某个时间点Redis服务器存储的数据保存到RDB文件中来实现持久化的。AOF持久化是通过将Redis服务器执行的所有写命令保存到AOF文件中来实现持久化的。
RDB持久化记录的是结果，AOF持久化记录的是过程，所以AOF持久化生成的AOF文件会有体积越来越大的问题，Redis提供了AOF重写功能来减小AOF文件体积。
AOF持久化的安全性要比RDB持久化的安全性高，即如果发生机器故障，AOF持久化要比RDB持久化丢失的数据要少。
如果Redis服务器开启了AOF持久化功能（默认是关闭的），Redis服务器在启动时会使用AOF文件来还原数据，如果Redis服务器没有开启AOF持久化功能，Redis服务器在启动时会使用RDB文件来还原数据，所以AOF文件的优先级比RDB文件的优先级高。
12、RDB中save和Bgsave的区别？
Redis提供了2个命令来创建RDB文件，一个是SAVE，另一个是BGSAVE。
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求
BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以推荐使用BGSAVE命令。
13、RDB和AOF如何选择？
可以综合使用，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做冷备，在AOF或者磁盘损坏不可用的情况下，还有RDB作为快速恢复的手段。
source: 阿里二面：熟悉Redis？讲讲你理解的Redis的持久化机制(RDB、AOF)
14、Redis的架构选择
如果数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了
主从+replication，数据量一般，满足高并发，一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了
redis cluster，主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster
15、Redis Cluster
客户端与Redis节点直连,不需要中间Proxy层，直接连接任意一个Master节点；根据公式HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作
Redis cluster架构
具有如下优点: (1)无需Sentinel哨兵监控，如果Master挂了，Redis Cluster内部自动将Slave切换Master (2)可以进行水平扩容 (3)支持自动化迁移，当出现某个Slave宕机了，那么就只有Master了，这时候的高可用性就无法很好的保证了，万一Master也宕机了，咋办呢？ 针对这种情况，如果说其他Master有多余的Slave ，集群自动把多余的Slave迁移到没有Slave的Master 中。
缺点: (1)批量操作是个坑(mget) (2)资源隔离性较差，容易出现相互影响的情况。
source: 那些年用过的Redis集群架构（含面试解析）
16、Redis cluster的高可用性
整个流程跟哨兵相比，非常类似，所以说，redis cluster功能强大，直接集成了replication和sentinal的功能。不过在通信协议上整个采用了gossip协议，跟集中式的哨兵协议不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的。其他在判断节点是否当季、节点过滤和选举上的思路都是少数服从多少的思路，基本一致。
集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到; 不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的节点有压力。
gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后。
17、数据分区的选择
a.哈希取余分区
哈希取余分区思路非常简单：计算 key 的 hash 值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。 该方案最大的问题是，当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要重新计算映射关系，引发大规模数据迁移。
b.一致性哈希分区
一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环，如下图所示，范围为 0-2^32-1。对于每个数据，根据 key 计算 hash 值，确定数据在环上的位置，然后从此位置沿环顺时针行走，找到的第一台服务器就是其应该映射到的服务器。
**与哈希取余分区相比，一致性哈希分区将增减节点的影响限制在相邻节点。**一致性哈希分区的主要问题在于，当节点数量较少时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡；同时也需要保证节点能够均匀分布在哈希环，使得缓存数据能够均匀分布。
c.带虚拟节点的一致性哈希分区(哈希槽)
该方案在一致性哈希分区的基础上，引入了虚拟节点的概念。Redis 集群使用的便是该方案，其中的虚拟节点称为槽（slot）。槽是介于数据和实际节点之间的虚拟概念；每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。引入槽以后，数据的映射关系由数据 hash->实际节点，变成了数据 hash->槽->实际节点。在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响很小。槽的数量一般远小于 2^32，远大于实际节点的数量；在 Redis 集群中，槽的数量为 16384。
数据映射
Redis 集群将数据映射到实际节点的过程：
Redis 对数据的特征值（一般是key）计算哈希值，使用的算法是 CRC16。
根据哈希值，计算数据属于哪个槽。
根据槽与节点的映射关系，计算数据属于哪个节点。
source: 深入学习 Redis 集群搭建方案及实现原理
18、缓存雪崩
故障原因：redis挂了 事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃 事中：本地cache缓存 + hystrix限流&降级，避免MySQL被打死 事后：redis持久化，快速恢复缓存数据
故障原因2：缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效 将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
19、缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。解决办法有两个：
查询数据库不存在，则在redis中存一份Null值，避免访问Mysql
最后
金三银四到了，送上一个小福利！
大。解决办法有两个：
查询数据库不存在，则在redis中存一份Null值，避免访问Mysql
最后
金三银四到了，送上一个小福利！
[外链图片转存中…(img-cPNvMpJc-1715495583430)]
[外链图片转存中…(img-3AFnRDBM-1715495583431)]
[外链图片转存中…(img-KJD0UBfl-1715495583431)]
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
