Redis淘汰策略

Redis 的 OBJECT 命令提供了多个子命令，用于检查有关键的内部详细信息。以下是可用的子命令及其描述：

1. ENCODING <key>：返回用于存储与键关联的值的内部表示类型。

2. FREQ <key>：返回键的访问频率索引。返回的整数与键的最近访问频率的对数成比例。

3. IDLETIME <key>：返回键的空闲时间，即自上次访问键以来经过的大约秒数，就是所谓的空转时长。

4. REFCOUNT <key>：返回键的引用计数。

您可以使用这些子命令来深入了解 Redis 如何存储和管理键，包括它们的编码、访问频率、空闲时间和引用计数。例如，您可以使用 OBJECT ENCODING <key> 来检查特定键的编码。类似地，您可以使用相应的子命令来检索特定键的访问频率、空闲时间和引用计数。

如果您有特定的键想要查询，可以在使用这些子命令时将 <key> 替换为实际的键名称，以检查特定键的详细信息。

使用expire设置key的过期时间，可以使用ttl查看他还能存活多久

Redis持久化

1. AOF持久化

AOF（Append Only File）持久化是 Redis 使用的一种持久化方式，它通过记录所有对 Redis 服务器进行写操作的命令，将这些命令追加到文件末尾，从而实现数据的持久化。

当 Redis 重启时，它会通过重新执行 AOF 文件中的命令来恢复数据。AOF 持久化的优点在于它提供了一种更加可靠的持久化方式，因为它记录了写操作本身，而不是记录数据的快照。这种方式下，即使发生意外情况导致 Redis 服务崩溃，也可以通过 AOF 文件中的命令来还原数据。

然而，AOF 持久化也有一些缺点，比如 AOF 文件可能会变得非常大，因为它记录了每一次写操作。为了解决这个问题，Redis 提供了 AOF 文件重写机制，可以对 AOF 文件进行压缩，去除冗余的命令，从而减小文件大小。

在 Redis 中，AOF 持久化有不同的同步策略，这些策略影响了命令何时被写入 AOF 文件。以下是几种常见的 AOF 同步策略：

1. Always（always）：每个写命令都立即被写入磁盘，这是最安全的策略，但也会导致性能下降。

2. Everysec（every second）：每秒钟将写命令同步到磁盘一次。这是默认的 AOF 同步策略，可以在一定程度上保证数据的安全性，同时也提供了较好的性能。

3. No（no）：Redis 不会主动进行 AOF 文件的同步操作，而是依赖操作系统来处理。这种方式下，操作系统通常会根据自身的策略来进行磁盘写入，可能会存在一定的数据丢失风险。

这些同步策略可以通过 Redis 配置文件中的 appendfsync 选项进行配置。选择合适的同步策略需要权衡数据安全性和性能之间的关系，以满足具体业务需求。

2. AOF重写

AOF重写是通过fork进程来实现的。AOF 重写的流程可以简单描述如下：

1. 触发AOF重写：Redis 会在后台自动触发 AOF 重写，也可以通过发送 BGREWRITEAOF 命令来手动触发。

2. 创建新的AOF文件：一旦 AOF 重写被触发，Redis 会开始创建一个新的 AOF 文件，通常以类似于 “temp-.aof” 的临时文件名的方式进行创建。

3. 记录新的写命令：在 AOF 重写过程中，Redis 会继续处理新的写命令请求，同时将这些写命令以命令的方式追加到新的 AOF 文件中，而不是直接复制旧的 AOF 文件内容。

4. 生成新的AOF文件：在后台进行 AOF 重写的同时，Redis 会以一种高效的方式将当前内存中的数据库状态写入新的 AOF 文件，去除了旧 AOF 文件中的冗余命令。

5. 替换旧的AOF文件：一旦新的 AOF 文件创建完成，Redis 会使用这个新的 AOF 文件来替换旧的 AOF 文件，并且在切换之前保证新旧 AOF 文件之间的数据一致性。

6. 完成AOF重写：AOF 重写完成后，旧的 AOF 文件会被替换，新的 AOF 文件会包含经过优化和压缩的命令记录，从而减小了磁盘占用。

通过这个流程，Redis 能够在不阻塞客户端的情况下对 AOF 文件进行压缩和优化，同时保证了数据的完整性。

AOF 重写是 Redis 中用于压缩和优化 AOF 文件的过程。由于 AOF 文件会记录每一次写操作，随着时间的推移，AOF 文件可能会变得非常大。AOF 重写的目的就是为了减小 AOF 文件的体积，去除冗余的命令，从而减少磁盘占用和加快恢复速度。

3.rdb持久化

RDB（Redis DataBase）持久化是 Redis 使用的一种持久化方式，它可以将 Redis 在内存中的数据以快照的形式保存到磁盘上。这种方式适合用于备份、灾难恢复以及数据迁移等场景。

RDB 持久化的流程可以简单描述如下：

1. 触发RDB持久化：RDB 持久化可以通过配置文件中的 save 指令或者通过命令触发。当满足一定条件时（比如在指定的时间内有指定数量的写操作），Redis 会执行 RDB 持久化。

2. 创建RDB文件：一旦 RDB 持久化被触发，Redis 会创建一个临时的 RDB 文件，以便保存当前数据库中的数据快照。

3. 数据写入RDB文件：在创建 RDB 文件的同时，Redis 会将当前内存中的数据库状态写入到这个 RDB 文件中，这个过程是一个快照的操作，会在一个瞬间完成。

4. 替换旧的RDB文件：一旦新的 RDB 文件创建完成，Redis 会使用这个新的 RDB 文件来替换旧的 RDB 文件。

5. 完成RDB持久化：RDB 持久化完成后，新的 RDB 文件会包含当前数据库的快照，可以用于后续的数据恢复。

RDB 持久化的优点在于生成的 RDB 文件是一个紧凑的二进制文件，适合用于备份和恢复操作。同时，在恢复大数据集时，RDB 持久化的速度通常比 AOF 持久化要快。然而，RDB 持久化可能会导致数据丢失，因为它是周期性的，只在指定的时间点进行数据快照。

4.混合持久化

Redis高可用

1. 主从同步

Redis 主从同步是指将主节点上的数据复制到从节点上，以实现数据备份、故障恢复和读写分离等功能。以下是 Redis 主从同步的基本过程：

1. 建立连接：

   • 从节点会向主节点发送 SYNC 命令，请求建立复制连接。
   • 主节点在接收到 SYNC 命令后，会创建一个专门用于复制的连接，并开始后续的同步过程。

2. 快照同步：

   • 如果从节点是第一次进行同步，主节点会执行 BGSAVE 命令生成 RDB 快照文件，并将该文件发送给从节点。
   • 从节点接收到快照文件后，会加载该文件，将自己的数据集状态更新到主节点快照文件所表示的时间点。

3. 增量同步：

   • 一旦完成快照同步，主节点会将接收到的所有写命令（包括读命令和写命令）传输给从节点，从节点会按照接收到的顺序重新执行这些写命令，以保持与主节点数据的一致性。

4. 持续同步：

   • 完成初次同步后，主节点会持续地将新的写命令发送给从节点，使得从节点的数据保持与主节点的数据一致。

需要注意的是，主从同步是异步的，这意味着主节点的写操作不会因为同步操作而被阻塞。因此，在一些情况下，主从节点之间可能会出现短暂的数据不一致，需要应用程序自行处理这种情况。

通过主从同步，Redis 实现了数据的备份和故障恢复，同时也支持了读写分离，可以提高系统的可用性和性能。

2. 哨兵模式

Redis Sentinel（哨兵）是一个用于监控 Redis 主从复制集群状态的组件，它可以实现自动故障转移和高可用性。哨兵通常作为一个独立的进程运行，它会监控整个 Redis 集群的健康状态，并在发现故障时采取自动化的措施来恢复服务。一般情况下，建议至少运行三个 Redis 哨兵进程来监控 Redis 主从复制的健康状态。这是因为在哨兵模式下，**需要保证有足够的哨兵进程来进行投票和决策，**以确保系统的高可用性和故障转移能力。

以下是 Redis Sentinel 的主要功能和特点：

1. 监控：哨兵会定期检查 Redis 主节点和从节点的健康状态，包括检测节点是否存活、节点的负载情况、网络连接状态等。

2. 故障检测：当哨兵发现 Redis 主节点或从节点出现故障时，它会立即采取措施，比如将一个从节点升级为新的主节点，以确保集群的高可用性。

3. 自动故障转移：哨兵可以自动进行故障转移，将一个从节点提升为新的主节点，然后通知其他从节点切换到新的主节点上进行复制。

4. 配置提供者：哨兵还可以作为配置提供者，为客户端提供关于 Redis 集群的信息，比如哪个节点是主节点、哪些节点是从节点等。

5. 集群管理：哨兵可以进行集群管理，比如在进行故障转移时，可以选择合适的从节点作为新的主节点，并协调其他节点进行切换。

通过 Redis Sentinel，可以实现 Redis 集群的自动化监控和故障处理，从而提高了整个 Redis 集群的可用性和稳定性。

哨兵：1.监测数据节点的状态 2.选取主节点
内部不存储业务数据，一般为奇数个。

当 Redis 主节点宕机后，哨兵进程会协同工作来进行故障转移，确保系统的高可用性。以下是主节点宕机后哨兵的运行过程：

1. 检测主节点宕机：

   • 当哨兵检测到主节点宕机时，它们会开始进行故障检测。

2. 选举新的主节点：

   • 哨兵进程会通过投票机制来选举新的主节点。它们会协商决定哪个从节点将成为新的主节点。
   • 哨兵会考虑每个从节点的复制偏移量（replication offset）和复制积压量（replication backlog），以及从节点的健康状态，来做出决策。

3. 通知客户端和其他从节点：

   • 一旦新的主节点被选举出来，哨兵会通知客户端和其他从节点发生了主从切换。

4. 更新配置：

   • 哨兵会更新所有的从节点配置，使它们成为新的主节点的从节点。

5. 恢复服务：

   • 一旦新的主节点被选举出来并且从节点已经切换完成，服务将恢复正常运行。

这个过程中，哨兵的角色就是监控、决策和协调故障转移，以确保 Redis 系统在主节点宕机后能够快速恢复并保持高可用性。

尽管哨兵模式为 Redis 提供了故障转移和高可用性的解决方案，但它也存在一些缺点：

1. 复杂性：配置和管理哨兵模式相对复杂，需要考虑哨兵的部署、监控和故障转移的相关设置。

2. 单点故障：尽管可以运行多个哨兵进程以提高容错性，但如果大多数哨兵进程出现故障，整个系统可能会受到影响。

3. 延迟：在故障转移发生时，需要一定时间来选举新的主节点并通知客户端和其他从节点。这可能会导致一段时间内的服务中断或延迟。

4. 人为干预：在某些情况下，哨兵模式可能需要人为干预才能恢复正常运行，例如在网络分区发生时可能会出现脑裂（split-brain）情况，需要管理员手动介入。

5. 性能开销：哨兵进程本身会消耗一定的系统资源，尤其在监控大规模 Redis 集群时，会产生一定的性能开销。

考虑到这些缺点，一些用户可能会选择使用 Redis Cluster 来代替哨兵模式，因为 Redis Cluster 具有更好的扩展性和容错性，能够更好地应对大规模的 Redis 部署。

3.cluster集群*

Redis cluster将所有数据划分为16384（2^14）个槽位，每个redis节点负责一部分槽位。是一种去中心化的集群方式；客户端为了可以直接定位（对 key 通过 crc16 进行 hash 再对2的14次方取余）某个具体的 key 所在节点，需要缓存槽位相关信息，这样才可以准确快速地定位到相应的节点。同时因为可能会存在客户端与服务器存储槽位的信息不一致的情况，还需要纠正机制（通过返回 -MOVED 3999 127.0.0.1:6479，客户端收到后需要立即纠正本地的槽位映射表）来实现槽位信息的校验调整。
另外，redis cluster 的每个节点会将集群的配置信息持久化到配置文件中，这就要求确保配置文件是可写的，而且尽量不要依靠人工修改配置文件

在 Redis Cluster 中，数据不是通过主从同步的方式来实现复制，而是通过集群中的节点之间进行数据分片和复制来实现高可用性和扩展性。

基本上，Redis Cluster 的数据复制是通过以下方式来实现的：

1. 数据分片：

   • 在 Redis Cluster 中，数据被分成多个槽（slot），每个槽包含一部分数据。集群中的每个节点负责处理其中的一部分槽。

2. 数据复制：

   • 每个槽都有一个主节点负责处理，同时可能有一个或多个从节点用于备份。主节点负责处理客户端的读写请求，从节点则负责复制主节点的数据。

3. 节点间通信：

   • 集群中的节点之间会通过消息传递协议进行通信，主要用于槽的迁移、节点的发现和故障检测等操作。

4. 故障转移：

   • 当主节点宕机时，集群会从其备份的从节点中选举一个新的主节点，以确保数据的持续可用性。

总体来说，Redis Cluster 通过数据分片和复制来实现数据的高可用性和横向扩展，而不同于传统的主从复制方式。这种方式使得 Redis Cluster 能够处理大规模的数据，并提供更高的性能和可用性。