1、Redis是什么RedisRemote Dictionary Server是一个使用C语言编写的高性能非关系型的键值对数据库。与传统数据库不同的是Redis的数据是存在内存中的所以读写速度非常快被广泛应用于缓存方向。Redis可以将数据写入磁盘中保证了数据的安全不丢失而且Redis的操作是原子性的。2、Redis优缺点2.1、优点1基于内存操作内存读写速度快。2支持多种数据类型包括String、Hash、List、Set、ZSet等。3支持持久化。Redis支持RDB和AOF两种持久化机制持久化功能可以有效地避免数据丢失问题。4支持事务。Redis的所有操作都是原子性的同时 Redis 还支持对几个操作合并后的原子性执行。5支持主从复制。主节点会自动将数据同步到从节点可以进行读写分离。6Redis命令的处理是单线程的。Redis6.0引入了多线程需要注意的是多线程用于处理网络数据的读写和协议解析Redis命令执行还是单线程的。2.2、缺点1对结构化查询的支持比较差。2数据库容量受到物理内存的限制不适合用作海量数据的高性能读写因此Redis适合的场景主要局限在较小数据量的操作。3Redis较难支持在线扩容在集群容量达到上限时在线扩容会变得很复杂。3、Redis为什么这么快1基于内存Redis是使用内存存储没有磁盘IO上的开销。数据存在内存中读写速度快。2IO多路复用模型Redis采用IO多路复用技术。Redis使用单线程来轮询描述符将数据库的操作都转换成了事件不在网络I/O上浪费过多的时间。3高效的数据结构Redis每种数据类型底层都做了优化目的就是为了追求更快的速度。4、既然Redis那么快为什么不用它做主数据库只用它做缓存虽然Redis非常快但它也有一些局限性不能完全替代主数据库。有以下原因:1事务处理Redis只支持简单的事务处理对于复杂的事务无能为力比如跨多个键的事务处理。2数据持久化Redis是内存数据库数据存储在内存中如果服务器崩溃或断电数据可能丢失。虽然 Redis提供了数据持久化机制但有一些限制。3数据处理Redis只支持一些简单的数据结构比如字符串、列表、哈希表等。如果需要处理复杂的数据结构比如关系型数据库中的表那么Redis可能不是一个好的选择。4数据安全Redis没有提供像主数据库那样的安全机制比如用户认证、访问控制等等。因此虽然Redis非常快但它还有一些限制不能完全替代主数据库。所以使用Redis作为缓存是一种很好的方式可以提高应用程序的性能并减少数据库的负载。5、讲讲Redis的线程模型Redis基于Reactor 模式开发了网络事件处理器这个处理器被称为文件事件处理器。它的组成结构为4部分多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的所以Redis才叫单线程模型。文件事件处理器使用I/O多路复用multiplexing程序来同时监听多个套接字 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。当被监听的套接字准备好执行连接accept、read、write、close等操作时 与操作相对应的文件事件就会产生 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。虽然文件事件处理器以单线程方式运行 但通过使用I/O多路复用程序来监听多个套接字 文件事件处理器既实现了高性能的网络通信模型 又可以很好地与redis服务器中其他同样以单线程方式运行的模块进行对接 这保持了Redis内部单线程设计的简单性。6、Redis 应用场景有哪些1缓存热点数据缓解数据库的压力。2利用Redis原子性的自增操作可以实现计数器的功能比如统计用户点赞数、用户访问数等。3分布式锁。在分布式场景下无法使用单机环境下的锁来对多个节点上的进程进行同步。可以使用Redis自带的SETNX命令实现分布式锁除此之外还可以使用官方提供的 RedLock分布式锁实现。4简单的消息队列可以使用Redis自身的发布/订阅模式或者List来实现简单的消息队列实现异步操作。5限速器可用于限制某个用户访问某个接口的频率比如秒杀场景用于防止用户快速点击带来不必要的压力。配合lua脚本6好友关系利用集合的一些命令比如交集、并集、差集等实现共同好友、共同爱好之类的功能。7排行榜利用zset数据结构的score的不同可以实现一个排行榜的功能。7、Memcached和Redis的区别1MemCached数据结构单一仅用来缓存数据而 Redis 支持多种数据类型。2MemCached不支持数据持久化重启后数据会消失。Redis 支持数据持久化。3Redis提供主从同步机制和 cluster 集群部署能力能够提供高可用服务。Memcached没有提供原生的集群模式需要依靠客户端实现往集群中分片写入数据。4Redis的速度比Memcached快很多。5Redis使用单线程的多路IO复用模型Memcached使用多线程的非阻塞IO模型。Redis6.0引入了多线程IO用来处理网络数据的读写和协议解析但是命令的执行仍然是单线程6value值大小不同Redis最大可以达到512Mmemcache只有1mb。8、为什么要用Redis而不用map/guava做缓存使用自带的map或者guava实现的是本地缓存最主要的特点是轻量以及快速生命周期随着 jvm的销毁而结束并且在多实例的情况下每个实例都需要各自保存一份缓存缓存不具有一致性。使用redis或memcached之类的称为分布式缓存在多实例的情况下各实例共用一份缓存数据缓存具有一致性。9、Redis数据类型有哪些9.1、基本数据类型:1String: 最常用的一种数据类型String类型的值可以是字符串、数字或者二进制但值最大不能超过512MB。2Hash: Hash是一个键值对集合。3Set: 无序去重的集合。Set提供了交集、并集等方法对于实现共同好友、共同关注等功能特别方便。4List: 有序可重复的集合底层是依赖双向链表实现的。5SortedSet: 有序Set。内部维护了一个score的参数来实现。适用于排行榜和带权重的消息队列等场景。9.2、特殊的数据类型:1Bitmap:位图可以认为是一个以位为单位数组数组中的每个单元只能存0或者1数组的下标在Bitmap中叫做偏移量。Bitmap的长度与集合中元素个数无关而是与基数的上限有关。2Hyperloglog。HyperLogLog是用来做基数统计的算法其优点是在输入元素的数量或者体积非常非常大时计算基数所需的空间总是固定的、并且是很小的。典型的使用场景是统计独立访客。3Geospatial: 主要用于存储地理位置信息并对存储的信息进行操作适用场景如定位、附近的人等。10、SortedSet和List异同点10.1、相同点1都是有序的2都可以获得某个范围内的元素。10.2、不同点1列表基于链表实现获取两端元素速度快访问中间元素速度慢2有序集合基于散列表和跳跃表实现访问中间元素时间复杂度是O (logN);3列表不能简单的调整某个元素的位置有序列表可以更改元素的分数;4有序集合更耗内存。11、Redis的内存用完了会怎样默认情况下如果达到设置的上限Redis的写命令会返回错误信息但是读命令还可以正常返回。 也可以配置内存淘汰机制当Redis达到内存上限时会冲刷掉旧的内容。12、Redis如何做内存优化可以好好利用Hash,list,sorted set,set等集合类型数据因为通常情况下很多小的Key-Value 可以用更紧凑的方式存放到一起。尽可能使用散列表hashes散列表是说散列表里面存储的数少使用的内存非常小所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象不要为这个用户的名称姓氏邮箱密码设置单独的key而是应该把这个用户的所有信息存储到一张散列表里面。13、keys命令存在的问题redis的单线程的。keys指令会导致线程阻塞一段时间直到执行完毕服务才能恢复。scan 采用渐进式遍历的方式来解决keys命令可能带来的阻塞问题每次scan命令的时间复杂度是O (1)但是要真正实现keys的功能需要执行多次scan。scan的缺点在scan的过程中如果有键的变化增加、删除、修改遍历过程可能会有以下问题新增的键可能没有遍历到遍历出了重复的键等情况也就是说scan并不能保证完整的遍历出来所有的键。14、Redis事务事务的原理是将一个事务范围内的若干命令发送给Redis然后再让Redis依次执行这些命令14.1、事务的生命周期1使用MULTI开启一个事务2在开启事务的时候每次操作的命令将会被插入到一个队列中同时这个命令并不会被真的执行3EXEC命令进行提交事务4提交后原子性执行一个事务范围内某个命令出错不会影响其他命令的执行不保证原子性1 127.0.0.1:6379 multi 2 OK 3 127.0.0.1:6379 set a 1 4 QUEUED 5 127.0.0.1:6379 set b 1 2 6 QUEUED 7 127.0.0.1:6379 set c 3 8 QUEUED 9 127.0.0.1:6379 exec 10 1) OK 11 2) (error) ERR syntax error 12 3) OKWATCH命令:WATCH命令可以监控一个或多个键一旦其中有一个键被修改之后的事务就不会执行类似于乐观锁。执行EXEC命令之后就会自动取消监控。1 127.0.0.1:6379 watch name 2 OK 3 127.0.0.1:6379 set name 1 4 OK 5 127.0.0.1:6379 multi 6 OK 7 127.0.0.1:6379 set name 2 8 QUEUED 9 127.0.0.1:6379 set gender 1 10 QUEUED 11 127.0.0.1:6379 exec 12 (nil) 13 127.0.0.1:6379 get gender 14 (nil)比如上面的代码1watch name开启了对name这个key的监控2修改name的值3开启事务a4在事务a中设置了name和gender的值5使用EXEC命令进行提交事务6使用命令get gender发现不存在即事务a没有执行使用UNWATCH可以取消WATCH命令对key的监控所有监控锁将会被取消。15、Redis事务支持隔离性吗Redis执行命令时单线程的并且它保证在执行事务时不会对事务进行中断事务可以运行直到执行完所有事务队列中的命令为止。因此Redis的事务是总是带有隔离性的。16、Redis事务保证原子性吗支持回滚吗Redis单条命令是原子性执行的但事务不保证原子性且没有回滚。事务中任意命令执行失败其余的命令仍会被执行。17、持久化机制持久化就是把内存的数据写到磁盘中防止服务宕机导致内存数据丢失。Redis支持两种方式的持久化一种是RDB的方式一种是AOF的方式。前者会根据指定的规则定时将内存中的数据存储在硬盘上而后者在每次执行完命令后将命令记录下来。一般将两者结合使用。AOF就是以上图片的这种格式。17.1、RDB方式RDB是Redis默认的持久化方案。RDB持久化时会将内存中的数据写入到磁盘中在指定目录下生成一个dump.rdb文件。Redis重启会加载dump.rdb文件恢复数据。bgsave是主流的触发RDB持久化的方式执行过程如下1执行BGSAVE命令.2Redis父进程判断当前是否存在正在执行的子进程如果存在BGSAVE命令直接返回。3父进程执行fork操作创建子进程fork操作过程中父进程会阻塞。4父进程fork完成后父进程继续接收并处理客户端的请求而子进程开始将内存中的数据写进硬盘的临时文件5当子进程写完所有数据后会用该临时文件替换旧的RDB文件。Redis启动时会读取RDB快照文件将数据从硬盘载入内存。通过RDB方式的持久化一旦Redis异常退出就会丢失最近一次持久化以后更改的数据。17.1.1、触发RDB持久化的方式1手动触发用户执行SAVE或BGSAVE命令。SAVE命令执行快照的过程会阻塞所有客户端的请求应避免在生产环境使用此命令。BGSAVE命令可以在后台异步进行快照操作快照的同时服务器还可以继续响应客户端的请求因此需要手动执行快照时推荐使用BGSAVE命令。2被动触发:①根据配置规则进行自动快照如SAVE 100 10100 秒内至少有10个键被修改则进行快照。②如果从节点执行全量复制操作主节点会自动执行BGSAVE生成RDB文件并发送给从节点。③默认情况下执行shutdown命令时如果没有开启AOF持久化功能则自动执行 BGSAVE。17.1.2、优点①Redis加载RDB恢复数据远远快于AOF的方式。②使用单独子进程来进行持久化主进程不会进行任何IO操作保证了Redis的高性能。17.1.3、缺点①RDB方式数据无法做到实时持久化。因为BGSAVE每次运行都要执行fork操作创建子进程属于重量级操作频繁执行成本比较高。②RDB文件使用特定二进制格式保存Redis版本升级过程中有多个格式的RDB版本存在老版本Redis无法兼容新版RDB格式的问题。17.2、AOF方式AOFappend only file持久化以独立日志的方式记录每次写命令Redis重启时会重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性AOF 是Redis持久化的主流方式。默认情况下Redis没有开启AOF方式的持久化可以通过appendonly参数启用appendonly yes。开启AOF方式持久化后每执行一条写命令Redis就会将该命令写进 aof_buf 缓冲区AOF 缓冲区根据对应的策略向硬盘做同步操作。默认情况下系统每30秒会执行一次同步操作。为了防止缓冲区数据丢失可以在Redis写入 AOF文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过appendfsync参数设置同步的时机。1 appendfsync always //每次写入aof文件都会执行同步最安全最慢不建议配置 2 appendfsync everysec //既保证性能也保证安全建议配置(命令写入aof_buf后调用系统write操作write完成 3 appendfsync no //由操作系统决定何时进行同步操作接下来看一下AOF持久化执行流程1所有的写入命令会追加到AOP缓冲区中。2AOF缓冲区根据对应的策略向硬盘同步。3随着AOF文件越来越大需要定期对AOF文件进行重写达到压缩文件体积的目的。AOF文件重写是把 Redis进程内的数据转化为写命令同步到新AOF文件的过程。4当Redis服务器重启时可以加载AOF文件进行数据恢复。17.2.1、优点1AOF可以更好的保护数据不丢失可以配置AOF每秒执行一次fsync操作如果Redis进程挂掉最多丢失1秒的数据。2AOF以append-only的模式写入所以没有磁盘寻址的开销写入性能非常高。17.2.2、缺点1对于同一份文件AOF文件比RDB数据快照要大。2数据恢复比较慢。17.3、RDB和AOF如何选择通常来说应该同时使用两种持久化方案以保证数据安全。1如果数据不敏感且可以从其他地方重新生成可以关闭持久化。2如果数据比较重要且能够承受几分钟的数据丢失比如缓存等只需要使用RDB即可。3如果是用做内存数据要使用Redis的持久化建议是RDB和AOF都开启。4如果只用AOF优先使用everysec的配置选择因为它在可靠性和性能之间取了一个平衡。当RDB与AOF两种方式都开启时Redis会优先使用AOF恢复数据因为AOF保存的文件比 RDB文件更完整。18、Redis有哪些部署方案单机版单机部署单机Redis能够承载的QPS大概就在上万到几万不等。这种部署方式很少使用。存在的问题1内存容量有限2处理能力有限3无法高可用。主从模式一主多从主负责写并且将数据复制到其它的slave节点从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容支撑读高并发。master节点挂掉后需要手动指定新的master可用性不高基本不用。哨兵模式主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。master节点挂掉后哨兵进程会主动选举新的 master可用性高但是每个节点存储的数据是一样的浪费内存空间。数据量不是很多集群规模不是很大需要自动容错容灾的时候使用。Redis cluster服务端分片技术3.0版本开始正式提供。Redis Cluster并没有使用一致性 hash而是采用slot (槽) 的概念一共分成16384个槽。将请求发送到任意节点接收到请求的节点会将查询请求发送到正确的节点上执行。主要是针对海量数据高并发高可用的场景如果是海量数据如果你的数据量很大那么建议就用Redis cluster所有主节点的容量总和就是 Redis cluster可缓存的数据容量。18.1、主从架构单机的redis能够承载的QPS大概就在上万到几万不等。对于缓存来说一般都是用来支撑读高并发的。因此架构做成主从 (master-slave) 架构一主多从主负责写并且将数据复制到其它的slave节点从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容支撑读高并发。Redis的复制功能是支持多个数据库之间的数据同步。主数据库可以进行读写操作当主数据库的数据发生变化时会自动将数据同步到从数据库。从数据库一般是只读的它会接收主数据库同步过来的数据。一个主数据库可以有多个从数据库而一个从数据库只能有一个主数据库。18.1.1、主从复制的原理1当启动一个从节点时它会发送一个PSYNC命令给主节点2如果是从节点初次连接到主节点那么会触发一次全量复制。此时主节点会启动一个后台线程开始生成一份RDB快照文件3同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB文件生成完毕后主节点会将RDB文件发送给从节点从节点会先将RDB文件写入本地磁盘然后再从本地磁盘加载到内存中4接着主节点会将内存中缓存的写命令发送到从节点从节点同步这些数据5如果从节点跟主节点之间网络出现故障连接断开了会自动重连连接之后主节点仅会将部分缺失的数据同步给从节点。18.2、哨兵Sentinel主从复制存在不能自动故障转移、达不到高可用的问题。哨兵模式解决了这些问题。通过哨兵机制可以自动切换主从节点。客户端连接Redis的时候先连接哨兵哨兵会告诉客户端Redis主节点的地址然后客户端连接上Redis并进行后续的操作。当主节点宕机的时候哨兵监测到主节点宕机会重新推选出某个表现良好的从节点成为新的主节点多个哨兵投票决定超过半数以上然后通过发布订阅模式通知其他的从服务器让它们切换主机。18.2.1、工作原理1每个Sentinel以每秒钟一次的频率向它所知道的MasterSlave以及其他Sentinel实例发送一个PING命令。2如果一个实例距离最后一次有效回复PING命令的时间超过指定值则这个实例会被 Sentinel标记为主观下线。3如果一个Master被标记为主观下线则正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认Master是否真正进入主观下线状态。4当有足够数量的Sentinel大于等于配置文件指定值在指定的时间范围内确认Master 的确进入了主观下线状态则Master会被标记为客观下线。若没有足够数量的Sentinel同意 Master 已经下线Master的客观下线状态就会被解除。若Master重新向Sentinel的PING命令返回有效回复Master的主观下线状态就会被移除。5哨兵节点会选举出哨兵leader负责故障转移的工作。6哨兵leader会推选出某个表现良好的从节点成为新的主节点然后通知其他从节点更新主节点信息。18.3、Redis cluster哨兵模式解决了主从复制不能自动故障转移、达不到高可用的问题但还是存在主节点的写能力、容量受限于单机配置的问题。而cluster模式实现了Redis的分布式存储每个节点存储不同的内容解决主节点的写能力、容量受限于单机配置的问题。Redis cluster集群节点最小配置6个节点以上3主3从其中主节点提供读写操作从节点作为备用节点不提供请求只作为故障转移使用。Redis cluster采用虚拟槽分区所有的键根据哈希函数映射到0 ~ 16383个整数槽内每个节点负责维护一部分槽以及槽所映射的键值数据。18.3.1、工作原理:1通过哈希的方式将数据分片每个节点均分存储一定哈希槽 (哈希值) 区间的数据默认分配了 16384 个槽位2每份数据分片会存储在多个互为主从的多节点上3数据写入先写主节点再同步到从节点 (支持配置为阻塞同步)4同一分片多个节点间的数据不保持一致性5读取数据时当客户端操作的 key 没有分配在该节点上时redis 会返回转向指令指向正确的节点6扩容时时需要需要把旧节点的数据迁移一部分到新节点在redis cluster架构下每个redis要放开两个端口号比如一个是6379另外一个就是加1w的端口号比如16379。16379端口号是用来进行节点间通信的也就是cluster bus的东西cluster bus 的通信用来进行故障检测、配置更新、故障转移授权。cluster bus用了另外一种二进制的协议gossip协议用于节点间进行高效的数据交换占用更少的网络带宽和处理时间。18.3.2、优点1无中心架构支持动态扩容2数据按照slot存储分布在多个节点节点间数据共享可动态调整数据分布3高可用性。部分节点不可用时集群仍可用。集群模式能够实现自动故障转移 (failover)节点之间通过gossip协议交换状态信息用投票机制完成Slave到Master的角色转换。18.3.3、缺点1不支持批量操作pipeline。2数据通过异步复制不保证数据的强一致性。3事务操作支持有限只支持多key在同一节点上的事务操作当多个key分布于不同的节点上时无法使用事务功能。4key作为数据分区的最小粒度不能将一个很大的键值对象如hash、list等映射到不同的节点。5不支持多数据库空间单机下的Redis可以支持到16个数据库集群模式下只能使用1 个数据库空间。6只能使用0号数据库。18.3.4、哈希分区算法有哪些节点取余分区。使用特定的数据如Redis的键或用户ID对节点数量N取余hash (key)%N 计算出哈希值用来决定数据映射到哪一个节点上。优点是简单性。扩容时通常采用翻倍扩容避免数据映射全部被打乱导致全量迁移的情况。一致性哈希分区。为系统中每个节点分配一个token范围一般在0~2^32这些token构成一个哈希环。数据读写执行节点查找操作时先根据key计算hash值然后顺时针找到第一个大于等于该哈希值的token节点。这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点对其他节点无影响。虚拟槽分区所有的键根据哈希函数映射到0~16383整数槽内计算公式slotCRC16 (key) 16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。Redis Cluser采用虚拟槽分区算法。19、过期键的删除策略1被动删除。在访问key时如果发现key已经过期那么会将key删除。2主动删除。定时清理key每次清理会依次遍历所有DB从db随机取出20个key如果过期就删除如果其中有5个key过期那么就继续对这个db进行清理否则开始清理下一个db。3内存不够时清理。Redis有最大内存的限制通过maxmemory参数可以设置最大内存当使用的内存超过了设置的最大内存就要进行内存释放 在进行内存释放的时候会按照配置的淘汰策略清理内存。20、内存淘汰策略有哪些20.1、为什么会有内存淘汰策略因为如果只靠被动删除、主动删除这两种删除方式不太行如果考虑到极端情况下我每次主动或被动去找到key都没有过期那么就可能出现一直清理不掉内存的情况这是就需要用内存淘汰策略来进行。当Redis的内存超过最大允许的内存之后Redis会触发内存淘汰策略删除一些不常用的数据以保证Redis服务器正常运行。Redis v4.0前提供6种数据淘汰策略1volatile-lru: LRULeast Recently Used最近最久未使用。利用LRU算法移除设置了过期时间的key时间维度2allkeys-lru:当内存不足以容纳新写入数据时从数据集中移除最近最少使用的key以时间为维度3volatile-ttl: 从已设置过期时间的数据集中挑选将要过期的数据淘汰4volatile-random: 从已设置过期时间的数据集中任意选择数据淘汰5allkeys-random: 从数据集中任意选择数据淘汰6no-eviction: 禁止删除数据当内存不足以容纳新写入数据时新写入操作会报错Redis v4.0后增加以下两种1volatile-lfu: LFULeast Frequently Used最近最久未使用从已设置过期时间的数据集中挑选最不经常使用的数据淘汰频次维度。2allkeys-lfu:当内存不足以容纳新写入数据时从数据集中移除最不经常使用的key。以频率为维度内存淘汰策略可以通过配置文件来修改相应的配置项是maxmemory-policy默认配置是 noeviction。21、如何保证缓存与数据库双写时的数据一致性1先删除缓存再更新数据库进行更新操作时先删除缓存然后更新数据库后续的请求再次读取时会从数据库读取后再将新数据更新到缓存。存在的问题删除缓存数据之后更新数据库完成之前这个时间段内如果有新的读请求过来就会从数据库读取旧数据重新写到缓存中再次造成不一致并且后续读的都是旧数据。2先更新数据库再删除缓存进行更新操作时先更新MySQL成功之后删除缓存后续读取请求时再将新数据回写缓存。存在的问题更新MySQL和删除缓存这段时间内请求读取的还是缓存的旧数据不过等数据更新完成就会恢复一致影响相对比较小。3异步更新缓存数据库的更新操作完成后不直接操作缓存而是把这个操作命令封装成消息扔到消息队列中然后由Redis自己去消费更新数据消息队列可以保证数据操作顺序一致性确保缓存系统的数据正常。4延迟双删以上几个方案都不完美需要根据业务需求评估哪种方案影响较小然后选择相应的方案。5这里还可以去使用加锁来实现这个功能解决数据一致性的问题22、缓存常见的问题22.1、缓存穿透缓存穿透是指查询一个不存在的数据由于缓存是不命中时被动写的如果从DB查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到DB去查询失去了缓存的意义。在流量大时可能DB就挂掉了。怎么解决1缓存空值并设置一定时间的过期时间不会查数据库。2采用布隆过滤器将所有可能存在的数据哈希到一个足够大的bitmap中查询不存在的数据会被这个bitmap拦截掉从而避免了对DB的查询压力。布隆过滤器的原理当一个元素被加入集合时通过K个哈希函数将这个元素映射成一个位数组中的K个点把它们置为1。查询时将元素通过哈希函数映射之后会得到k个点如果这些点有任何一个0则被检查元素一定不在直接返回如果都是1则查询元素很可能存在就会去查询 Redis和数据库。布隆过滤器一般用于在大数据量的集合中判定某元素是否存在存在一定的误判率。22.2、缓存雪崩缓存雪崩是指在我们设置缓存时采用了相同的过期时间导致缓存在某一时刻同时失效请求全部转发到DBDB瞬时压力过重挂掉。解决方法1、在原有的失效时间基础上增加一个随机值使得过期时间分散一些。这样每一个缓存的过期时间的重复率就会降低就很难引发集体失效的事件。2、加锁排队可以起到缓冲的作用防止大量的请求同时操作数据库但它的缺点是增加了系统的响应时间降低了系统的吞吐量牺牲了一部分用户体验。当缓存未查询到时对要请求的key进行加锁只允许一个线程去数据库中查其他线程等候排队。3、设置二级缓存。二级缓存指的是除了Redis本身的缓存再设置一层缓存本地缓存当Redis失效之后先去查询二级缓存。例如可以设置一个本地缓存在Redis缓存失效的时候先去查询本地缓存而非查询数据库。22.3、缓存击穿缓存击穿大量的请求同时查询一个key时此时这个key正好失效了就会导致大量的请求都落到数据库。缓存击穿是查询缓存中失效的key而缓存穿透是查询不存在的key。解决方法:1加互斥锁。在并发的多个请求中只有第一个请求线程能拿到锁并执行数据库查询操作其他的线程拿不到锁就阻塞等着等到第一个线程将数据写入缓存后直接走缓存。可以使用 Redis分布式锁实现代码如下:public String get(String key) { String value redis.get(key); if (value null) { //缓存值过期 String unique_key systemId : key; //设置30s的超时 if (redis.set(unique_key, 1, NX, PX, 30000) 1) { //设置成功 value db.get(key); redis.set(key, value, expire_secs); redis.del(unique_key); } else { //其他线程已经到数据库取值并回写到缓存了可以重试获取缓存值 sleep(50); get(key); //重试 } } else { return value; } }2热点数据不过期。直接将缓存设置为不过期然后由定时任务去异步加载数据更新缓存。这种方式适用于比较极端的场景例如流量特别特别大的场景使用时需要考虑业务能接受数据不一致的时间还有就是异常情况的处理保证缓存可以定时刷新。22.4、缓存预热缓存预热就是系统上线后将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候先查询数据库然后再将数据缓存的问题用户直接查询事先被预热的缓存数据就是进行一个提前预热的效果通过PostConstruct这个注解先将db运行了再放入到redis里面这个是在运行其他之前就开始运行了解决方案:1直接写个缓存刷新页面上线时手工操作一下2数据量不大可以在项目启动的时候自动进行加载3定时刷新缓存22.5、缓存降级当访问量剧增、服务出现问题如响应时间慢或不响应或非核心服务影响到核心流程的性能时仍然需要保证服务还是可用的即使是有损服务。系统可以根据一些关键数据进行自动降级也可以配置开关实现人工降级。缓存降级的最终目的是保证核心服务可用即使是有损的。而且有些服务是无法降级的如加入购物车、结算。在进行降级之前要对系统进行梳理看看系统是不是可以丢卒保帅从而梳理出哪些必须誓死保护哪些可降级比如可以参考日志级别设置预案1一般比如有些服务偶尔因为网络抖动或者服务正在上线而超时可以自动降级2警告有些服务在一段时间内成功率有波动如在95~100%之间可以自动降级或人工降级并发送告警3错误比如可用率低于90%或者数据库连接池被打爆了或者访问量突然猛增到系统能承受的最大阀值此时可以根据情况自动降级或者人工降级4严重错误比如因为特殊原因数据错误了此时需要紧急人工降级。服务降级的目的是为了防止Redis服务故障导致数据库跟着一起发生雪崩问题。因此对于不重要的缓存数据可以采取服务降级策略例如一个比较常见的做法就是Redis出现问题不去数据库查询而是直接返回默认值给用户。23、Redis怎么实现消息队列使用list类型保存数据信息rpush生产消息lpop消费消息当lpop没有消息时可以sleep一段时间然后再检查有没有信息如果不想sleep的话可以使用blpop在没有信息的时候会一直阻塞直到信息的到来。BLPOP queue 0 // 0表示不限制等待时间 //BLPOP和LPOP命令相似唯一的区别就是当列表没有元素时BLPOP命令会一直阻塞连接直到有新元素加入。redis可以通过pub/sub主题订阅模式实现一个生产者多个消费者当然也存在一定的缺点当消费者下线时生产的消息会丢失。PUBLISH channel1 hi SUBSCRIBE channel1 UNSUBSCRIBE channel1 // 退订通过SUBSCRIBE命令订阅的频道。PSUBSCRIBE channel?*按照规则订阅。PUNSUBSCRIBE channel?*退订通过PSUBSCRIBE命令按照某种规则订阅的频道。其中订阅规则要进行严格的字符串匹配PUNSUBSCRIBE*无法退订channel?* 规则。24、Redis怎么实现延时队列使用sorted set拿时间戳作为score消息内容作为key调用zadd来生产消息消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。25、Redis中pipeline的作用redis客户端执行一条命令分4个过程发送命令、命令排队、命令执行、返回结果。使用pipeline可以批量请求批量返回结果执行速度比逐条执行要快。使用pipeline组装的命令个数不能太多不然数据量过大增加客户端的等待时间还可能造成网络阻塞可以将大量命令的拆分多个小的pipeline命令完成。原生批命令mset和mget与pipeline对比:1原生批命令是原子性pipeline是非原子性。pipeline命令中途异常退出之前执行成功的命令不会回滚。2原生批命令只有一个命令但pipeline支持多命令。26、LUA脚本Redis通过LUA脚本创建具有原子性的一批命令的执行当lua脚本命令正在运行的时候不会有其他脚本或Redis命令被执行实现组合命令的原子操作。在Redis中执行Lua脚本有两种方法eval和evalsha。eval命令使用内置的Lua解释器对Lua脚本进行求值。// 第一个参数是lua脚本第二个参数是键名参数个数剩下的是键名参数和附加参数 eval return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]} 2 key1 key2 first second 1)key1 2)key2 3)first 4)second26.1、LUA脚本作用1Lua脚本在Redis中是原子执行的执行过程中间不会插入其他命令。2Lua脚本可以将多条命令一次性打包有效地减少网络开销。26.2、应用场景举例限制接口访问频率。在Redis维护一个接口访问次数的键值对key是接口名称value是访问次数。每次访问接口时会执行以下操作1通过aop拦截接口的请求对接口请求进行计数每次进来一个请求相应的接口访问次数count 加1存入redis。2如果是第一次请求则会设置count1并设置过期时间。因为这里set() 和expire() 组合操作不是原子操作所以引入lua脚本实现原子操作避免并发访问问题。3如果给定时间范围内超过最大访问次数则会抛出异常。private String buildLuaScript() { return local c \nc redis.call(get,KEYS[1]) \nif c and tonumber(c) tonumber(ARGV[1]) then \nreturn c; \nend \nc redis.call(incr,KEYS[1]) \nif tonumber(c) 1 then \nredis.call(expire,KEYS[1],ARGV[2]) \nend \nreturn c;; } String luaScript buildLuaScript(); RedisScriptNumber redisScript new DefaultRedisScript(luaScript, Number.class); Number count redisTemplate.execute(redisScript, keys, limit.count(), limit.period());PS: 这种接口限流的实现方式比较简单问题也比较多一般不会使用接口限流用的比较多的是令牌桶算法和漏桶算法。27、什么是RedLock红锁Redis官方站提出了一种权威的基于Redis实现分布式锁的方式名叫Redlock此种方式比原先的单节点的方法更安全。它可以保证以下特性1安全特性互斥访问即永远只有一个client能拿到锁2避免死锁最终client都可能拿到锁不会出现死锁的情况即使原本锁住某资源的 client挂掉了3容错性只要大部分Redis节点存活就可以正常提供服务28、Redis大key怎么处理通常我们会将含有较大数据或含有大量成员、列表数的Key称之为大Key。以下是对各个数据类型大key的描述:1value是STRING类型它的值超过5MB2value是ZSET、Hash、List、Set等集合类型时它的成员数量超过1w个上述的定义并不绝对主要是根据value的成员数量和大小来确定根据业务场景确定标准。怎么处理:28.1、怎么处理:1当value是string时可以使用序列化、压缩算法将key的大小控制在合理范围内但是序列化和反序列化都会带来更多时间上的消耗。或者将key进行拆分一个大key分为不同的部分记录每个部分的key使用multiget等操作实现事务读取。2当value是 ist/set等集合类型时根据预估的数据规模来进行分片不同的元素计算后分到不同的片。29、Redis常见性能问题和解决方案1Master最好不要做任何持久化工作包括内存快照和AOF日志文件特别是不要启用内存快照做持久化。2如果数据比较关键某个Slave开启AOF备份数据策略为每秒同步一次。3为了主从复制的速度和连接的稳定性Slave和Master最好在同一个局域网内。4尽量避免在压力较大的主库上增加从库5Master调用 BGREWRITEAOF重写AOF文件AOF在重写的时候会占大量的CPU和内存资源导致服务load过高出现短暂服务暂停现象。6为了Master的稳定性主从复制不要用图状结构用单向链表结构更稳定即主从关系为Master-Slave1-Slave2-Slave3...这样的结构也方便解决单点故障问题实现Slave对 Master的替换也即如果Master挂了可以立马启用Slave1做Master其他不变。30、Redis突然变慢有哪些原因1存在bigkey。如果Redis实例中存储了bigkey那么在淘汰删除bigkey释放内存时也会耗时比较久。应该避免存储bigkey降低释放内存的耗时。2如果Redis实例设置了内存上限maxmemory有可能导致Redis变慢。当Redis内存达到maxmemory后每次写入新的数据之前Redis必须先从实例中踢出一部分数据让整个实例的内存维持在maxmemory之下然后才能把新数据写进来。3开启了内存大页。当Redis在执行后台RDB和AOF rewrite时采用fork子进程的方式来处理。但主进程fork子进程后此时的主进程依旧是可以接收写请求的而进来的写请求会采用Copy On Write写时复制的方式操作内存数据30.1、什么是写时复制这样做的好处是父进程有任何写操作并不会影响子进程的数据持久化。不过主进程在拷贝内存数据时会涉及到新内存的申请如果此时操作系统开启了内存大页那么在此期间客户端即便只修改10B的数据Redis在申请内存时也会以2MB为单位向操作系统申请申请内存的耗时变长进而导致每个写请求的延迟增加影响到Redis性能。解决方案就是关闭内存大页机制。4使用了Swap。操作系统为了缓解内存不足对应用程序的影响允许把一部分内存中的数据换到磁盘上以达到应用程序对内存使用的缓冲这些内存数据被换到磁盘上的区域就是 Swap。当内存中的数据被换到磁盘上后Redis再访问这些数据时就需要从磁盘上读取访问磁盘的速度要比访问内存慢几百倍。尤其是针对Redis这种对性能要求极高、性能极其敏感的数据库来说这个操作延时是无法接受的。解决方案就是增加机器的内存让Redis有足够的内存可以使用。或者整理内存空间释放出足够的内存供Redis使用5网络带宽过载。网络带宽过载的情况下服务器在TCP层和网络层就会出现数据包发送延迟、丢包等情况。Redis的高性能除了操作内存之外就在于网络IO了如果网络IO存在瓶颈那么也会严重影响Redis的性能。解决方案1、及时确认占满网络带宽Redis实例如果属于正常的业务访问那就需要及时扩容或迁移实例了避免因为这个实例流量过大影响这个机器的其他实例。2、运维层面需要对Redis机器的各项指标增加监控包括网络流量在网络流量达到一定阈值时提前报警及时确认和扩容。6频繁短连接。频繁的短连接会导致Redis大量时间耗费在连接的建立和释放上TCP的三次握手和四次挥手同样也会增加访问延迟。应用应该使用长连接操作Redis避免频繁的短连接。31、为什么Redis集群的最大槽数是16384个Redis Cluster采用数据分片机制定义了16384个Slot槽位集群中的每个Redis实例负责维护一部分槽以及槽所映射的键值数据。Redis每个节点之间会定期发送ping/pong消息心跳包包含了其他节点的数据用于交换数据信息。Redis集群的节点会按照以下规则发ping消息1每秒会随机选取5个节点找出最久没有通信的节点发送ping消息2每100毫秒都会扫描本地节点列表如果发现节点最近一次接受pong消息的时间大于 cluster-node-timeout/2则立刻发送ping消息心跳包的消息头里面有个myslots的char数组是一个bitmap每一个位代表一个槽如果该位为1表示这个槽是属于这个节点的。接下来解答为什么Redis集群的最大槽数是16384个而不是65536个。1如果采用16384个插槽那么心跳包的消息头占用空间2KB16384/8如果采用 65536个插槽那么心跳包的消息头占用空间8KB (65536/8)。可见采用65536个插槽发送心跳信息的消息头达8k比较浪费带宽。2一般情况下一个Redis集群不会有超过1000个master节点太多可能导致网络拥堵。3哈希槽是通过一张bitmap的形式来保存的在传输过程中会对bitmap进行压缩。bitmap的填充率越低压缩率越高。其中bitmap填充率slots/N (N 表示节点数)。所以插槽数越低填充率会降低压缩率会提高。
