Redis知识点（1）
目录
Redis
Redis和MySQL的区别
Redis的高可用方案
Redis可以用来做什么
Redis的数据类型
字符串
列表
哈希
集合
有序集合
Bitmap
Redis为什么快呢？
I/O多路复用
说说select,poll,epoll,kqueue,IOCP的区别
Redis为什么早期选择单线程？
Redis6.0的多线程
Redis的常用命令
set命令
sadd命令的时间复杂度
incr命令
单线程的RedisQPS能到多少？
持久化
Redis的持久化方式有哪些
RDB
bgsave 命令会在后台 fork 一个子进程来执行 RDB 持久化操作，主进程不会被阻塞。
什么情况下会触发？
AOF
AOF的刷盘策略
AOF的重写机制
AOF文件存储的是什么类型的数据
RDB和AOF的各自优缺点
RDB和AOF如何选择
Redis如何恢复数据？
Redis的混合持久化
高可用
主从复制
主从复制的主要作用
什么情况出现主从复制数据不一样？
解决方案
Redis主从有几种常见的拓扑结构
Redis的主从复制原理
全量同步和增量同步
主从复制存在哪些问题？
脑裂问题
Redis哨兵机制
Redis哨兵的工作原理
Redis的集群
Redis Cluster
集群中数据如何分区？
Redis集群的原理
部署Redis集群至少需要3个物理节点
Redis集群的动态伸缩
Redis
redis是一种键值对的NoSQL数据库。
主要是把数据放在内存当中，相比直接访问磁盘的关系型数据库，读写速度会快很多，基本上能达到微妙级的响应。
所以在一些性能要求很高的场景，比如缓存热点数据，防止接口爆刷，都会用到Redis.
不仅如此，Redis还可支持持久化，可以将内存中的数据异步落盘，以便服务宕机重启后能恢复数据。
Redis和MySQL的区别
Redis属于非关系型数据库，数据是通过键值对的形式放在内存当中的；MySQL属于关系型数据库，数据以行和列的形式存储在磁盘当中。
实际开发中，会将 MySQL 作为主存储，Redis 作为缓存，通过先查 Redis，未命中再查 MySQL 并写回Redis 的方式来提高系统的整体性能。
Redis的高可用方案
哨兵机制，这是一个相对成熟的高可用的解决方案，我们生产环境部署的是一主两从的Redis实例，再加上三个Sentinel节点监控它们。Sentinel的配置相对简单，主要设置了故障转移的判定条件和超时阈值。
Redis Cluster 集群方案该项目数据量大且增长快，需要水平扩展能力。我们部署了 6 个主节点，每个主节点配备一个从节点，形成了一个 3主3从 的初始集群。Redis Cluster 的设置比 Sentinel 复杂一些，需要正确配置集群节点间通信、分片映射等。
Redis Cluster 最大的优势是数据自动分片，我们可以通过简单地增加节点来扩展集群容量。此外，它的故障转移也很快，通常在几秒内就能完成。
Redis可以用来做什么
Redis可以用来做缓存，比如把高频访问的文章详情，商品信息，用户信息放入Redis当中，并通过设置过期时间来保证数据的一致性，这样可以减轻数据库的访问压力。
Redis 的 Zset 还可以用来实现积分榜、热搜榜，通过 score 字段进行排序，然后取前 N 个元素，就能实现 TOPN 的榜单功能。
利于Redis的SETNX命令或者Redission号可以实现分布式锁，确保同一时间只有一个节点可以持有锁；为了防止出现死锁，可以给锁设置一个超时时间，到期后自动释放；并且最好开启一个监听线程，当任务尚未完成时给锁自动续期。
如果是秒杀接口，还可以使用 Lua 脚本来实现令牌桶算法，限制每秒只能处理 N 个请求。
Redis的数据类型
Redis支持五种基本类型。分别是字符串，列表，哈希，集合和有序集合。
字符串
字符串是基本的数据类型，可以存储文本，数字或者二进制数据，最大容量是512MB。
适合缓存单个对象，比如验证码、token、计数器等。
列表
列表是一个有序的元素集合，支持从头部或尾部插入/删除元素，常用于消息队列或任务列表。
哈希
哈希是一个键值对集合，适合存储对象，如商品信息、用户信息等。
集合
集合是无序且不重复的，支持交集，并集操作，查询效率能达到O（1）级别，主要用于去重，标签，共同好友等场景。
有序集合
有序集合的元素安装分数进行排序，支持范围查询，适用于排行榜或优先级队列
Bitmap
Bitmap 可以把一组二进制位紧凑地存储在一块连续内存中，每一位代表一个对象的状态，比如是否签到、是否活跃等。
比如用户 0 的已签到 1、用户 1 未签到 0、用户 2 已签到，Redis 就会把这些状态放进一个连续的二进制串 101，1 亿用户签到仅需 100,000,000 / 8 / 1024 ≈ 12MB 的空间，真的省到离谱。
Redis为什么快呢？
第一，Redis 的所有数据都放在内存中，而内存的读写速度本身就比磁盘快几个数量级。
第二，Redis 采用了基于 IO 多路复用技术的事件驱动模型来处理客户端请求和执行 Redis 命令。
其中的 IO 多路复用技术可以在只有一个线程的情况下，同时监听成千上万个客户端连接，解决传统 IO 模型中每个连接都需要一个独立线程带来的性能开销。IO 多路复用会持续监听请求，然后把准备好的请求压入到一个队列当中，并将其有序地传递给文件事件分派器，最后由事件处理器来执行对应的 accept、read 和 write 请求。
第三，Redis 对底层数据结构做了极致的优化，比如说 String 的底层数据结构动态字符串支持动态扩容、预分配冗余空间，能够减少内存碎片和内存分配的开销。
I/O多路复用
IO 多路复用是一种允许单个进程同时监视多个文件描述符的技术，使得程序能够高效处理多个并发连接而无需创建大量线程。
I/O多路复用的核心：让单个线程可以等待多个文件描述符就绪，然后对就绪的描述符进行操作。这样可以在不使用多线程或多进程的情况下处理并发连接。
说说select,poll,epoll,kqueue,IOCP的区别
select 的缺点是单个进程能监视的文件描述符数量有限，一般为1024个，且每次调用都需要将文件描述符集合从用户态复制到内核态，然后遍历找出就绪的描述符，性能较差
poll的优点是没有最大文件描述符数量的限制，但是每次调用仍然需要将文件描述符集合从用户态复制到内核态，依然需要遍历，性能仍然较差。
epoll 是 Linux 特有的 IO 多路复用机制，支持大规模并发连接，使用事件驱动模型，性能更高。其工作原理是将文件描述符注册到内核中，然后通过事件通知机制来处理就绪的文件描述符，不需要轮询，也不需要数据拷贝，更没有数量限制，所以性能非常高。
kqueue 是 BSD/macOS 系统下的 IO 多路复用机制，类似于 epoll，支持大规模并发连接，使用事件驱动模型。
IOCP 是 Windows 系统下的 IO 多路复用机制，使用使用完成端口模型而非事件通知。
Redis为什么早期选择单线程？
第一，单线程模型不需要考虑复杂的锁机制，不存在多线程下的死锁，竞态条件等问题，开发起来更快，也更容易维护。
第二，Redis是IO密集型而非CPU密集型，主要受内存和网络IO限制，非CPU的计算能力，单线程可以避免上下文切换的开销。
第三 单线程可以保证命令执行的原子性，无需额外的同步机制。
Redis6.0的多线程
Redis 6.0 的多线程仅用于处理网络 IO，包括网络数据的读取、写入，以及请求解析。
而命令的执行依然是单线程，这种设计被称为IO线程化，能够在高负载的情况下，最大限度地提升Redis的响应速度。
Redis的常用命令
操作字符串可以用Set/get/incr，操作哈希可以用hset,hget,hgetall，操作列表可以用 LPUSH/LPOP/LRANGE，操作集合可以用 SADD/SISMEMBER，操作有序集合可以用 ZADD/ZRANGE/ZINCRBY等，通用命令有 EXPIRE/DEL/KEYS 等。
set命令
set命令用于设置字符串的key,支持过期时间和条件写入，常用于设置缓存、实现分布式锁、延长 Session 等场景。
sadd命令的时间复杂度
SADD 支持一次添加多个元素，返回值为实际添加成功的元素数量，时间复杂度为 O(N)。
incr命令
INCR 是一个原子命令，可以将指定键的值加 1，如果 key 不存在，会先将其设置为 0，再执行加 1 操作。
单线程的RedisQPS能到多少？
一个普通服务器的 Redis 实例通常可以达到每秒十万左右的 QPS。
持久化
Redis的持久化方式有哪些
主要有两种，RDB 和 AOF。RDB 通过创建时间点快照来实现持久化，AOF 通过记录每个写操作命令来实现持久化。
这两种方式可以单独使用，也可以同时使用。这样就可以保证 Redis 服务器在重启后不丢失数据，通过 RDB 和 AOF 文件来恢复内存中原有的数据。
RDB
RDB持久化机制可以在指定的时间间隔内将Redis某一时刻的数据保存到磁盘上的RDB文件中，当Redis重启，可以通过加载这个RDB文件来恢复数据。
RDB 持久化可以通过 save 和 bgsave 命令手动触发，也可以通过配置文件中的 save 指令自动触发。
save 命令会阻塞 Redis 进程，直到 RDB 文件创建完成。
bgsave 命令会在后台 fork 一个子进程来执行 RDB 持久化操作，主进程不会被阻塞。
什么情况下会触发？
第一种，在 Redis 配置文件中设置 RDB 持久化参数 save <seconds> <changes>，表示在指定时间间隔内，如果有指定数量的键发生变化，就会自动触发 RDB 持久化。
第二种，主从复制时，当从节点第一次连接到主节点时，主节点会自动执行 bgsave 生成 RDB 文件，并将其发送给从节点。
第三种，如果没有开启 AOF，执行 shutdown 命令时，Redis 会自动保存一次 RDB 文件，以确保数据不会丢失。
AOF
AOF 通过记录每个写操作命令，并将其追加到 AOF 文件来实现持久化，Redis 服务器宕机后可以通过重新执行这些命令来恢复数据。
当 Redis 执行写操作时，会将写命令追加到 AOF 缓冲区；Redis 会根据同步策略将缓冲区的数据写入到 AOF 文件。
当 AOF 文件过大时，Redis 会自动进行 AOF 重写，剔除多余的命令，比如说多次对同一个 key 的 set 和 del，生成一个新的 AOF 文件；当 Redis 重启时，读取 AOF 文件中的命令并重新执行，以恢复数据。
AOF的刷盘策略
Redis 将 AOF 缓冲区的数据写入到 AOF 文件时，涉及两个系统调用：write 将数据写入到操作系统的缓冲区，fsync 将 OS 缓冲区的数据刷新到磁盘。
这里的刷盘涉及到三种策略：always、everysec 和 no。
- always：每次写命令执行完，立即调用 fsync 同步到磁盘，这样可以保证数据不丢失，但性能较差。
- everysec：每秒调用一次 fsync，将多条命令一次性同步到磁盘，性能较好，数据丢失的时间窗口为 1 秒。
- no：不主动调用 fsync，由操作系统决定，性能最好，但数据丢失的时间窗口不确定，依赖于操作系统的缓存策略，可能会丢失大量数据。
AOF的重写机制
由于 AOF 文件会随着写操作的增加而不断增长，为了解决这个问题， Redis 提供了重写机制来对 AOF 文件进行压缩和优化。
AOF 重写可以通过两种方式触发，第一种是手动执行 BGREWRITEAOF 命令，适用于需要立即减小AOF文件大小的场景。
第二种是在 Redis 配置文件中设置自动重写参数，比如说 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，表示当 AOF 文件大小超过指定值时，自动触发重写。
AOF文件存储的是什么类型的数据
AOF存储的是Redis服务器接受到的写命令数据，以Redis协议格式保存。
RDB和AOF的各自优缺点
RDB 通过 fork 子进程在特定时间点对内存数据进行全量备份，生成二进制格式的快照文件。其最大优势在于备份恢复效率高，文件紧凑，恢复速度快，适合大规模数据的备份和迁移场景。
缺点是可能丢失两次快照期间的所有数据变更。
AOF 会记录每一条修改数据的写命令。这种日志追加的方式让 AOF 能够提供接近实时的数据备份，数据丢失风险可以控制在 1 秒内甚至完全避免。
缺点是文件体积较大，恢复速度慢。
RDB和AOF如何选择
如果是缓存场景，可以接受一定程度的数据丢失，我会倾向于选择 RDB 或者完全不使用持久化。RDB 的快照方式对性能影响小，而且恢复速度快，非常适合这类场景。
但如果是处理订单或者支付这样的核心业务，数据丢失将造成严重后果，那么 AOF 就成为必然选择。通过配置每秒同步一次，可以将潜在的数据丢失风险限制在可接受范围内。
在实际的项目当中，我更偏向于使用 RDB + AOF 的混合模式。
Redis如何恢复数据？
当 Redis 服务重启时，它会优先查找 AOF 文件，如果存在就通过重放其中的命令来恢复数据；如果不存在或未启用 AOF，则会尝试加载 RDB 文件，直接将二进制数据载入内存来恢复。
Redis的混合持久化
混合持久化结合了 RDB 和 AOF 两种方式的优点，解决了它们各自的不足。在 Redis 4.0 之前，我们要么面临 RDB 可能丢失数据的风险，要么承受 AOF 恢复慢的问题，很难两全其美。
混合持久化的工作原理非常巧妙：在 AOF 重写期间，先以 RDB 格式将内存中的数据快照保存到 AOF 文件的开头，再将重写期间的命令以 AOF 格式追加到文件末尾。
这样，当需要恢复数据时，Redis 先加载 RDB 格式的数据来快速恢复大部分的数据，然后通过重放命令恢复最近的数据，这样就能在保证数据完整性的同时，提升恢复速度。
高可用
主从复制
主从复制允许从节点维护主节点的数据副本。在这种架构中，一个主节点可以连接多个从节点，从而形成一主多从的结构。主节点负责处理写操作，从节点自动同步主节点的数据变更，并处理读请求，从而实现读写分离。
主从复制的主要作用
第一，主节点负责处理写请求，从节点负责处理读请求，从而实现读写分离，减轻主节点压力的同时提升系统的并发能力
第二 从节点可以作为主节点的数据备份，当主节点发生故障时，可以快速将从节点提升为新的主节点，从而保证系统的高可用
什么情况出现主从复制数据不一样？
Redis的主从复制是异步进行的，因此在主节点宕机，网络波动或复制延迟较高时会出现从节点数据不同步的情况
比如主节点写入数据后宕机，但从节点还未来得及复制，就会出现数据不一致。
另一个容易被忽视的因素是主节点内存压力。当主节点内存接近上限并启用了淘汰策略时，某些键可能被自动删除，而这些删除操作如果未能及时同步，就会造成从节点保留了主节点已经不存在的数据。
解决方案
首先是网络层面的优化，理想情况下，主从节点应该部署在同一个网络区域内，避免跨区域的网络延迟。
其次是配置层面的调整，比如说适当增大复制积压缓冲区的大小和存活时间，以便从节点重连后进行增量同步而不是全量同步，以最大程度减少主从同步的延迟。
第三是引入监控和自动修复机制，定期检查主从节点的数据一致性。
Redis主从有几种常见的拓扑结构
主要有三种
最最基础的是一主一从，这种模式适合小型项目。一个主节点负责写入，一个从节点负责读和数据备份。
一主多从
随着业务增长，读请求增多，主节点负责写入，多个从节点还可以分摊压力。
树状主从
在跨地域部署场景中，树状主从结构可以有效降低主节点负载和需要传送给从节点的数据量。通过引入复制中间层，从节点不仅可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。
Redis的主从复制原理
Redis的主从复制是指通过异步复制将主节点的数据变更到从节点，从而实现数据备份和读写分离，这个过程大致可以分为三个阶段：建立连接、同步数据和传播命令。
在建立连接阶段，从节点通过执行 replicaof 命令连接到主节点。连接建立后，从节点向主节点发送 psync 命令，请求数据同步。这时主节点会为该从节点创建一个连接和复制缓冲区。
同步数据阶段分为全量同步和增量同步。当从节点首次连接主节点时，会触发全量同步。
在这个过程中，主节点会 fork 一个子进程生成 RDB 文件，同时将文件生成期间收到的写命令缓存到复制缓冲区。然后将 RDB 文件发送给从节点，从节点清空自己的数据并加载这个 RDB 文件。等 RDB 传输完成后，主节点再将缓存的写命令发送给从节点执行，确保数据完全一致。
主从完成全量同步后，主要依靠传播命令阶段来保持数据的增量同步。主节点会将每次执行的写命令实时发送给所有从节点。
全量同步和增量同步
全量同步会将主节点的完整数据集传输给从节点，通常全量同步的代价很高，因为完整的 RDB 文件在生成时会占用大量的 CPU 和磁盘 IO；在网络传输时还会消耗掉不少带宽。全量同步会将主节点的完整数据集传输给从节点，通常发生在从节点首次连接主节点时。
于是 Redis 在 2.8 版本后引入了增量同步的概念，目的是在断线重连后避免全量同步。
①、复制偏移量：主从节点分别维护一个复制偏移量，记录传输的字节数。主节点每传输 N 个字节数据，自身的复制偏移量就会增加 N；从节点每收到 N 个字节数据，也会相应增加自己的偏移量。
②、主节点 ID：每个主节点都有一个唯一 ID，即复制 ID，用于标识主节点的数据版本。当主节点发生重启或者角色变化时，ID 会改变。
③、复制积压缓冲区：主节点维护的一个固定长度的先进先出队列，默认大小为 1M。主节点在向从节点发送命令的同时，也会将命令写入这个缓冲区。
主从复制存在哪些问题？
Redis 主从复制的最大挑战来自于它的异步特性，主节点处理完写命令后会立即响应客户端，而不会等待从节点确认，这就导致在某些情况下可能出现数据不一致。
另一个常见问题是全量同步对系统的冲击。全量同步会占用大量的 CPU 和 IO 资源，尤其是在大数据量的情况下，会导致主节点的性能下降。、
脑裂问题
在 Redis 的哨兵架构中，脑裂的典型表现为：主节点与哨兵、从节点之间的网络发生故障了，但与客户端的连接是正常的，就会出现两个“主节点”同时对外提供服务。
哨兵认为主节点已经下线了，于是会将一个从节点选举为新的主节点。但原主节点并不知情，仍然在继续处理客户端的请求。
等主节点网络恢复正常了，发现已经有新的主节点了，于是原主节点会自动降级为从节点。在降级过程中，它需要与新主节点进行全量同步，此时原主节点的数据会被清空。导致客户端在原主节点故障期间写入的数据全部丢失。
Redis哨兵机制
Redis 中的哨兵用于监控主从集群的运行状态，并在主节点故障时自动进行故障转移。
核心功能包括监控、通知和自动故障转移。哨兵会定期检查主从节点是否按预期工作，当检测到主节点故障时，就在从节点中选举出一个新的主节点，并通知客户端连接到新的主节点。
Redis哨兵的工作原理
哨兵的工作原理可以概括为 4 个关键步骤：定时监控、主观下线、领导者选举和故障转移。
首先，哨兵会定期向所有 Redis 节点发送 PING 命令来检测它们是否可达。如果在指定时间内没有收到回复，哨兵会将该节点标记为“主观下线。
当一个哨兵判断主节点主观下线后，会询问其他哨兵的意见，如果达到配置的法定人数，主节点会被标记为“客观下线”。
然后开始故障转移，这个过程中，哨兵会先选举出一个领导者，领导者再从从节点中选择一个最适合的节点作为新的主节点，选择标准包括复制偏移量、优先级等因素。
确定新主节点后，哨兵会向其发送 SLAVEOF NO ONE 命令使其升级为主节点，然后向其他从节点发送 SLAVEOF 命令指向新主节点，最后通过发布/订阅机制通知客户端主节点已经发生变化。
Redis的集群
主从复制实现了读写分离和数据备份，哨兵机制实现了主节点故障时自动进行故障转移。
集群架构是对前两种方案的进一步扩展和完善，通过数据分片解决 Redis 单机内存大小的限制，当用户基数从百万增长到千万级别时，我们只需简单地向集群中添加节点，就能轻松应对不断增长的数据量和访问压力。
Redis Cluster
Redis Cluster 是 Redis 官方提供的一种分布式集群解决方案。其核心理念是去中心化，采用 P2P 模式，没有中心节点的概念。每个节点都保存着数据和整个集群的状态，节点之间通过 gossip 协议交换信息。
在数据分片方面，Redis Cluster 使用哈希槽机制将整个集群划分为 16384 个单元。
集群中数据如何分区？
常见的数据分区有三种：节点取余、一致性哈希和哈希槽。
节点取余分区简单明了，通过计算键的哈希值，然后对节点数量取余，结果就是目标节点的索引。
缺点是增加一个新节点后，节点数量从 N 变为 N+1，几乎所有的取余结果都会改变，导致大部分缓存失效。
为了解决节点变化导致的大规模数据迁移问题，一致性哈希分区出现了：它将整个哈希值空间想象成一个环，节点和数据都映射到这个环上。数据被分配到顺时针方向上遇到的第一个节点。
这种设计的巧妙之处在于，当节点数量变化时，只有部分数据需要重新分配。比如说我们从 5 个节点扩容到 8 个节点，理论上只有约 3/8 的数据需要迁移，大大减轻了扩容时的系统压力。
但一致性哈希仍然有一个问题：数据分布不均匀。比如说在上面的例子中，节点 1 和节点 2 的数据量差不多，但节点 3 的数据量却远远小于它们。
Redis Cluster 的哈希槽分区在一致性哈希和节点取余的基础上，做了一些改进。它将整个哈希值空间划分为 16384 个槽位，每个节点负责一部分槽，数据通过 CRC16 算法计算后对 16384 取模，确定它属于哪个槽。
假设系统中有 4 个节点，为其分配了 16 个槽(0-15)；
- 槽 0-3 位于节点 node1；
- 槽 4-7 位于节点 node2；
- 槽 8-11 位于节点 node3；
- 槽 12-15 位于节点 node4。
如果此时删除 node2，只需要将槽 4-7 重新分配即可，例如将槽 4-5 分配给 node1，槽 6 分配给 node3，槽 7 分配给 node4，数据在节点上的分布仍然较为均衡。
如果此时增加 node5，也只需要将一部分槽分配给 node5 即可，比如说将槽 3、槽 7、槽 11、槽 15 迁移给 node5，节点上的其他槽位保留。
因为槽的个数刚好是 2 的 14 次方，和 HashMap 中数组的长度必须是 2 的幂次方有着异曲同工之妙。它能保证扩容后，大部分数据停留在扩容前的位置，只有少部分数据需要迁移到新的槽上。
Redis集群的原理
Redis 集群的搭建始于节点的添加和握手。每个节点通过设置 cluster-enabled yes 来开启集群模式。然后通过 CLUSTER MEET 进行握手，将对方添加到各自的节点列表中。
这个过程设计的非常精巧：节点 A 发送 MEET 消息，节点 B 回复 PONG 并发送 PING，节点 A 回复 PONG，于是双向的通信链路就建立完成了。
有趣的是，由于采用了 Gossip 协议，我们不需要让每对节点都执行握手。在一个多节点集群的部署中，仅需要让第一个节点与其他节点握手，其余节点就能通过信息传播自动发现并连接彼此。
握手完成后，可以通过 CLUSTER ADDSLOTS 命令为主节点分配哈希槽。当 16384 个槽全部分配完毕，集群正式进入就绪状态。
故障检测和恢复是保障 Redis 集群高可用的关键。每秒钟，节点会向一定数量的随机节点发送 PING 消息，当发现某个节点长时间未响应 PING 消息，就会将其标记为主观下线。当半数以上的主节点都认为某节点主观下线时，这个节点就会被标记为“客观下线”。
如果下线的是主节点，它的从节点之一将被选举为新的主节点，接管原主节点负责的哈希槽。
部署Redis集群至少需要3个物理节点
Redis集群的动态伸缩
Redis 集群动态伸缩的核心机制是通过重新分配哈希槽实现的。当需要扩容时，首先通过 CLUSTER MEET 命令将新节点加入集群；然后使用 reshard 命令将部分哈希槽重新分配给新节点。