Redis知识体系

1、基于内存操作，操作不需要跟磁盘交互

2、本身就是k-v结构，类似于hashMap，所以查询速度接近O(1)

3. 同时redis自己底层数据结构支持，比如跳表、SDS

4. 命令执行是单线程，同时通信采用多路复用

5. lO多路复用，单个线程中通过记录跟踪每一个sock（I/O流）  的状态来 
管理多个I/O流  。

更丰富的数据类型  ，虽然都是k、v结构， value可以存储很多的数据类 
型

完善的内存管理机制、保证数据一致性：持久化机制、过期策略

支持多种编程语言

高可用，集群、保证高可用

基本指令

应用场景

存储有序的字符串列表，元素可以重复。列表的最大长度为 2^32 - 1 个元 
素（4294967295，每个列表超过 40 亿个元素）。

基本指令

使用场景

基本指令

应用场景

String类型的无序集合，最大存储数量 2^32-1（40 亿左右）。  并且他们的 
添加、删除元素的时间都是O（1）。

基本指令

应用场景

有序的set，每个元素有个score。

基本指令

应用场景

位图不是实际的数据类型，而是String类型中定义的一种面向位的操作，所 
以这个位图的最大长度是512M。
可以容纳最少2^32 不同的位。可以在不同的位置设置0或者1

基本指令

应用场景

save命令：执行SAVE命令时，Redis服务器会阻塞客户端命令，直到rdbSave函数完成RDB文件的创建。由于这种方式会阻塞Redis服务器，导致无法处理其他客户端请求，因此在线上环境中一般不推荐使用

bgsave命令：BGSAVE命令通过主线程的fork创建一个子进程来执行rdbSave函数，而父进程（Redis服务器主进程）正常处理客户端的请求。这样Redis持久化操作就不会影响到正常的服务提供。子进程遍历Redis内存中所有的键值对，并使用rdbSaveObject等函数将每个对象进行二进制序列化写入到RDB文件。序列化过程中，Redis会对数据进行压缩，以加快写入文件的速度，并减少文件体积。RDB文件创建完成后，子进程会向父进程发送信号，通知父进程RDB文件创建完成

自动触发：自动触发可以在redis.conf配置文件中设置，当满足特定的条件时，会自动触发持久化。触发后，底层调用的其实是bgsave命令。条件包括：900秒（15分钟）内至少有1个key的值发生变化；300秒（5分钟）内至少有10个key的值发生变化；60秒（1分钟）内至少有10000个key的值发生变化。

恢复速度快：由于RDB文件是一个紧凑的二进制文件，文件体积小，加载速度快。因此恢复数据的速度比AOF快

文件体积小：RDB文件在写入前进行了压缩，因此文件体积小，有利于文件传输和备份

适合灾备恢复：RDB文件体积小，适合文件传输到其他存储介质上，非常适合用于灾备恢复

数据丢失风险：若Redis在两次RDB持久化之间发生故障，则最后一次RDB持久化后的数据就会丢失（数据不一致）

内存占用：在fork创建的子进程进行RDB持久化过程中，子进程会占用与父进程相同的内存资源，可能会导致Redis性能下降

版本兼容：RDB文件为一个二进制文件，不同版本的Redis之间可能存在兼容性问题

命令追加：当AOF持久化开启时，服务器在执行完一个写命令后，Redis不会直接阻塞服务器来等待AOF文件写入完成。Redis采用异步写入策略，会将这个命令以RESP协议格式追加到AOF缓冲区（aof_buf，一个内存中的数据结构）中

文件写入：Redis服务器进程是一个事件循环，在每个事件循环结束前，会使用后台一个线程（或进程）会调用flushAppendOnlyFile函数将AOF缓冲区（aof_buf）中的命令内容写到AOF文件中。这个后台过程不会阻塞Redis主线程处理新的命令

文件同步：AOF文件会根据appendfsync参数设置的持久化策略同步到磁盘。appendfsync的参数包括

文件重写：随着服务器运行时间增加，AOF文件会越来越大，这会影响Redis重启时间。因此Redis提供了AOF重写机制，通过创建一个新的AOF文件来替代旧文件，新文件只包含恢复当前数据集所需的最小命令集。重写过程也是异步进行的，并且不会阻塞Redis处理新命令。重写操作由后台子进程进行，不阻塞主进程处理客户端的命令。重写期间，新的写命令会被同时追加到现有AOF文件和重写文件的AOF缓存区（aof_buf）中。重写完成后，主进程会将重写缓存区中的命令追加到新的AOF文件中，并替代旧文件

重启加载：Redis重启后，会加载AOF文件，并重新执行文件中写命令来恢复内存数据

数据完整性高：AOF文件包含了每个写操作的详细记录，提供了更好的数据恢复能力

灵活性高：可以通过配置appendfsync参数来平衡数据安全和写入性能

写入性能损失：每个写操作都需要被追加到AOF缓冲区和写入磁盘，可能会增加写入操作的延迟

AOF文件可能过大：随着服务器运行时间的增加，AOF文件会越来越大，影响Redis的重启时间和性能。不过，Redis提供了AOF重写机制来优化AOF文件的大小

恢复速度快：由于结合了RDB快照的快速加载特性，混合持久化在恢复数据时速度更快

数据完整性高：通过结合AOF日志的详细记录特性，混合持久化提供了更高的数据完整性

数据量较大：当Redis数据库中存储的数据量较大时，使用RDB快照可以生成一个紧凑的二进制文件，该文件包含了数据库在某个时间点的数据快照

对数据完整性要求不高：如果对数据一致性要求不是特别高，可以容忍少量的数据丢失，RDB快照是一个很好的选择。因为RDB是基于时间间隔的持久化，可能在两次快照之间会有数据丢失

需要快速恢复：由于RDB文件是压缩的二进制文件，恢复时速度较快，适用于需要快速恢复数据的场景

对数据完整性要求高：如果应用程序对数据一致性要求非常高，不能容忍数据丢失，那么应该选择AOF日志持久化。因为AOF记录了每个写操作命令，通过重新执行这些命令可以恢复数据到最新状态

可以接受性能损耗：AOF日志持久化在写入性能方面可能会有一些损失，因为每个写操作都需要被追加到AOF缓冲区和写入磁盘。因此，如果应用程序可以接受一定的性能损耗，那么可以选择AOF日志持久化

对数据安全性和性能要求均高：如果应用程序既需要确保数据的安全性，又需要保证Redis的性能，那么可以选择混合持久化。混合持久化在恢复数据时，可以先加载RDB快照快速恢复大部分数据，然后再重放AOF日志中的写操作来恢复剩余的数据

需要快速恢复数据并减少故障恢复时间：混合持久化可以缩短Redis的启动时间，因为RDB快照提供了数据的快速加载，而AOF日志则确保了数据的完整性

提高主从同步效率：在主从复制场景中，混合持久化可以提高主从同步的效率，因为从节点可以先加载RDB快照快速同步大部分数据，然后再通过AOF日志同步增量数据

如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC
命令给master请求复制数据。
master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期
间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完
毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后
再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多
个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送
给多个并发连接的slave。

数据分片

高可用

可扩展

节点互联：
所有Redis节点使用PING-PONG机制进行互联，通过心跳检测来维护节点间的连接状态。
集群中某个节点的失效，需要整个集群中超过半数的节点监测都失效才算真正的失效。
客户端连接：
客户端不需要中间代理层（proxy），可以直接连接集群中的任意一个可用节点。
客户端发送命令时，接收命令的节点会根据键名计算出命令要处理的数据库键属于哪个哈希槽。如果刚好是当前槽，则节点直接执行命令；否则，节点会返回一个MOVED错误，指引客户端转向至正确的节点。
数据迁移：
Redis Cluster的重新分片操作可以将任意数量已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点），并且相关槽所属的键值对也会从源节点被移动到目标节点。
该过程可以在线进行，由redis-trib负责执行，包括准备迁移、获取键名、迁移键值对和更新集群状态等步骤。

优点：
数据分布均衡，能够动态调整数据分布。
无中心架构，提高了系统的可扩展性和可用性。
提供了集群管理工具redis-trib，简化了集群管理的工作。

缺点：数据通过异步复制，不保证数据的强一致性。
客户端实现相对复杂，需要处理MOVED和ASK等重定向错误。
不支持跨节点的事务，只支持单节点的事务。
部分Redis命令在集群模式下不支持，如KEYS、SCAN等命令