概述

什么是Redis

• Redis (Remote Dictionary Server) 是一个使用 C 语言编写的，开源的 (BSD许可) 的高性能非关系型 (NoSQL) 的键值对数据库

• Redis 可以存储键和五种不同类型的值之间的映射，键的类型只能为字符串，值支持：字符串、列表、集合、散列表、有序集合

• 与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快， 因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的 Key-Value DB。

• 另外，Redis 也经常用来做分布式锁，除此之 外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案

Redis有哪些优缺点

**优点 **

• 读写性能优异， Redis 能读的速度是110000次/s，写的速度是81000次/s
• 支持数据持久化，支持 AOF 和 RDB 两种持久化方式
• 支持事务，Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作合并 后的原子性执行
• 数据结构丰富，除了支持 String 类型的 value 外还支持 Hash、Set、Zset、list 等数据结构。
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

**缺点 **

• 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上
• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性
• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂，为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费

为什么要用 Redis /为什么要用缓存

主要从 “高性能” 和 “高并发” 这两点来看待这个问题

高性能

假如用户第一次访问数据库中的某些数据，这个过程会比较慢，因为是从硬盘上读取的，将该用户访问的数据存在数缓存中，这样下一次再访问这些数据的时候 就可以直接从缓存中获取了，操作缓存就是直接操作内存，所以速度相当快，如果数据库中的对应数据改变后，同步改变缓存中相应的数据即可

高并发

直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存而不用经过数据库

为什么要用 Redis 而不用 map/guava 做缓存?

• 缓存分为本地缓存和分布式缓存，以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性

• 使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性，缺点是需要保持 redis 或 memcached 服务的高可用，整个程序架构上较为复杂

Redis 为什么这么快

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速，数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是 O(1)
• 数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁 操作，没有因为可能出现死锁而导致的性能消耗；
• 使用多路 I/O 复用模型，非阻塞 IO
• 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

数据类型

Redis有哪些数据类型

Redis主要有 5 种数据类型，包括 String，List，Set，Zset 和 Hash 满足大部分的应用场景

Redis的应用场景

• 计数器

  • 可以对 String 进行自增自减运算，从而实现计数器功能，Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量

• 缓存

  • 将热点数据放到内存中，设置内存的大使用量以及淘汰策略来保证缓存的命中率

• 会话缓存

  • 可以使用 Redis 来统一存储多台应用服务器的会话信息，当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性

• 全页缓存 (FPC)

  • 除基本的会话 token 之外，Redis 还提供很简便的 FPC 平台，以 Magento 为例， Magento 提供一个插件来使用 Redis 作为全页缓存后端，此外，对 WordPress 的用户来说，Pantheon 有一个非常好的插件 wp-redis，这个插件能帮助你快速度加载你曾浏览过的页面

• 查找表

  • 例如 DNS 记录就很适合使用 Redis 进行存储，查找表和缓存类似，也是利用了 Redis 快速的查找特性，但是查找表的内容不能失效，而缓存的内容可以失效， 因为缓存不作为可靠的数据来源

• 消息队列

  • List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息，不过最好使用 Kafka、RabbitMQ 等消息中间件

• 分布式锁实现

  • 在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步，使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现

• Set 可以实现交集、并集等操作，从而实现共同好友等功能

• ZSet 可以实现有 序性操作，从而实现排行榜等功能

• String 适合简单的 k-v 存储，类似于 memcached 的存储结构，短信验证码，配置信息等，就用这种类型来存储

• Hash 一般 key 为 ID 或者唯一标示，value对应的就是详情了，如商品详情， 个人信息详情，新闻详情等

• List 比较适合存储一些有序且数据相对固定的数据，如省市区表、字典表等，因为list是有序的，适合根据写入的时间来排序

• Set 可以简单的理解为 id-List 的模式，如微博中一个人有哪些好友，Set 牛的地方在于，可以对两个set提供交集、并集、差集操作

• Sorted Set 是 Set 的增强版本，增加了一个 Score 参数，自动会根据 score 的值进行排序，比较适合类似于 Top10 等不根据插入的时间来排序的数据

持久化

什么是Redis持久化？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失

Redis 的持久化机制是什么？各自的优缺点？

Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制

RDB

RDB是 Redis 默认的持久化方式，按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为 dump.rdb，通过配置文件中的 save 参数来 定义快照的周期

优点：

• 只有一个文件 dump.rdb，方便持久化
• 容灾性好，一个文件可以保存到安全的磁盘
• 性能大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 大化，使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能
• 相对于数据集大时，比 AOF 的启动效率更高

缺点：

• 数据安全性低，RDB 是间隔一段时间进行持久化，如果持久化之间 Redis 发生故障，会发生数据丢失，所以这种方式更适合数据要求不严谨的时候

AOF

AOF 持久化 ( 即 Append Only File 持久化)，是将 Redis 执行的每次写命令记录到单独的日志文件中，当重启 Redis 会重新将持久化的日志中文件恢复数据，当两种方式同时开启时，数据恢复 Redis 会优先选择 AOF 恢复

优点：

• 数据安全，AOF 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 AOF 文件中一次
• 通过 append 模式写文件，即使中途服务器宕机，也通过 redis-checkaof 工具解决数据一致性问题
• AOF 机制的 rewrite 模式，AOF 文件没被 rewrite 之前 (文件过大时会对命令进行合并重写)，可以删除其中的某些命令，比如误操作的 flushall

缺点：

• AOF 文件比 RDB 文件大，且恢复速度慢
• 数据集大的时候，比 RDB 启动效率低

优缺点是什么？

• AOF 文件比 RDB 更新频率高，优先使用 AOF 还原数据
• AOF 比 RDB 更安全也更大
• RDB 性能比 AOF 好
• 如果两个都配了优先加载 AOF

如何选择合适的持久化方式

• 一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能，在这种情况下，当 Redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整
• 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化
• 有很多用户都只使用 AOF 持久化，但并不推荐这种方式，因为定时生成RDB快照 (snapshot) 非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免 AOF 程序的 BUG
• 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式

Redis持久化数据和缓存怎么做扩容？

如果 Redis 被当做缓存使用，使用一致性哈希实现动态扩容缩容

如果 Redis 被当做一个持久化存储使用，必须使用固定的 keys-tonodes 映射关系，节点的数量一旦确定不能变化，否则的话 (即 Redis 节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有 Redis 集群可以做到这样

过期键的删除策略

Redis的过期键的删除策略

我们都知道，Redis是 key-value 数据库，我们可以设置 Redis 中缓存的 key 的过期时间，Redis 的过期策略就是指当 Redis 中缓存的key过期了，Redis如何处理

过期策略通常有以下三种

• 定时过期：每个设置过期时间的 key 都需要创建一个定时器，到过期时间就会立即清除，该策略可以立即清除过期的数据，对内存很友好，但是会占用大量的 CPU 资源去处理过期的数据，从而影响缓存的响应时间和吞吐量
• 惰性过期：只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除，该策略可以节省CPU资源，却对内存非常不友好，极端情况可能出现大量的过期 key 没有再次被访问，从而不会被清除，占用大量内存
• 定期过期：每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的key，该策略是前两者的一个折中方案，通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果

expires字典会保存所有设置了过期时间的 key 的过期时间数据，其中，key 是指向键空间中的某个键的指针，value 是该键的毫秒精度的UNIX时间戳，用来表示过期时间，键空间是指该 Redis 集群中保存的所有键

Redis中同时使用了惰性过期和定期过期两种过期策略

Redis key的过期时间和永久有效分别怎么设置？

EXPIRE 和 PERSIST 命令

我们知道通过 expire 来设置 key 的过期时间，那么对过期的数据怎么处理呢?

除了缓存服务器自带的缓存失效策略之外（Redis 默认的有 6 种策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种

• 定时去清理过期的缓存
• 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存

两者各有优劣，第一种的缺点是维护大量缓存的 key 是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂，具体用哪种方案，大家可以根据自己的应用场景来权衡

内存相关

MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据

Redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略

Redis的内存淘汰策略有哪些

Redis 的内存淘汰策略是指在 Redis 用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据

• noeviction：当内存不足以容纳新写入数据时，新写入操作会报错

• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key

• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key

• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key

• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key

• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

Redis主要消耗什么物理资源？

内存

Redis的内存用完了会发生什么？

如果达到设置的上限，Redis 的写命令会返回错误信息，但是读命令还可以正常返回，或者你可以配置内存淘汰机制，当 Redis 达到内存上限时会冲刷掉旧的内容

Redis如何做内存优化？

可以好好利用 Hash、List、Sorted、Set、Set 等集合类型数据，因为通常情况下很多小的 Key-Value 可以用更紧凑的方式存放到一起，尽可能使用散列表，散列表使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面，比如你的 web 系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的 key，而是应该把这个用户的所有信息存储到一张散列表

Redis线程模型

Redis 基于 Reactor 模式开发了网络事件处理器，这个处理器被称为文件事件处理器 (file event handler)，它的组成结构为 4 部分

• 多个套接字
• IO多路复用程序
• 文件事件分派器
• 事件处理器

因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型

文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器，当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件

虽然文件事件处理器以单线程方式运行， 但通过使用 I/O 多路复用程序来监听多个套接字， 文件事件处理器既实现了高性能的网络通信模型， 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接， 这保持了 Redis 内部单线程设计的简单性

什么是事务？

• 事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行
• 事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
• 事务是一个原子操作，事务中的命令要么全部被执行，要么全部都不执行

Redis事务的概念

• Redis 事务的本质是通过 MULTI、EXEC、WATCH 等一组命令的集合
• 事务支持一次执行多个命令，一个事务中所有命令都会被序列化，在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中
• redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令

Redis事务的三个阶段

• 事务开始 MULTI

• 命令入队

• 事务执行 EXEC

• 事务执行过程中，如果服务端收到有 EXEC、DISCARD、WATCH、MULTI 之外的请求，将会把请求放入队列中排队

Redis事务相关命令

• Redis 事务功能是通过 MULTI、EXEC、DISCARD 和 WATCH 四个原语实现的

• Redis 会将一个事务中的所有命令序列化，然后按顺序执行

• Redis 不支持回滚，Redis 在事务失败时不进行回滚，而是继续执行余下的命令， 所以 Redis 的内部可以保持简单且快速

• 如果在一个事务中的命令出现错误，那么所有的命令都不会执行

• 如果在一个事务中出现运行错误，那么正确的命令会被执行

• WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为，可以监控一个或多个键，一旦其中有一个键被修改或删除，之后的事务就不会执行，监控一直持续到 EXEC 命令

• MULTI 命令用于开启一个事务，它总是返回 OK， MULTI 执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当 EXEC 命令被调用时，所有队列中的命令才会被执行

• EXEC：执行所有事务块内的命令，返回事务块内所有命令的返回值，按命令执行的先后顺序排列，当操作被打断时，返回空值 nil

• 通过调用 DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出

• UNWATCH 命令可以取消 watch 对所有 key 的监控

事务管理

• 原子性（Atomicity）

  • 原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生

• 一致性（Consistency）

  • 事务前后数据的完整性必须保持一致

• 隔离性（Isolation）

  • 多个事务并发执行时，一个事务的执行不应影响其他事务的执行

• 持久性（Durability）

  • 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

Redis 的事务总是具有 ACID 中的一致性和隔离性，其他特性是不支持的，当服务器运行在 AOF 持久化模式下，并且 appendfsync 选项的值为 always 时，事务也具有耐久性

Redis事务支持隔离性吗

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止，因此，Redis 的事务是总是带有隔离性的

Redis事务保证原子性吗，支持回滚吗

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚，事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务其他实现

基于 Lua 脚本，Redis 可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完

基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成，但这样会需要额外写代码实现，比较繁琐

集群方案 - 哨兵模式

• Sentinel，中文名是哨兵，哨兵是 Redis 集群机构中非常重要的一个组件，主要有以下功能

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作

• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员

• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上

• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址

• 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

• 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题

• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的

  • 哨兵至少需要 3 个实例，来保证自己的健壮性
  • 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性
  • 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

集群方案 - Redis Cluster

Redis Cluster 是一种服务端 Sharding 技术，3.0版本开始正式提供，Redis Cluster 并没有使用一致性 hash，而是采用 slot(槽) 的概念，一共分成16384个槽，将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行

方案说明

• 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽 (哈希值) 区间的数据，默认分配了16384 个槽位
• 每份数据分片会存储在多个互为主从的多节点上
• 数据写入先写主节点，再同步到从节点，支持配置为阻塞同步
• 同一分片多个节点间的数据不保持一致性
• 读取数据时，当客户端操作的 key 没有分配在该节点上时，redis会返回转向指令，指向正确的节点
• 扩容时时需要需要把旧节点的数据迁移一部分到新节点
• 在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是加1w 的端口号，比如 16379，16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权
• cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间

基本通信原理

集群元数据的维护一般有两种方式：集中式、Gossip 协议

redis cluster 节点间采用 gossip 协议进行通信

分布式寻址算法

• hash 算法（大量缓存重建）

• 一致性 hash 算法，自动缓存迁移，虚拟节点自动负载均衡

优点：

• 无中心架构
• 数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布
• 可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除
• 高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升
• 降低运维成本，提高系统的扩展性和可用性

缺点：

• Client 实现复杂，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟，异常处理部分还不完善，比如常见的 “max redirect exception”
• 节点会因为某些原因发生阻塞(阻塞时间大于 clutser-node-timeout)，被判断下线，这种 failover 是没有必要的
• 数据通过异步复制，不保证数据的强一致性
• 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况
• Slave 在集群中充当“冷备”，不能缓解读压力，当然可以通过 SDK 的合理设计来提高 Slave 资源的利用率
• Key 批量操作限制，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 执行批量操作。对于映射为不同 slot 值的 Key 由于 Keys 不支持跨 slot 查询，所以执行 mset、mget、sunion 等操作支持不友好
• Key 事务操作支持有限，只支持多 key 在同一节点上的事务操作，当多个 Key 分布于不同的节点上时无法使用事务功能
• Key 作为数据分区的最小粒度，不能将一个很大的键值对象如 hash、list 等映射到不同的节点
• 不支持多数据库空间，单机下的 redis 可以支持到 16 个数据库，集群模式下只能使用 1 个数据库空间，即 db 0
• 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构
• 避免产生 hot-key，导致主库节点成为系统的短板
• 避免产生 big-key，导致网卡撑爆、慢查询等
• 重试时间应该大于 cluster-node-time 时间
• Redis Cluster 不建议使用 pipeline 和 multi-keys 操作，减少 max redirect 产生的场景

Redis Sharding

• Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的多 Redis 实例集群方法，其主要思想是采用哈希算法将 Redis 数据的 key 进行散列，通过 hash 函数，特定的 key 会映射到特定的 Redis 节点上
• Java redis 客户端驱动 jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及结合缓存池的 ShardedJedisPool 优点，优势在于非常简单，服务端的 Redis 实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强
• 缺点是由于 sharding 处理放到客户端，规模进一步扩大时给运维带来挑战，客户端 sharding 不支持动态增删节点，服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整

Redis 主从架构

• 单机的 Redis，能够承载的 QPS 大概就在上万到几万不等，对于缓存来说，一般都是用来支撑读高并发的，因此架构做成主从 (master-slave) 架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读，所有的读请求全部走从节点，这样也可以很轻松实现水平扩容，支撑读高

• Redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量

• 一个 master node 是可以配置多个 slave node 的，slave node 也可以连接其他的 slave node

• slave node 做复制的时候，不会 block master node 的正常工作

• slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务，但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了

• slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量

• 注意，如果采用了主从架构，那么建议必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了

• 另外，master 的各种备份方案，也需要做，万一本地的所有文件丢失了，从备份中挑选一份 rdb 去恢复 master，这样才能确保启动的时候，是有数据的，即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空

redis 主从复制的核心原理

• 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node，如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制，此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件

• 同时还会将从客户端 client 新收到的所有写命令缓存在内存中，RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中

• 接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据

• slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据

分区

Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个 Redis 的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）

为什么要做 Redis 分区？

分区可以让 Redis 管理更大的内存，Redis 将可以使用所有机器的内存，如果没有分区，你最多只能使用一台机器的内存，分区使 Redis的计算能力通过简单地增加计算机得到成倍提升，Redis 的网络带宽也会随着计算机和网卡的增加而成倍增长

你知道有哪些Redis分区实现方案？

• 客户端分区就是在客户端就已经决定数据会被存储到哪个 redis 节点或者从哪个 redis节点读取，大多数客户端已经实现了客户端分区

• 代理分区意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据，代理根据分区规则决定请求哪些 Redis 实例，然后根据 Redis 的响应结果返回给客户端，redis 和 memcached 的一种代理实现就是 Twemproxy

• 查询路由 (Query routing) 的意思是客户端随机地请求任意一个 redis 实例，然后由Redis将请求转发给正确的Redis节点，Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接 redirected到正确的 redis 节点

Redis分区有什么缺点？

涉及多个 key 的操作通常不会被支持，例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例

同时操作多个key，则不能使用Redis事务

分区使用的粒度是 key，不能使用一个非常长的排序 key 存储一个数据集

当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的 Redis 实例和主机同时收集 RDB / AOF文件

分区时动态扩容或缩容可能非常复杂，Redis 集群在运行时增加或者删除Redis 节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性，然而，有一种预分片的技术也可以较好的解决这个问题

分布式问题

Redis实现分布式锁

• Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对 Redis 的连接并不存在竞争关系，Redis 中可以使用SETNX 命令实现分布式锁。

• 当且仅当 key 不存在，将 key 的值设为 value， 若给定的 key 已经存在，则 SETNX 不做任何动作

• 使用SETNX命令获取锁，若返回 0，key已存在，锁已存在，则获取失败，反之获取成功，为了防止获取锁后程序出现异常，导致其他线程/进程调用 SETNX 命令总是返回 0 而进入死锁状态，需要为该 key 设置一个合理的过期时间释放锁，使用 DEL 命令将锁数据删除

如何解决 Redis 的并发竞争 Key 问题

• 所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同

• 推荐一种方案：分布式锁

  • 如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能
  • 基于 zookeeper 临时有序节点可以实现的分布式锁，大致思想为：每个客户端对某个方法加锁时，在 zookeeper 上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点，判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个，当释放锁的时候，只需将这个瞬时节点删除即可，同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题，完成业务流程后，删除对应的子节点释放锁
  • 在实践中，当然是从以可靠性为主。所以首推 Zookeeper

分布式 Redis 是前期做还是后期规模上来了再做好？为什么？

既然 Redis 是如此的轻量（单实例只使用1M内存），为防止以后的扩容， 好的办法就是一开始就启动较多实例，即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例

一开始就多设置几个Redis实例，例如 32 或者 64 个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的，这样的话，当你的数据不断增长，需要更多的 Redis 服务器时，你需要做的就是仅仅将 Redis 实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题），一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器

什么是 RedLock

Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全，它可以保证以下特性

• 安全特性：互斥访问，即永远只有一个 client 能拿到锁
• 避免死锁： 最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
• 容错性：只要大部分 Redis 节点存活就可以正常提供服务缓存异常缓存雪崩

什么是缓存雪崩

缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉

解决方案

• 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
• 一般并发量不是特别多的时候，使用多的解决方案是加锁排队
• 给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存

缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉

解决方案

• 接口层增加校验，如用户鉴权校验，id 做基础校验，id <= 0 的直接拦截
• 从缓存取不到的数据，在数据库中也没有取到，这时也可以将 key-value 对写为 key-null，缓存有效时间可以设置短点，如30秒，设置太长会导致正常情况也没法使用，这样可以防止攻击用户反复用同一个 id 暴力攻击
• 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力

布隆过滤器（推荐）

当一个元素加入布隆过滤器中的时候，会进行如下操作：

1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）
2. 根据得到的哈希值，在位数组中把对应下标的值置为 1

当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行如下操作

1. 对给定元素再次进行相同的哈希计算
2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中

不同的字符串可能哈希出来的位置相同，这种情况我们可以适当增加位数组大小或者调整我们的哈希函数

布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在

缓存击穿

缓存击穿是指缓存中没有但数据库中有的数据，一般是缓存时间到期，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力，和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库

解决方案

1.设置热点数据永远不过期

2.加互斥锁，互斥锁缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统，这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据

解决方案

1. 直接写个缓存刷新页面，上线时手工操作一下

2. 数据量不大，可以在项目启动的时候自动进行加载

3. 定时刷新缓存

缓存降级

当访问量剧增、服务出现问题，如响应时间慢或不响应，或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务，系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级

缓存降级的最终目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的

1. 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级

2. 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警

3. 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级

4. 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级

服务降级的目的，是为了防止 Redis 服务故障，导致数据库跟着一起发生雪崩问题，因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis 出现问题，不去数据库查询，而是直接返回默认值给用户

热点数据和冷数据

缓存热点数据才有价值，对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大，频繁修改的数据，看情况考虑使用缓存，对于热点数据，比如我们的某 IM 产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次，再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次

数据更新前至少读取两次，缓存才有意义，这个是基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了

那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力

缓存热点key

缓存中的一个 Key，比如一个促销商品，在某个时间点过期的时候，恰好在这个时间点对这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮

解决方案对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁，其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询

Redis支持的Java客户端都有哪些？

Redisson、Jedis、lettuce等等，官方推荐使用Redisson

Redis和Redisson有什么关系？

Redisson是一个高级的分布式协调 Redis 客服端，能帮助用户在分布式环境中轻松实现一些Java的对象

• Bloom filter、BitSet、Set、SetMultimap、ScoredSortedSet、SortedSet
• Map、ConcurrentMap、List、ListMultimap
• Queue、BlockingQueue、Deque、BlockingDeque
• Semaphore、Lock、ReadWriteLock、AtomicLong、CountDownLatch
• Publish / Subscribe
• HyperLogLog

Jedis与Redisson对比有什么优缺点？

• Jedis 是 Redis的 Java 实现的客户端，其API提供了比较全面的Redis命令的支持
• Redisson 实现了分布式和可扩展的 Java 数据结构，和 Jedis 相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性
• Redisson的宗旨是促进使用者对 Redis 的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上

其他问题

Redis 与 Memcached的区别

两者都是非关系型内存键值数据库，现在公司一般都是用 Redis 来实现缓存， 主要有以下不同

• Memcached 所有的值均是简单的字符串，Redis 作为其替代者，支持更为丰富的数据类型

• Redis 的速度比 Memcached 快很多

• Redis 可以持久化其数据

如何保证缓存与数据库双写时的数据一致性？

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？一般来说，就是如果你的系统不是严格要求缓存 + 数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况， 最好不要做这个方案：读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求

还有一种方式就是可能会暂时产生不一致的情况，但是发生的几率特别小，就是先更新数据库，然后再删除缓存

Redis常见性能问题和解决方案？

• Master 好不要做任何持久化工作，包括内存快照和 AOF 日志文件，特别是不要启用内存快照做持久化
• 如果数据比较关键，某个 Slave 开启 AOF 备份数据，策略为每秒同步一次
• 为了主从复制的速度和连接的稳定性，Slave 和 Master 好在同一个局域网内
• 尽量避免在压力较大的主库上增加从库
• Master 调用 BGREWRITEAOF 重写 AOF 文件，AOF 在重写的时候会占大量的 CPU 和内存资源，导致服务 load 过高，出现短暂服务暂停现象
• 为了 Master 的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现 Slave 对 Master 的替换，也即，如果Master 挂了，可以立马启用 Slave1做 Master，其他不变

一个字符串类型的值能存储最大容量是多少？

512M

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

• 使用 keys 指令可以扫出指定模式的 key 列表

• 对方接着追问：如果这个 redis 正在给线上的业务提供服务，那使用 keys 指令会有什么问题？这个时候你要回答redis关键的一个特性：redis的单线程的，keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复

• 这个时候可以使用 scan 指令，scan 指令可以无阻塞的提取出指定模式的 key 列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用 keys 指令长

使用Redis做过异步队列吗，是如何实现的

• 使用 list 类型保存数据信息，rpush生产消息，lpop消费消息，当lpop没有消息时，可以sleep一段时间，然后再检查有没有信息，如果不想sleep的话，可以使用blpop, 在没有信息的时候，会一直阻塞，直到信息的到来
• redis可以通过 pub/sub主题订阅模式实现一个生产者，多个消费者，当然也存在一定的缺点，当消费者下线时，生产的消息会丢失

Redis如何实现延时队列

使用 sortedset，使用时间戳做 score, 消息内容作为 key，调用 zadd 来生产消息，消费者使用 zrangbyscore 获取 n 秒之前的数据做轮询处理

Redis回收进程如何工作的？

• 一个客户端运行了新的命令，添加了新的数据

• Redis检查内存使用情况，如果大于 maxmemory 的限制， 则根据设定好的策略进行回收

• 一个新的命令被执行，等等

• 所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下