Redis是 单进程单线程 的，Redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销。
Redis为什么是单线程的？
多线程处理会涉及到锁，而且多线程处理会设计到线程切换而消耗CPU。因为CPU不会Redis的瓶颈，Redis的瓶颈最有可能是机器内存或者网络带宽。单线程无法发挥多核CPU性能，不过可以通过在单机开启Redis实例来解决。
Redis的优势
**速度快。**因为数据存储于内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
支持丰富的数据类型 ，支持string，list，set，sorted set，hash
支持事务 ，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
丰富的特性 ：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
Redis和memcached有哪些优势
memcached所有的值均是简单的字符串，Reids作为其替代者，支持更为丰富的数据类型
Redis的速度比memcached快很多
Redis可以持久化其数据
Redis支持数据的备份，即master/slave模式的数据备份
Redis key的过期时间和永久有效分别怎么设置？
EXPIRE 和 PERSIST 命令。
Redis 主要消耗什么物理资源？
内存。
为什么Redis需要把所有数据放到内存中？
Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。
所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。
在内存越来越便宜的今天，redis将会越来越受欢迎。 如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。
说说Redis哈希槽的概念？
Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。
Redis中的管道有什么用？
一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。
这就是管道（pipelining），是一种几十年来广泛使用的技术。例如许多POP3协议已经实现支持这个功能，大大加快了从服务器下载新邮件的过程。
怎么理解Redis事务？
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
Redis 事务相关的命令有哪几个？
MULTI 、 EXEC 、 DISCARD 、 WATCH
Redis内存回收机制
Redis的内存回收主要围绕以下两个方面：
Redis过期策略 ：删除过期时间的key值
Redis淘汰策略 ：内存使用到达maxmemory上限时触发内存淘汰数据
Redis过期策略
Redis过期策略通常有以下三种：
定时过期每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
惰性过期只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
定期过期每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
Redis中同时使用了 惰性过期 和 定期过期 两种过期策略。
Redis有哪几种数据淘汰策略
在Redis中，允许用户设置最大使用内存大小 server.maxmemory ，当Redis内存数据集大小上升到一定大小的时候，就会执行数据淘汰策略
volatile-lru ：从已设置过期的数据集中挑选最近最少使用的淘汰
volatile-ttl ：从已设置过期的数据集中挑选将要过期的数据淘汰
volatile-random ：从已设置过期的数据集中任意挑选数据淘汰
allkeys-lru ：从数据集中挑选最近最少使用的数据淘汰
allkeys-random ：从数据集中任意挑选数据淘汰
noenviction ：禁止淘汰数据
Redis支持哪几种持久化方式
RDB持久化原理是将Redis在内存中的数据记录定时dump到磁盘上的RDB文件。 指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF（append only file）持久化原理是将Redis的操作日志以追加的方式写入文件。 以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。当服务器重启的时候会重新执行这些命令来恢复原始的数据。AOF命令以Reids协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
Redis两种持久化方式优缺点？
RDB持久化
优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小
缺点：RDB文件的致命缺点在与其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化称为主流。此外，RDB文件需要满足特定格式，兼容性差。
AOF持久化与RDB持久化相对应,AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大，恢复速度慢，对性能影响大
如何选择Redis持久化方式策略？
在介绍持久化策略之前，首先要明白无论是RDB还是AOF，持久化的开启都是要付出性能方面的代价的。对比RDB持久化，一方面是bdsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力；对于AOF持久化，向硬盘写数据的频率大大提高（everysec策略下为秒级），IO压力更大，设置可能造成AOF追加阻塞文件。此外，AOF文件的重写与RDB的basave类似，会有fork时的阻塞和子进程的IO压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对Redis主进程性能的影响会更大。
在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化，使用RDB或AOF一种，或同事开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从机slave可以独立的选择持久化方案。
为什么要做Redis分区？
分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。
Redis集群的主从复制模型是怎样的？
为了是在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群是用了主从复制模型，每个节点都会有N-1个复制品
Redis集群会有写操作丢失吗？为什么？
Redis并不能保证数据强一致性，这意味着在实际中集群在特定的条件下可能会丢失写操作
Redis集群之间是如何复制的
异步复制。
Redis如何做内存优化
尽可能使用散列表（hashes），散列表（是说列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面，比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户所有信息存储到一张散列表中。
Redis常用的使用场景
Session共享（单点登录）
页面缓存
队列
排行榜/计算器
发布/订阅
Redis有哪些架构模式？讲讲各自的特点？
单机版
特点：简单
存在问题：
内存容量有限
处理能力有限
无法高可用
主从复制
Redis的复制（replication）功能允许用户根据一个Redis服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。主要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步给从服务器，从而一直保证主从服务器的数据相同。
问题：
无法保证高可用
没有解决master写的压力
哨兵
Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。
特点：
保证高可用
监控各个节点
自动故障迁移
缺点：
主从模式，切换需要时间，会丢数据
没有解决master写的压力
集群（proxy型）
Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。
特点：
多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
支持失败节点自动删除
后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致
缺点：
增加了新的 proxy，需要维护其高可用。
failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预
集群（直连型）
从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。
特点：
无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。
数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。
高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本
实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master的角色提升。
缺点：
资源隔离性较差，容易出现相互影响的情况。
数据通过异步复制,不保证数据的强一致性
使用过Redis分布式锁吗，它是怎么实现的？
先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。 如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？ set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！
使用过 Redis 做异步队列么，你是怎么用的？有什么缺点？
般使用 list 结构作为队列，rpush 生产消息，lpop 消费消息。当 lpop 没有消息的时候，要适当 sleep一会再重试。
缺点：
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如 rabbitmq 等。
能不能生产一次消费多次呢？
使用 pub/sub 主题订阅者模式，可以实现 1:N 的消息队列。
什么是缓存穿透？如何避免？
缓存穿透
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。
如何避免？
对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。
对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。
什么是缓存雪崩？何如避免？
缓存雪崩当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力，导致系统崩溃。
如何避免？
在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期 3：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀
缓存并发
这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行。
缓存预热
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。
这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决思路：
直接写个缓存刷新页面，上线时手工操作下；
数据量不大，可以在项目启动的时候自动进行加载；
目的就是在系统上线前，将数据加载到缓存中。
Redis回收进程如何工作的？
客户端执行数据写入操作
redis server接收到写入操作之后，检查maxmemory的限制，如果超过了限制，那么就根据对应的policy清理掉部分数据
写入操作完成执行。
Redis是单线程的，如何提高多核CPU的利用率？
可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。
修改配置不重启Redis会实时生效吗？
针对运行实例，有许多配置选项可以通过 CONFIG SET 命令进行修改，而无需执行任何形式的重启。 从 Redis 2.2 开始，可以从 AOF 切换到 RDB 的快照持久性或其他方式而不需要重启 Redis。检索 CONFIG GET * 命令获取更多信息。 但偶尔重新启动是必须的，如为升级 Redis 程序到新的版本，或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候。
Redis的内存用完了会发生什么？
如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回。）或者你可以将Redis当缓存来使用配置淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。
分布式Redis是前期做还是后期规模上来了再做好？为什么？
既然Redis是如此的轻量（单实例只使用1M内存）,为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。
Redis与其他key-value存储有什么不同？
Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，应为数据量不能大于硬件内存。在内存数据库方面的另一个优点是， 相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。 同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。
关注获得更多分享
网友评论