Redis 的作用及详细分析

网上查询总结了一下Redis相关的信息记录一下，有问题的地方，望多加指正，我们共同学习。

什么是Redis
Redis是一款内存高速缓存数据库。Redis全称为：Remote Dictionary Server （远程数据服务），使用C语言编写，Redis是一个key-value存储系统（键值存储系统），支持丰富的数据类型，如：String、list、set、zset、hash。
Redis是一种支持key-value等多种数据结构的存储系统。可用于缓存，事件发布或订阅，高速队列等场景。使用C语言编写，支持网络，提供字符串，哈希，列表，队列，集合结构直接存取，基于内存，可持久化。

1.使用redis缓存的好处
提高并发量，不需要每次都访问数据库，提高并发量。提高性能，redis运行在内
存中，内存的执行效率，远远超过数据库。
2.Redis的key和value的存储大小有限制吗？
Redis的key和value的存储大小都是有限制的，都是512M。

3.redis存储什么数据类型
(1)字符串（String）用于存储文本或二进制数据。
(2)字符串列表（lists）类似于链表，可以在列表两端进行添加、删除操作，常用于实现消息队列或简单的日志系统。
(3)字符串集合（sets）无序的字符串集合，支持快速添加、删除和查找操作。
(4)有序字符串集合（sorted sets）类似于集合，但每个成员都关联一个分数，通过分数进行排序。
(5)哈希（hash）类似于关联数组，存储键值对的集合。
(6)位图（Bitmap）：用于处理位数据，例如记录用户在线状态等。

4.使用redis缓存的弊端及解决方案

缓存穿透，大量的请求访问，查询的是数据库中不存在的数据，就会在缓存中无法命中，直接去访问数据库，数据库中也查询不到,自然无法将结果写入缓存，下一秒又有大量请求查询不存在的数据，导致数据库最终挂掉(要么系统出bug,要么黑客恶意攻击)
解决方案:
在数据库中没有查询到的数据，存储一个特定值到缓存中，这样下次恶意访问就可以去缓存中查询到数据，不会访问到数据库.注意的是这些特定的key，需要设置过期时间，避免黑客攻击时，大量的无效key把redis存满。
缓存雪崩，大规模的key失效，大量的请求通过key访问到数据库，导致数据库直接崩溃，然后系统直接瘫痪.
解决方案:
事前: 保证redis集群的高可用性，redis cluster，主从机制;
事中: hystrix（熔断器）限流+降级，避免数据库被打死.高并发的访问量走hystrix限流组件，让访问量保持在数据库最大负载范围内,保证数据库不被打死,系统可以继续使用.剩余的请求走降级组件,返回一些默认的值或者是友情提示等
事后: redis持久化机制，尽快回复缓存集群，一旦重启，自动从磁盘上加载数据,回复内存中的数据
缓存与数据库不一致，修改数据时，数据库和缓存数据不一致。最初级的缓存不一致:
出现场景：
先修改数据库，再删除缓存,如果修改缓存失败,就会导致数据库中式新数据,缓存中是旧数据,数据不一致解决思路:
先删除缓存，再修改数据库,如果删除缓存成功，修改数据库失败，那么数据库中是旧数据，缓存中是空的，读的时候缓存中没有，去数据库中读旧数据，然后更新到缓存中去
高并发场景下数据库与缓存的数据不一致:
出现场景：
读写并发请求，导致数据库和缓存中的数据不一致，在写请求删除缓存，修改数据库库存还未成功时，查询库存的请求就发来,先去缓存中查询，发现是空，然后去数据库中查，然后将结果放入缓存中，然后修改库存的操作成功，导致数据库中是新数据，缓存中是旧数据
解决思路:
相同的商品id,进行哈希取值,再加上对内存队列的数量进行取模,每个商品都可以路由到某一个内存队列中,然后将去请求和写请求串行化,这样就可保证一定不会出现不一致的情况,但是会导致系统的吞吐量会大幅降低
缓存并发竞争，同一时间，多个线程来执行，操作同一个key。解决思路:
方式一：分布式锁,（zookeeper分布式锁），确保同一时间,只能由一个系统实例在操作某个key,别的实例不被允许读和写
方式二：乐观锁，每次要写之前,先判断这个value的时间戳是否比缓存里的更新,如果新就允许写.

5.为什么redis是单线程的但是还可以支撑高并发?

redis线程模型:redis里有个处理器叫做文件事件处理器(file event handler),这个文件事件处理器是单线程的执行的,redis所以是单线程的模型。
执行流程:
redis启动初始化时,redis会将连接应答器和AE_READABLE事件关联
客户端跟redis连接,会在serverSocket产生一个AE_READABLE事件,然后由IO多路复用程序监听到事件,将serverSocket压入队列,然后连接应答处理器来处理事件,和客户端建立连接,创建对应的socket,同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来
客户端向redis发起请求时,首先会在socket中产生一个AE_READABLE事件,然后被监听,被压入队列,然后由对应的命令请求处理器来处理
redis准备好给客户端响应数据之后,就会将socket的AE_WRITABLE命令跟回复处理器关联起来,当客户端准备好读取响应数据时,就会在socket上产生一个AE_WRITABLE事件,会由对应的命令回复处理器来处理
命令回复处理器处理完之后,就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系

6.Redis为什么效率高?

核心是基于非阻塞的IO多路复用机制,由监听程序轮询等待的事件,然后压入队列,可以达到一个线程同时处理多个io请求的目的
纯内存操作
单线程避免了多线程的频繁切换问题

7.Redis由哪些数据类型,分别在哪些场景下使用?

String,存储基本的类型
List,有序列表,比如之前项目中的广告缓存,用的就是list集合进行缓存的,它可以用于比如存储粉丝列表,文章的评论列表等等
Set,无序列表,它最主要的特点就是去重,比如微博上查询两个明星的共同粉丝,就可以用set进行去重
SortSet,它主要是在set的基础上加上了排序功能
Hash,类似map的集合,一般可以用来存储对象,我们系统中的购物车对象就是以hash类型存储在redis中,key就是用户的id,value就是购物车对象

8.Redis过期策略

定期删除配合惰性删除
定期删除,指的是redis默认每个100ms就抽取一些设置了过期事件的key,检查是否过期,如果过期就删除.如果太多的key都设置了过期时间,每隔几百毫秒,就全部检查删除,cpu的负载会很高.实际上redis是每隔100ms随机抽取一些key来检查和删除.
惰性删除,就是当你获取key时,redis就会检查一下,如果key过期了,就删除,不会返回,如果没过期就返回
因为redis的过期策略会导致你设置了过期key,过期了很多过期key没有被删除,还堆积在内存中,此时就要设置内存淘汰机制来解决了
内存淘汰机制
noevication:当内存不足以容纳写入新数据时,新写入操作就会报错
allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的key
allkeys-random:在键空间中,随机移除某个key
volatile-lru:在设置了过期时间的键空间中,移除最近最少使用的key
volatile-random:在设置了过期时间的键空间中,随机移除某个key
volatile-ttl:在设置了过期时间的键空间中,由更早过期时间的key优先移除

9.怎样做redis支撑高并发(读多写少用缓存,读少写多用队列)

搭建redis集群,做成主从架构,一主多从,通过redis replication机制实现读写分离,主负责写,并且将数据同步复制到其他slave（从）节点上,从节点负责读,所有的读请求走从节点.好处,可支持水平扩容的读高并发架构

redis replication的核心机制

redis采用异步方式复制数据都slave节点上,slave节点会周期性的确认自己每次复制的数据量
一个master（主）节点可以配置多了slave节点
slave节点也可以连接其他slave节点
slave节点做复制的时候,也不会阻塞对自己的查询操作,它会用旧数据向外提供服务;复制完后,它就删除旧数据,加载新数据,这个时候向外停止服务(毫秒级别)
slave节点主要用来横向扩容,做读写分离,提高吞吐量

Master（主节点）持久化对于主从架构的安全保障的意义

如果仅仅用slave节点作为master节点的数据热备份,当master节点宕机后重启,数据清空,本地没有数据可以恢复,它会任为自己的数据就是空的,然后同步到slave节点上,就会导致数据百分百丢失
其次,如果开启了哨兵机制,在master节点挂掉之后,会迅速推选出一个slave节点去做master节点,但是当哨兵还没检测到master节点挂掉,master节点就自动重启了,还是会出现上面的情况

redis主从架构的核心原理

当启动一个slave节点时,会发送一个PSYNC命令给master节点
如果这个slave节点第一次连接master节点,就会出发full resynchronization
开始full resynchronization的时候,master会开启一个后台线程,开始生成一份rdb快照文件,同时还还会继续接收客户端的写命令,存在内存中.RDB文件生成完毕后,master会将这个RDB发送给slave,slave先将RDB写入本地自盘,然后再加载到内存.然后master会将内存中缓存的写命令发送给slave,slave同步这些数据

redis的高可用

不可用: 虽然主从架构,读写分离可以保证缓存应对高并发场景,但是如果master节点挂掉,整个缓存架构就会挂掉,大量的流量涌入数据库,超过数据库的最大承载压力,数据库挂掉,整个系统就会挂掉不可用
高可用: 故障转移,主备切换,当master故障时,自动检测(通过sentinal node 哨兵),将某个slave自动切换成master的过程交主备切换.这个机制实现了redis主从架构下的高可用性

10.redis的持久化
如果没有持久化,遇到灾难性故障时,就会丢失所有数据，如果开启持久化到磁盘,定期备份到云服务上,就能保证遇到灾难性故障,就不会丢失全部数据

RDB

当redis需要做持久化时,redis会fork一个子进程,将数据写到磁盘写上一个临时RDB文件中,当子进程完成写临时文件后,将原来的RDB换掉
优势:
适合做冷备份,在最坏的情况下,恢复数据要比AOF快
对redis对外提供读写服务,影响服务非常小
RDB数据快照文件更少

AOF

可以做到更精细的持久化,redis每执行一个修改数据的命令,都会将它添加到os cache中,一般会每个一秒执行一次fsync操作,保证将os cache中的数据写入磁盘中AOF日志文件中,AOF日志文件以append-only模式写入,文件不容易破损,在AOF日志过大时,就会出现后台重写
优势:
AOF可以更好的保护数据不丢失,丢失的数据更少
AOF日志文件以append-only模式写入,没有磁盘寻址的开销,写入性能非常高
AOF日志过大时,也不会影响客户端的读写

RDB和AOF到底如何抉择

综合使用两种持久化机制,用AOF保证数据不丢失,作为数据恢复的第一选择,用RDB来做不同程度的冷备份,在AOF文件丢失或者损坏不可用的情况下,用RDB来进行快速的数据恢复

11.redis怎么设置缓存大小
打开redis配置文件

示例：maxmemory 100mb
单位：mb,gb。
默认为0，没有指定最大缓存，如果有新的数据添加，超过最大内存，则会使redis崩溃，所以一点要设置。
设置maxmemory之后，配合的要设置缓存数据回收策略, 可以通过设置LRU算法来删除部分key，释放空间(LRU是Least Recently Used 近期最少使用算法。)。
就可以修改缓存大小为16gb.

12.redis集群主从数据如何同步
答1:
Redis主从同步有两种方式：全同步和部分同步。主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。

答2:
(1)全量同步：
Redis全量复制一般发生在S-ave初始化阶段，这时S-ave需要将Master上的所有数据都复制一份。具体步骤如下：
　　1）从服务器连接主服务器，发送SYNC命令；
　　2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
　　3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
　　4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
　　5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
　　6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
　　
(2)增量同步：
Redis增量复制是指S-ave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令

(3)Redis主从同步策略：
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，s-ave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

13.Redis缓存穿透和redis雪崩处理
(1)缓存穿透
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，应该去后端系统查询（比如数据库）。如果key对应的value不存在，并且对key并发请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

解决方案

对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
也可以采用一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

(2)缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统（比如数据库）带来很大的压力。
缓存雪崩是指在我们设置缓存是采用了相同的过期时间，导致缓存在某一时期同时失效，请求全部转发到DB，DB瞬间压力过大雪崩。

解决方案：

把缓存时间分散开，比如在原来的时间基础上增加一个随机值，比如1~5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

14.发布与订阅
Redis的发布与订阅（Pub/Sub）是一种消息通信模式，允许客户端订阅频道（Channel），并在发布者向频道发送消息时接收这些消息。这种模式在Redis中被广泛用于实现事件通知、实时数据更新、聊天应用等场景。
(1)Redis的发布与订阅是一种解耦的消息通信模式，其核心思想是：

发布者（Publisher）：负责将消息发送到指定的频道（Channel）。
订阅者（Subscriber）：负责订阅特定的频道，以便接收消息。
这种模式类似于广播电台，订阅者可以同时监听多个频道，而发布者则可以在任何频道上发布消息，无需知道订阅者的具体信息。这种模式使得系统中的生产者和消费者之间不再直接耦合，提高了系统的灵活性和可扩展性

(2)Redis发布与订阅的实现方式

Redis的发布与订阅机制是基于消息代理模式实现的。其核心数据结构包括：
server.pubsub_channels：Redis服务器内部维护的一个哈希表，用于记录每个频道的订阅者列表。
链表结构：每个频道对应的订阅者列表以链表形式存储，便于快速遍历和通知。

(3)Redis发布与订阅的命令
Redis提供了以下命令用于实现发布与订阅功能：

命令	功能
SUBSCRIBE	订阅一个或多个频道
UNSUBSCRIBE	取消对某个频道的订阅
PSUBSCRIBE	订阅符合特定模式的频道
PUNSUBSCRIBE	取消对某个模式的订阅
PUBLISH	向指定频道发送消息

(4)Redis发布与订阅的应用场景
Redis发布与订阅模式在以下场景中非常有用：

实时聊天应用：用户可以通过订阅频道接收消息，实现一对多的通信。
事件通知：例如，当某个资源状态发生变化时，通知所有订阅该事件的客户端。
实时数据更新：例如，股票价格、天气信息等实时数据的推送。
消息队列：在分布式系统中，作为轻量级的消息队列使用

(5)Redis发布与订阅的注意事项

消息丢失：如果订阅者在消息发布时已经断开连接，Redis不会存储消息，因此消息可能会丢失。为了解决这个问题，可以结合Redis的持久化机制或使用其他消息队列系统。
性能问题：大量订阅者和高频消息可能会导致性能瓶颈，需要合理设计频道和订阅策略。
网络稳定性：订阅者必须在线才能接收到消息，否则消息将无法送达