1.Redis 支持哪几种数据类型
String、List、Set、Sorted Set、hashes bitmap hyperloglog
2.Redis 有哪些适合的场景
会话缓存(Session Cache)
最常用的一种使用 Redis 的情景是会话缓存(session cache)。用 Redis 缓存会话比其他存
储(如 Memcached)的优势在于:Redis 提供持久化。当维护一个不是严格要求一致性的缓存时,如果用户的购物车信息全部丢失,大部分人都会不高兴的,现在,他们还会这样吗?
幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用 Redis 来缓存会话的文
档。甚至广为人知的商业平台 Magento 也提供 Redis 的插件。
• 全页缓存(FPC)
除基本的会话 token 之外,Redis 还提供很简便的 FPC 平台。回到一致性问题,即使重启了Redis 实例,因为有磁盘的持久化,用户也不会看到页面加载速度的下降,这是一个极大改进,类似 PHP 本地 FPC。再次以 Magento 为例,Magento 提供一个插件来使用 Redis 作为全页缓存后端。此外,对 WordPress 的用户来说,Pantheon 有一个非常好的插件 wp-redis,这个插件能帮助你以最快速度加载你曾浏览过的页面。
• 队列
Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作,这使得 Redis 能作为一个
很好的消息队列平台来使用。Redis 作为队列使用的操作,就类似于本地程序语言(如
Python)对 list 的 push/pop 操作。
如果你快速的在 Google 中搜索“Redis queues”,你马上就能找到大量的开源项目,这些项目的目的就是利用 Redis 创建非常好的后端工具,以满足各种队列需求。例如,Celery 有一个后台就是使用 Redis 作为 broker,你可以从这里去查看。
• 排行榜/计数器
Redis 在内存中对数字进行递增或递减的操作实现的非常好。集合(Set)和有序集合
(Sorted Set)也使得我们在执行这些操作的时候变的非常简单,Redis 只是正好提供了这
两种数据结构。所以,我们要从排序集合中获取到排名最靠前的 10 个用户–我们称之为“user_scores”,我们只需要像下面一样执行即可:当然,这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数,你
需要这样执行:
ZRANGE user_scores 0 10 WITHSCORES
Agora Games 就是一个很好的例子,用 Ruby 实现的,它的排行榜就是使用 Redis 来存储数据的,你可以在这里看到。
• 发布/订阅
最后(但肯定不是最不重要的)是 Redis 的发布/订阅功能。发布/订阅的使用场景确实非常
多。我已看见人们在社交网络连接中使用,还可作为基于发布/订阅的脚本触发器,甚至用
Redis 的发布/订阅功能来建立聊天系统!
活跃用户数统计
用户日活、月活、留存率等均可以用redis位数组来存储,还是以每天的日期作为key,用户活跃了就写入offset为用户id的位值1。
同理月活也是如此。
用户是否在线以及总在线人数统计
同样是使用一个位数组,用户的id映射偏移量,在线标识为1,下线标识为0。即可实现用户上下线查询和总在线人数的统计
APP内用户的全局消息提示小红点
现在大多数的APP里都有站内信的功能,当有消息的时候,则提示一个小红点,代表用户有新的消息。
点赞/取消点赞:
假设用户ID为100,对照片ID为100的照片进行点赞。首先根据照片ID生成数据存储的redis key,比如生成策略是like_photo:{photo_id},用户ID为1000的用户点赞只需将like_photo:100的第1000位设置为1即可(取消置为0)。
redis setbit操作的时间复杂度为O(1),所以这种点赞方式十分高效。
当前是否点赞:
用户打开图片的时候需要查询当前是否点赞过该照片,查询是否点赞可以通过redis getbit操作实现。
查询点赞总次数:
比如需要显示照片ID为1000的照片的获赞总次数,只需对like_photo:1000进行位图计数操作即可:bitcount。时间复杂度为O(N)。个人以为可以在照片表中加一个字段记录获赞总次数,这样就不用循环统计各个照片的获赞次数。
redis还提供了bittop等其他一些API,可以实现一些有趣的事。
3.怎么理解 Redis 事务?
事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。
4.Redis 事务相关的命令有哪几个?
MULTI、EXEC、DISCARD、WATCH
5.Redis集群
首先下载linux版本的redis安装包,解压,找到redis的conf文件,配置端口号,配置要开启的数据库,看有几个库,然后再配置redis开启后日志存储的位置,数据的存储位置,支持后台运行模式,在配置下开启集群模式,完成之后,保存,复制几分,然后启动,多启动几台单台服务,一般都是一组一组,我们一般都配置六台,总共三组,所有单台服务启动完毕后,通过redis-trib(踹 bu).rb create --replicas(re pu li kai si) 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
Redis 集群
Redis 在3.0版本前只支持单实例模式,虽然支持主从模式、哨兵模式部署来解决单点故障
Redis 在 3.0 版本以后就推出了集群模式。
Redis 集群搭建规划,由于集群至少需要6个节点(3主3从模式)
我们计划集群中 Redis 节点的端口号为 9001-9006 ,端口号即集群下各实例文件夹。数据存放在 端口号/data 文件夹中。
2.复制执行脚本
在 /usr/local/redis-cluster 下创建 bin 文件夹,用来存放集群运行脚本,并把安装好的 Redis 的 src 路径下的运行脚本拷贝
3.复制一个新 Redis 实例
我们现在从已安装好的 Redis 中复制一个新的实例到 9001 文件夹,并修改 redis.conf 配置。修改 redis.conf 配置和单点唯一区别是下图部分,其余还是常规的这几项:
port 9001(每个节点的端口号)
daemonize yes bind 192.168.119.131(绑定当前机器 IP)
dir /usr/local/redis-cluster/9001/data/(数据文件存放位置)
pidfile /var/run/redis_9001.pid(pid 9001和port要对应)
cluster-enabled yes(启动集群模式)
cluster-config-file nodes9001.conf(9001和port要对应)
cluster-node-timeout 15000
appendonly yes
4. 再复制出五个新 Redis 实例
我们已经完成了一个节点了,其实接下来就是机械化的再完成另外五个节点,其实可以这么做:把 9001 实例 复制到另外五个文件夹中,唯一要修改的就是 redis.conf 中的所有和端口的相关的信息即可,其实就那么四个位置。开始操作,看图:
5. 调用 ruby 命令来进行创建集群,--replicas 1 表示主从复制比例为 1:1,即一个主节点对应一个从节点;然后,默认给我们分配好了每个主节点和对应从节点服务,以及 solt 的大小,因为在 Redis 集群中有且仅有 16383 个 solt ,默认情况会给我们平均分配,当然你可以指定,后续的增减节点也可以重新分配
6.redis持久化
redis是一个内存数据库,数据保存在内存中,但是我们都知道内存的数据变化是很快的,也容易发生丢失。幸好Redis还为我们提供了持久化的机制,分别是RDB(Redis DataBase)和AOF(Append Only File)。
持久化流程
既然redis的数据可以保存在磁盘上,那么这个流程是什么样的呢?
要有下面五个过程:
(1)客户端向服务端发送写操作(数据在客户端的内存中)。
(2)数据库服务端接收到写请求的数据(数据在服务端的内存中)。
(3)服务端调用write这个系统调用,将数据往磁盘上写(数据在系统内存的缓冲区中)。
(4)操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
(5)磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)
RDB机制
既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存,那么就应该有一种触发机制,是实现这个过程。对于RDB来说,提供了三种机制:save、bgsave、自动化。
RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢,你可以理解成把当前时刻的数据拍成一张照片保存下来。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式,这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
RDB 的优势和劣势
①、优势
(1)RDB文件紧凑,全量备份,非常适合用于进行备份和灾难恢复。
(2)生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作。
(3)RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
②、劣势
RDB快照是一次全量备份,存储的是内存数据的二进制序列化形式,存储上非常紧凑。当进行快照持久化时,会开启一个子进程专门负责快照持久化,子进程会拥有父进程的内存数据,父进程修改内存子进程不会反应出来,所以在快照持久化期间修改的数据不会被保存,可能丢失数据。
AOF机制
全量备份总是耗时的,有时候我们提供一种更加高效的方式AOF,工作机制很简单,redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
优点
(1)AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据。(2)AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。
(3)AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。
(4)AOF日志文件的命令通过非常可读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据,只要这个时候后台rewrite还没有发生,那么就可以立即拷贝AOF文件,将最后一条flushall命令给删了,然后再将该AOF文件放回去,就可以通过恢复机制,自动恢复所有数据
缺点
(1)对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大
(2)AOF开启后,支持的写QPS会比RDB支持的写QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fsync,性能也还是很高的
(3)以前AOF发生过bug,就是通过AOF记录的日志,进行数据恢复的时候,没有恢复一模一样的数据出来
7.Redis 缓存穿透 + 缓存雪崩 + 缓存击穿的原因和解决方案
7.1缓存穿透
缓存穿透是指查询一个根本不存在的数据,缓存层和持久层都不会命中。在日常工作中出于容错的考虑,如果从持久层查不到数据则不写入缓存层,缓存穿透将导致不存在的数据每次请求都要到持久层去查询,失去了缓存保护后端持久的意义
缓存穿透示意图:
缓存穿透问题可能会使后端存储负载加大,由于很多后端持久层不具备高并发性,甚至可能造成后端存储宕机。通常可以在程序中统计总调用数、缓存层命中数、如果同一个Key的缓存命中率很低,可能就是出现了缓存穿透问题。
造成缓存穿透的基本原因有两个。第一,自身业务代码或者数据出现问题(例如:set 和 get 的key不一致),第二,一些恶意攻击、爬虫等造成大量空命中(爬取线上商城商品数据,超大循环递增商品的ID)
解决方案:
1. 缓存空对象
缓存空对象:是指在持久层没有命中的情况下,对key进行set (key,null)
缓存空对象会有两个问题:第一,value为null 不代表不占用内存空间,空值做了缓存,意味着缓存层中存了更多的键,需要更多的内存空间,比较有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。第二,缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。例如过期时间设置为5分钟,如果此时存储层添加了这个数据,那此段时间就会出现缓存层和存储层数据的不一致,此时可以利用消息系统或者其他方式清除掉缓存层中的空对象
2. 布隆过滤器拦截
在访问缓存层和存储层之前,将存在的key用布隆过滤器提前保存起来,做第一层拦截,当收到一个对key请求时先用布隆过滤器验证是key否存在,如果存在在进入缓存层、存储层。可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景,代码维护较为复杂,但是缓存空间占用少。
布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。
算法描述:
初始状态时,BloomFilter是一个长度为m的位数组,每一位都置为0。
添加元素x时,x使用k个hash函数得到k个hash值,对m取余,对应的bit位设置为1。
判断y是否属于这个集合,对y使用k个哈希函数得到k个哈希值,对m取余,所有对应的位置都是1,则认为y属于该集合(哈希冲突,可能存在误判),否则就认为y不属于该集合。可以通过增加哈希函数和增加二进制位数组的长度来降低错报率。
错报原因:
一个key映射数组上多位,一位会被多个key使用,也就是多对多的关系。如果一个key映射的所有位值为1,就判断为存在。但是可能会出现key1 和 key2 同时映射到下标为100的位,key1不存在,key2存在,这种情况下会发生错误率
方案对比:
7.2缓存雪崩
由于缓存层承载着大量请求,有效地保护了存储层,但是如果缓存层由于某些原因不可用(宕机)或者大量缓存由于超时时间相同在同一时间段失效(大批key失效/热点数据失效),大量请求直接到达存储层,存储层压力过大导致系统雪崩。
解决方案:
可以把缓存层设计成高可用的,即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务。利用sentinel或cluster实现。
采用多级缓存,本地进程作为一级缓存,redis作为二级缓存,不同级别的缓存设置的超时时间不同,即使某级缓存过期了,也有其他级别缓存兜底
缓存的过期时间用随机值,尽量让不同的key的过期时间不同(例如:定时任务新建大批量key,设置的过期时间相同)
7.3缓存击穿
缓存击穿问题也叫热点Key问题,就是一个被高并发访问并且缓存重建业务较复杂(意味着对数据库压力相对较大)的key突然失效了(可以理解为redis的缓存突然无了),无数的请求访问会在瞬间给数据库带来巨大的冲击。
当前key是一个热点key(例如一个秒杀活动),并发量非常大。
重建缓存不能在短时间完成,可能是一个复杂计算,例如复杂的SQL、多次IO、多个依赖等。
在缓存失效的瞬间,有大量线程来重建缓存,造成后端负载加大,甚至可能会让应用崩溃。
分布式互斥锁
只允许一个线程重建缓存,其他线程等待重建缓存的线程执行完,重新从缓存获取数据即可。set(key,value,timeout)
2. 永不过期
- 从缓存层面来看,确实没有设置过期时间,所以不会出现热点key过期后产生的问题,也就是“物理”不过期。
- 从功能层面来看,为每个value设置一个逻辑过期时间,当发现超过逻辑过期时间后,会使用单独的线程去更新缓存
2种方案对比:
分布式互斥锁:这种方案思路比较简单,但是存在一定的隐患,如果在查询数据库 和 重建缓存(key失效后进行了大量的计算)时间过长,也可能会存在死锁和线程池阻塞的风险,高并发情景下吞吐量会大大降低!但是这种方法能够较好地降低后端存储负载,并在一致性上做得比较好。
“永远不过期”:这种方案由于没有设置真正的过期时间,实际上已经不存在热点key产生的一系列危害,但是会存在数据不一致的情况,同时代码复杂度会增大。
- Mysql和Redis的双写一致性
8.1场景:
双写一致性指的是当我们更新了数据库的数据之后redis中的数据 也要同步去更新。使用redis读取数据的流程,当用户访问数据的时候,会先从缓存中读取数据,如果命中缓存的话,那么直接把缓存中的数据返回给用户,如果缓存中没有数据的话,先查询数据库把查询到的数据保存到缓存中,然后返回给用户。
8.2保证双写一致性的策略
1、先更新缓存,再更新数据库
2、先更新数据库,再更新缓存
3、先删除缓存,再更新数据库
4、先更新数据库,再删除缓存
8.3.四种策略的优缺点
1、先更新缓存,再更新数据库
问题很明显如果更新缓存成功,更新数据库失败,就会造成缓存的脏数据
2、先更新数据库,再更新缓存
如果再高并发的情况下,可能会存在如下的情况,线程A更新了数据库,如果由于网络或者其他的原因,线程A还没来得及更新缓存,这时候有一个线程B更新了数据库,更新了缓存,这时候线程A才更新缓存,这时候就会导致线程B对缓存的更新丢失了,像事务丢失的情况
3、先删除缓存,再更新数据库
这种策略可能已经避免掉了,策略2中缓存丢失的情况,但是再高并发的情况下,也会有不一致的情况,比如线程A做写操作,首先删除缓存然后准备更新数据库,这时候,线程B执行了写操作,没有命中缓存,然后查询数据库,这时候读取的是旧值,并把查询到的旧值保存到缓存中,接着线程A完成了数据库的更新,这时候数据库和缓存又出现了不一致的情况,解决方案:我们只要再线程A,完成数据库的更新之后,稍作延迟再删除一次缓存,也叫作延迟双删。这里的延迟时间一定要大于业务的一次读操作的时间。
4、先更新数据库,再删除缓存
再高并发的情况下,也会有不一致的情况,比如线程A做读取数据的操作,正准备写入缓存的时候,线程B更新了数据库,然后执行了删除缓存的操作,这时候线程A才把旧值写入到缓存中,虽然这种情况出现的概率比较低,因为写操作的时候要大于一次读操作的时间的。解决方案:延迟双删,延时双删还是有问题的,如果删除缓存失败怎么办,当然是再次删除,不断的循环删除。删除失败后我们可以将要删除的key放入到队列中,然后尝试重复删除,直到删除成功。
- Redis有哪几种模式
9.1.主从模式
1.主从模式是最为简单的redis集群模式
2.主要工作模式是主从复制。主数据库可以执行读写功能,而从数据库只能执行读功能。主数据库数据发生变化,会自动同步到从数据库。
3.主数据库为master,从数据库为slave,一个master可以有多个slave,一个slave只能有一个master,slave挂了,重新启动会从master同步数据
master挂了,服务器只能进行读功能,不能执行写功能,直到master重新启动同步数据后,才能提供写服务。
9.2.哨兵模式
1.可以解决主从模式的弊端:master挂掉之后不能提供写功能。
2.哨兵模式是建立在主从模式的
3.当master挂掉之后,会自动从slave中选一个作为master。若master重新启动,master则会转化为现有的master下的一个slave
4.当slave切换时,会通过发布订阅方式,将slave所对应的master更改
5.因为哨兵也是一个进程,所以也有挂掉的可能,需要配置多个哨兵互相监督。一个哨兵可以监督多个主从数据库。同样,一个主从数据库可以被多个哨兵监督。
9.3.集群Cluster模式
1.redis cluster是Redis的分布式解决方案,在3.0版本推出后有效地解决了redis分布式方面的需求,自动将数据进行分片,每个master上放一部分数据提供内置的高可用支持,部分master不可用时,还是可以继续工作的
2.支撑N个redis master node,每个master node都可以挂载多个slave node
3.高可用,因为每个master都有salve节点,那么如果mater挂掉,redis cluster这套机制,就会自动将某个slave切换成master
- 了解Redis 的回收策略(淘汰策略)吗?
Redis 5.0版本中约定了八种内存淘汰策略,在内存不足以容纳新写入数据时触发。关于已设置过期时间的数据集(server.db[i].expires),采用如下四种淘汰策略:
volatile-lru:淘汰最近最少使用的数据。不推荐
volatile-ttl:淘汰将要过期的数据。不推荐
volatile-random:随机淘汰数据。不推荐
volatile-lfu:淘汰使用频率最低的数据。
关于未设置过期时间的数据集(server.db[i].dict),采用如下三种淘汰策略:
allkeys-lru:淘汰最近最少使用的数据。推荐使用,目前项目在用这种。
allkeys-lfu:淘汰使用频率最低的数据。
allkeys-random:随机淘汰数据。应该也没人用吧,你不删最少使用Key,却随机删。
另外一种策略就是no-enviction(禁止驱逐策略):当内存使用超过配置的阈值时会返回错误,不会驱逐任何键。意思是当内存不足以容纳新入数据时,新写入操作就会报错,查询请求可以继续进行,线上任务也不能持续进行,采用此策略可以保证数据不被丢失。redis淘汰数据时还会同步到aof,使用策略规则:
(1)如果数据访问频率呈现泊松分布,则使用 allkeys-lru
(2)如果数据访问频率呈现均匀分布,则使用allkeys-random。