当前位置： 首页 > news >正文

Redis 原理与实验

news 2025/11/17 6:50:56

1.特点阐述与比较

简述 Redis 的核心特性，结合实际场景说明 Redis 相比传统关系型数据库（如 MySQL）的优势与适用场景。

一、Redis 核心特性

  1. 基于内存存储，读写响应时间达微秒级，远超磁盘数据库。
  2. 支持 5 种核心数据结构（字符串、哈希、列表、集合、有序集合），适配多类场景。
  3. 高并发高可用，单实例 QPS 可达 10 万 +，支持主从复制、集群部署。
  4. 支持持久化（RDB 快照、AOF 日志），兼顾性能与数据安全性。
  5. 提供丰富附加功能，如缓存过期、原子操作、发布订阅、分布式锁。

二、Redis 相比 MySQL 的核心优势

  1. 读写性能碾压：Redis 内存直接操作，MySQL 依赖磁盘 IO，前者速度快 10-100 倍，适合高吞吐场景。
  2. 数据结构灵活：无需预定义表结构，可直接存储半结构化 / 非结构化数据，迭代效率更高。
  3. 原生支持高并发：自带集群、主从复制能力，无需复杂分库分表，降低高流量架构复杂度。
  4. 功能更贴合高频场景：原子操作避免并发问题，过期策略简化缓存失效管理，无需额外开发。

三、Redis 适用场景（结合实际）

  • 缓存加速：电商商品详情页缓存、API 接口结果缓存，减少 MySQL 查询压力，提升页面加载速度。
  • 实时计数器：秒杀活动库存计数、短视频点赞量 / 阅读量统计，原子操作保证数据准确性。
  • 临时数据存储：用户登录会话、购物车临时数据，过期策略自动清理无效数据。
  • 分布式场景：分布式锁（解决跨服务并发问题）、发布订阅（实时消息通知，如订单状态推送）。
  • 排行榜 / 榜单：游戏战力排行、电商销量榜单，有序集合支持高效排序与范围查询。


2.两种持久化原理深度解析

分别解释 Redis 两种持久化机制（RDB、AOF）的工作原理、配置核心参数、优缺点及适用场景，说明如何根据业务需求选择合适的持久化方案。

RDB持久化

原理：按照快照的方式，将指定时间内的所有数据库数据都以二进制文件的形式存储到磁盘，

配置核心参数：

  1. save <seconds> <changes>：自动触发条件，例 save 900 1（900 秒内 1 次修改）、save 300 10（300 秒内 10 次修改）。
  2. dbfilename dump.rdb：RDB 文件名称，默认存储在 dir 配置的目录下。
  3. dir ./：RDB 文件存储路径。
  4. stop-writes-on-bgsave-error yes：bgsave 失败时是否停止写操作，默认开启（保证数据一致性）

优点：文件体积小，数据恢复速度极快；快照期间主进程无 IO 开销，对读写性能影响小。

缺点：数据一致性弱，仅能恢复到上一次快照时间点，可能丢失两次快照间的数据；bgsave fork 子进程时会短暂占用额外内存，大内存实例可能引发阻塞。

适用场景：数据可以容忍短时丢失，要求快速恢复，定期全量备份

AOF持久化

原理：记录 Redis 所有写操作指令，以文本格式追加到 AOF 文件中。恢复时通过重新执行文件中的指令，还原内存数据。支持三种同步策略，控制指令刷盘频率。

配置核心参数：

  1. appendonly yes：开启 AOF 持久化（默认关闭）。
  2. appendfsync：刷盘策略，可选 always（每写 1 条指令刷盘）、everysec（每秒刷盘 1 次）、no（由操作系统决定刷盘时机）。
  3. appendfilename appendonly.aof：AOF 文件名称，存储路径同 dir 配置。
  4. no-appendfsync-on-rewrite no：AOF 重写期间是否暂停刷盘，默认关闭（避免数据丢失）。
  5. auto-aof-rewrite-percentage 100/auto-aof-rewrite-min-size 64mb：AOF 文件达到指定大小（64MB）且比上次重写后增大 100% 时，自动触发重写（压缩文件体积）。

优点：数据一致性强，always 策略可实现秒级数据不丢失；支持日志重写，避免文件无限增大。

缺点：AOF 文件体积远大于 RDB，数据恢复速度较慢；刷盘操作会产生 IO 开销，always 策略可能降低 Redis 写性能。

适用场景：对数据完整性要求高，不能接受数据大量丢失的场景。核心业务数据存储，需要最大限度保证数据完整性的场景。

根据业务需求选择合适的持久化方案

优先选混合持久化AOF 文件头部存储 RDB 快照，后续追加写指令。兼顾 RDB 恢复快和 AOF 一致性强的优点，是多数生产环境首选

数据无核心价值，追求极致性能：仅开启 RDB，配置合理的快照触发间隔，容忍少量数据丢失。

核心业务，零数据丢失诉求，开启 AOF 并配置 


3.主从复制工作机制以及哨兵模式解析

阐述 Redis 主从复制的工作机制（包括全量同步、增量同步流程），以及 Sentinel 哨兵机制的核心功能、故障检测与故障转移流程。

Redis 主从复制的工作机制：主从复制通过 “主节点写入、从节点拉取同步” 实现数据一致，支持一主多从，核心分为全量同步和增量同步两种模式。

全量模式：全部复制

  1. 从节点发送 psync ? -1 命令，向主节点请求全量同步。
  2. 主节点响应 +FULLRESYNC <runid> <offset>，确认全量同步并返回自身 runid 和当前偏移量。
  3. 主节点执行 bgsave 生成 RDB 快照，期间新写操作存入 “复制缓冲区”。
  4. 主节点将 RDB 文件发送给从节点，从节点接收后清空本地数据，加载 RDB 恢复快照。
  5. 快照加载完成后，主节点将复制缓冲区的增量命令同步给从节点，从节点执行后完成数据对齐。

增量模式：部分复制

  1. 从节点重连后发送 psync <runid> <offset>，携带上次记录的主节点 runid 和自身当前偏移量。
  2. 主节点验证 runid 一致，且从节点偏移量在自身复制缓冲区范围内，响应 +CONTINUE 确认增量同步。
  3. 主节点将从节点偏移量之后的所有写命令，从复制缓冲区中批量发送给从节点。
  4. 从节点执行接收的命令，更新自身偏移量，与主节点恢复数据一致。

哨兵机制

1. 核心功能

集群监控：实时检查主节点、从节点及其他哨兵节点的健康状态。

故障检测与判定：通过 “主观下线 + 客观下线” 机制，精准识别主节点故障。

自动故障转移：主节点故障后，自动选举新主节点、切换从节点复制关系，恢复集群写能力。

通知与配置：故障发生时通过脚本 / API 通知管理员，同时向客户端提供新主节点地址。

2. 故障检测流程

主观下线（SDOWN）：单个哨兵节点每 1 秒向所有节点发送 ping 命令，若目标节点在 down-after-milliseconds 配置时间内未响应，该哨兵判定其为 “主观下线”。

客观下线（ODOWN）：仅当主节点被判定为主观下线时，哨兵会向集群中其他哨兵发送 “主节点故障” 询问请求。若超过 quorum 配置的哨兵数量（如集群 3 个哨兵，quorum=2）均确认该主节点主观下线，则判定为 “客观下线”，触发故障转移。

3. 故障转移流程
  1. 选举新主节点：哨兵从所有健康的从节点中，按优先级筛选最优节点：
    • 优先选择 slave-priority 配置值最小的从节点。
    • 优先级相同则选择复制偏移量最大的从节点。
    • 偏移量相同则选择运行 ID 最小的从节点。
  2. 通知从节点切换：哨兵向新主节点发送 slaveof no one 命令，使其成为主节点；向其他从节点发送 slaveof <新主节点IP:端口> 命令，让它们切换复制目标为新主节点。
  3. 更新配置与通知：哨兵更新集群配置，将旧主节点标记为从节点；同时通知客户端新主节点地址，后续客户端直接向新主节点写入数据。
  4. 旧主节点恢复处理：若旧主节点重新上线，哨兵会向其发送 slaveof <新主节点IP:端口> 命令，使其成为新主节点的从节点，避免冲突。


4.Redis Cluster 集群的工作机制

说明 Redis Cluster 集群的工作机制，包括数据分片规则、节点通信方式、扩容与缩容的核心逻辑，以及 Cluster 相比主从 + Sentinel 架构的优势。

Redis Cluster 集群的工作机制

Redis Cluster 是 Redis 官方提供的分布式数据库解决方案，它通过数据分片​ 的方式进行数据分布式存储，同时提供复制​和故障转移能力，实现高可用性。

1. 数据分片规则：哈希槽（Hash Slot）

这是 Redis Cluster 最核心的概念。

分片单位：Cluster 将整个数据集自动划分为 16384​ 个哈希槽。

数据映射规则：当存储一个键值对时，Redis 会使用 CRC16 算法对 key 进行计算：slot = CRC16(key) mod 16384。这个计算结果决定了数据属于哪个槽。

槽分配规则：这 16384 个槽会被分配给集群中的所有主节点。例如：

一个 3 主节点的集群，可能分配为：Node1（0-5460槽），Node2（5461-10922槽），Node3（10923-16383槽）。

每个主节点负责处理自己所分配槽的读写命令。

优势：这种机制将数据管理的粒度从“键”提升到“槽”，使得数据的迁移、负载均衡可以以槽为单位进行操作，非常灵活。

节点通信方式：Gossip 协议

集群中的每个节点都维护着整个集群的元数据（Metadata），包括：

所有节点的信息（IP、端口、角色等）。

每个哈希槽的映射关系（即哪个槽由哪个节点负责）。

集群的状态（如节点是否下线）。

这些元数据通过 Gossip 协议​ 在节点间持续同步。

工作方式：每个节点会定期（如每秒）随机选择几个其他节点，互相交换 PING/PONG 消息。这些消息中包含了自身维护的集群元数据和其他信息。

目的：

信息传播：快速发现新节点和传播集群状态变化（如节点下线、故障转移完成）。

故障检测：用于检测节点是否失效。如果一个节点在指定时间内没有被任何节点 PING 通，它将被集群标记为疑似下线（PFAIL），如果大多数主节点都认为某个节点下线，则将其标记为已下线（FAIL），并触发故障转移。

3. 扩容与缩容的核心逻辑

核心操作是哈希槽的重新分配，这个过程由集群管理命令自动完成，对客户端基本透明。

扩容（增加主节点）：

准备新节点：启动新的 Redis 实例，并使用 CLUSTER MEET命令让其加入集群（此时它还没有分配任何槽，是空的）。

重新分片：执行 reshard 命令，指定从现有节点中迁移一部分哈希槽到新节点。

数据迁移：集群管理工具会自动化完成：

对源节点中属于待迁移槽的键，逐个进行迁移。

迁移过程中，对于这些键的请求，源节点会返回一个 ASK 重定向（ASK Redirect）​ 错误，告知客户端这个键正在迁移，请临时转向目标节点请求。迁移完成后，映射关系更新，客户端后续请求会直接发往新节点（收到 MOVED 重定向）。

缩容（移除主节点）：

迁移数据：必须先将被移除节点负责的所有哈希槽，通过 reshard 操作迁移到其他现有节点上。

安全下线：确认该节点不再负责任何槽后，才能安全地将其从集群中移除。

关键点：扩容缩容的核心是槽的移动，而非直接移动数据。数据是随着槽的归属变化而自动迁移的。

特点比较

特性

主从 + Sentinel 架构

Redis Cluster 架构

核心目标​

高可用（High Availability）​

高可用 + 水平扩展（Horizontal Scaling）​

数据模型​

单一数据集。主从节点数据完全一致，是数据的全量副本。

分区数据集。数据被分片，每个主节点只存储整个集群数据的一部分。

写能力​

无法扩展。所有写操作都集中在主节点上，受单机性能限制。

线性扩展。可以通过增加主节点来分摊写压力，提升整体写性能。

容量​

受单机内存限制。整个数据集不能超过单个主节点的内存大小。

可突破单机内存限制。集群总容量是所有主节点内存之和。

故障转移​

由 Sentinel 节点监控和完成自动故障转移。

由集群自身通过 Gossip 协议和选举机制完成，无需额外组件。

配置复杂度​

相对简单，逻辑清晰。

相对复杂，需要理解数据分片、重定向等概念。

核心优势：真正的水平扩展，无中心架构，原生分布式支持


5.慢查询相关探究

解释 Redis 慢查询的定义、触发条件及配置方式，结合运维场景说明如何通过慢查询日志定位和优化 Redis 性能问题。

定义：慢查询指Redis 命令从 “接收请求” 到 “执行完成” 的实际执行时间，超过预设阈值的命令。

触发条件：仅需满足一个核心条件：命令执行时间 > slowlog-log-slower-than 配置值

配置方式：

 设置阈值：

将慢查询阈值调整为 5 毫秒（5000 微秒） 127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 5000

 设置队列长度：

将慢查询日志队列长度设置为 1000 127.0.0.1:6379> CONFIG SET slowlog-max-len 1000

 使配置永久生效，需要修改 redis.conf 文件并重启

slowlog-log-slower-than 5000

slowlog-max-len 1000

场景说明：

场景：Redis 实例响应变慢，客户端报超时

第一步获取日志

获取最近10条慢查询记录 127.0.0.1:6379> SLOWLOG GET 10

第二步分析日志，定位问题

假设看到的慢查询日志如下

问题命令1：KEYS cache:product:*:detail

原因分析：KEYS命令会遍历整个数据库的所有键来匹配模式。当数据库中有数百万个key时，这个操作会阻塞Redis单线程，导致其他所有请求都被卡住，引发“雪崩”效应。

优化方案：绝对禁止在生产环境使用 KEYS命令，使用 SCAN命令替代，从业务逻辑上避免

问题命令2：HGETALL large_hash_key

原因分析：HGETALL会获取指定哈希键的所有字段和值。如果这个哈希键非常大，那么网络传输和客户端反序列化都会非常耗时，同样会长时间占用Redis的主线程

优化方案：使用 HSCAN命令，使用 HMGET命令，拆分大Key

第三步深入排查与优化

识别大Key（Big Key）：使用 redis-cli --bigkeys命令扫描数据库，找出可能的大Key。大Key是导致慢查询的常见元凶。

识别热Key（Hot Key）：某些Key被频繁访问，可能导致单个Redis实例CPU负载过高。可以通过监控或使用 redis-cli --hotkeys来发现。

检查持久化影响：如果慢查询发生时，正好触发了 RDB 快照生成或 AOF 重写，这两个操作会 fork 子进程，如果主进程内存占用很大，fork 操作本身可能会阻塞主进程。查 latest_fork_usec指标可以查看上次 fork 的耗时。

检查内存和交换分区（Swap）：如果物理内存不足，操作系统会将部分内存页换出到磁盘（Swap），一旦Redis访问被换出的数据，会产生极高的延迟。使用 INFO memory命令关注 used_memory和系统监控。


6.五种核心数据类型解析

简述 Redis 五种核心数据类型（String、Hash、List、Set、ZSet）的特点、底层实现（可选）及典型应用场景，并举例说明每种类型的常用命令。


7.Redis 动态配置的实现原理

说明 Redis 动态配置的实现原理，哪些配置项支持动态修改（无需重启 Redis），动态修改与修改配置文件的区别及注意事项。

一、String（字符串）

核心特点

最基础的数据类型，value 可存储字符串、数字（整数 / 浮点数）、二进制数据（如图片、序列化对象）。

最大存储容量 512MB，支持原子操作（如自增 / 自减），读写性能极致。

底层实现

默认用 简单动态字符串（SDS） 实现，相比 C 字符串，支持动态扩容、二进制安全（可存储特殊字符）、减少内存重分配开销。

典型应用场景

缓存单个值（如用户昵称、商品价格、接口结果）。

计数器（如文章阅读量、商品库存、接口调用次数）。

分布式锁

Session 存储（序列化用户会话信息为字符串）。

常用命令

set key value [EX seconds] [NX]：设置键值，可选过期时间、仅不存在时设置。

get key：获取键对应的值。

incr key：值为整数时自增 1。

decr key：值为整数时自减 1。

append key value：在字符串末尾追加内容。

二、Hash（哈希）

核心特点

键值对的集合（类似 Java 的 HashMap），key 是外层键，value 是内层 “字段 - 值” 映射。

支持单独操作内层字段（增删改查），无需修改整个对象，节省带宽。

底层实现

数据量小时用 压缩列表（ziplist） 存储（节省内存）；数据量大时自动转为 哈希表（dict）（提升查询效率）。

典型应用场景

存储对象类数据（如用户信息：id、姓名、年龄、手机号）。

商品详情（名称、价格、库存、销量）。

配置项存储（系统各项配置的键值对集合）。

常用命令

hset key field value：设置哈希的字段值。

hget key field：获取哈希的字段值。

hgetall key：获取哈希的所有字段和值。

hdel key field1 [field2]：删除哈希的一个或多个字段。

hlen key：统计哈希的字段数量。

三、List（列表）

核心特点

有序的字符串列表（双向链表），元素可重复，支持两端插入 / 删除，按索引访问。

底层是 “双向链表” 结构，首尾操作时间复杂度 O (1)，中间操作效率低。

底层实现

数据量小时用 压缩列表（ziplist）；数据量大时转为 双向链表（linkedlist）。

典型应用场景

消息队列（如异步任务队列，用 lpush 生产消息、rpop 消费消息）。

最新消息列表（如朋友圈、评论列表，用 lpush 新增，lrange 分页查询）。

栈 / 队列实现（栈：lpush + lpop；队列：lpush + rpop）。

常用命令

lpush key value1 [value2]：从列表左侧插入一个或多个元素。

rpop key：从列表右侧删除并返回一个元素。

lrange key start stop：获取列表从 start 到 stop 索引的元素

llen key：统计列表的元素数量。

lrem key count value：删除列表中 count 个值为 value 的元素。

四、Set（集合）

核心特点

无序的字符串集合，元素不可重复，支持高效的集合运算（交集、并集、差集）。

查找元素的时间复杂度 O (1)，远超 List 的 O (n)。

底层实现

元素是整数时用 整数集合（intset） 存储（节省内存）；否则用 哈希表（dict） 存储。

典型应用场景

去重场景（如用户标签去重、中奖用户去重）。

好友关系（如共同好友、好友推荐，用交集 sinter 计算）。

标签系统（如文章标签、商品分类，用 sadd 添加标签，smembers 查询所有标签）。

常用命令

sadd key member1 [member2]：向集合添加一个或多个元素（重复元素自动去重）。

smembers key：获取集合的所有元素。

sismember key member：判断元素是否在集合中（返回 1 存在，0 不存在）。

sinter key1 key2：计算两个集合的交集。

sdiff key1 key2：计算两个集合的差集（key1 有而 key2 没有的元素）。

五、ZSet（有序集合）

核心特点

有序且元素不可重复，每个元素关联一个 “分数（score）”，按分数排序（默认升序）。

支持按分数范围、排名范围查询，排序效率高。

底层实现

数据量小时用 压缩列表（ziplist）；数据量大时用 跳表（skiplist）+ 哈希表（跳表保证有序性，哈希表快速查找元素分数）。

典型应用场景

排行榜（如游戏战力排行、商品销量排行、视频点赞排行，用 zadd 添加分数，zrange 按排名查询）。

带权重的消息队列（如优先级任务队列，score 作为优先级，zrange 按优先级消费）。

范围统计（如成绩排名、用户活跃度排名，用 zcount 统计分数范围内的元素数量）。

常用命令

zadd key score1 member1 [score2 member2]：向有序集合添加元素及对应的分数。

zrange key start stop [WITHSCORES]：按排名升序获取从 start 到 stop 的元素（可选返回分数）。

zrevrange key start stop：按排名降序获取元素（适合排行榜倒序展示）。

zscore key member：获取元素对应的分数。

zcount key min max：统计分数在 min 到 max 范围内的元素数量。


8.主从复制与 Sentinel 配置


部署 1 主 2 从的 Redis 架构（主节点 6379，从节点 6380、6381），配置从节点只读，验证主从数据同步（主节点写数据，从节点查询验证）；

实践开始：

先对事先准备好的三台机器进行检查（另外两台是克隆，所以只检查一台）

对三台机器进行配置目录和日志目录的创建和授权

分别对两台从节点进行修改配置redis.conf

主要修改port,replicaof,masterauth

然后登录三个节点查看状态

10.0.0.16

10.0.0.100

10.0.0.101

然后主节点存储数据，验证结果

主存

丛看

且从节点权限为只读


部署 3 个 Sentinel 节点（端口 26379、26380、26381），监控主从集群，模拟主节点故障（手动停止主节点），验证 Sentinel 是否正确执行故障转移，记录故障转移过程。

然后接下来进行哨兵的配置

首先到将提供的模板进行修改，主要修改这两行

然后相同的格式发送给另外两台主机

修改属主属组

然后配置启动文件

由于没有提供模板我们需要自己写一个

同样需要复制给另外两个主机

然后重载文件，进行启动

然后进入哨兵查看状态

可以看出，一主两从三哨兵

然后进行模拟主节点损毁

直接关闭redis,检查是否会变化

没关之前

关闭

再次检查，已经成功切换

经过哨兵切换后，即使原主节点重新上线，也不会再成为主节点


9.Redis Cluster 部署与运维


部署 3主 23从的 Redis Cluster 集群（主节点端口 7000、7001、7002、从节点 7003、7004、7005），完成集群初始化与节点加入；
验证集群数据分片（写入不同 key，通过cluster keyslot查看 key 对应的槽位，验证数据分布）；
执行集群扩容（新增 1 主 1 从节点，分配槽位）和缩容（移除新增节点，迁移槽位）操作，记录每一步命令与结果。

实践开始

首先我们需要创建六个实例，步骤重复繁琐，所以用脚本来实现

在10.0.0.19主机

for port in 7000 7001 7002; domkdir -p /opt/redis/cluster/${port}cat > /opt/redis/cluster/${port}/redis.conf << EOF
port ${port}
cluster-enabled yes
cluster-config-file nodes-${port}.conf
cluster-node-timeout 15000
appendonly yes
daemonize yes
pidfile /var/run/redis_${port}.pid
logfile /opt/redis/cluster/${port}/redis.log
dir /opt/redis/cluster/${port}
EOF
done# 启动Redis实例
for port in 7000 7001 7002; doredis-server /opt/redis/cluster/${port}/redis.conf
done

在10.0.0.102主机

# 创建配置文件和数据目录
for port in 7003 7004 7005; domkdir -p /opt/redis/cluster/${port}cat > /opt/redis/cluster/${port}/redis.conf << EOF
port ${port}
cluster-enabled yes
cluster-config-file nodes-${port}.conf
cluster-node-timeout 15000
appendonly yes
daemonize yes
pidfile /var/run/redis_${port}.pid
logfile /opt/redis/cluster/${port}/redis.log
dir /opt/redis/cluster/${port}
EOF
done# 启动Redis实例
for port in 7003 7004 7005; doredis-server /opt/redis/cluster/${port}/redis.conf
done

然后进行集群创建

验证创建结果

验证数据分片

查看key对应的槽位

新增节点，同样用脚本进行创建

10.0.0.16

# 创建并启动新主节点
mkdir -p /opt/redis/cluster/7006
cat > /opt/redis/cluster/7006/redis.conf << EOF
port 7006
cluster-enabled yes
cluster-config-file nodes-7006.conf
cluster-node-timeout 15000
appendonly yes
daemonize yes
pidfile /var/run/redis_7006.pid
logfile /opt/redis/cluster/7006/redis.log
dir /opt/redis/cluster/7006
EOFredis-server /opt/redis/cluster/7006/redis.conf

10.0.0.102

# 创建并启动新从节点
mkdir -p /opt/redis/cluster/7007
cat > /opt/redis/cluster/7007/redis.conf << EOF
port 7007
cluster-enabled yes
cluster-config-file nodes-7007.conf
cluster-node-timeout 15000
appendonly yes
daemonize yes
pidfile /var/run/redis_7007.pid
logfile /opt/redis/cluster/7007/redis.log
dir /opt/redis/cluster/7007
EOFredis-server /opt/redis/cluster/7007/redis.conf

添加新主节点到集群

添加新从节点到集群（先获取7006的节点ID）

重新分片

检查扩容后的集群状态

集群缩容 - 移除新增节点

首先将7006节点的所有槽位迁移回其他节点

然后先减从节点

再减主节点

查看


10.Redis 源码编译安装与优化


在 Linux 环境（如 Ubuntu24-04）中，完成 Redis-8.2.2 的源码编译安装，配置核心优化参数（如内存限制、最大连接数、日志路径），并设置 Redis 为系统服务（systemd），确保开机自启。

提前进行apt update

然后安装编译工具和依赖

安装可选的依赖

apt install -y libssl-dev libsystemd-dev

接下来进行下载源码的操作

cd /tmp切换目录

下载

wget https://download.redis.io/releases/redis-8.2.2.tar.gz

解压进入源码目录

然后进行编译安装

make -j$(nproc)

运行测试

make test

安装到系统目录 sudo make install

创建必要的系统目录

创建redis系统用户和组

设置目录权限

复制默认配置文件

创建systemd服务文件

设置配置文件权限并启动

测试链接


11.多实例部署


基于同一台 Linux 服务器，部署 2 个 Redis-8.2.2 实例（端口分别为 6379、6380），配置不同的配置文件、数据目录、日志文件，验证两个实例独立运行且可正常连接。

在有redis的主机上进行创建文件

再分别创建

赋予权限

将原本的配置文件复制过来，并进行修改

主要修改这些位置，数字改成相应的进程号

port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile "/var/log/redis/redis-server-6380.log"
dir /var/lib/redis/6380/
赋予权限

启动

分别进行连接

创建内容

在6379写入内容

在6380查看

证明两个实例独立运行且可正常连接


12.数据类型实操


使用 redis-cli 客户端，完成以下操作并记录命令与结果：
用 String 类型实现 “用户登录状态缓存”（设置 key 过期时间）；

设置用户登录状态，key为"user:1001:session"，值为登录token，过期时间30分钟

查询登录状态

查看剩余过期时间


用 Hash 类型存储 “用户信息”（包含 id、name、age、phone 字段）并实现字段新增、修改、查询；

创建用户信息哈希

查看年龄并修改

增加邮箱并查看


用 ZSet 类型实现 “学生成绩排名”（存储 5 个学生的成绩并按分数降序排序）

新增五位同学

查看从高到低

从低到高

http://www.dtcms.com/a/617978.html

相关文章：

  • 网站开发职责与要求软件开发专业好吗
  • 【Linux驱动开发】Linux 设备驱动中的总线机制
  • 电压基准芯片详解：从原理到选型，附 TLV431 应用解析
  • 住房和城乡建设部网站监理工程师网站发送邮件功能
  • 开发第一个python程序
  • obet(Oracle Block Editor Tool)第二版发布
  • 【gas优化】2.11 Calldata 替换 Memory
  • 深度学习周报（11.10~11.16）
  • 阿里云建站论坛网站区块链网站建设方案
  • 李宏毅NLP-14-NLP任务
  • 惠普LaserJet Pro MFP M126a如何打印自检页
  • 南京大学cpp复习——面向对象第一部分（构造函数，拷贝构造函数，析构函数，移动构造函数，友元）
  • Stream 流核心速查表
  • 网站建设设计服务公司优化大师绿色版
  • STM32通信协议学习--I2C通信（了解）
  • 【技术选型】Go后台框架选型
  • 电子商务网站建设策划书范文西安优秀的集团门户网站建设费用
  • AI人工智能-语言模型-第六周（小白）
  • 找工作经验分享
  • 提供网站建设哪家好佛山外贸seo
  • 建站官网怎么做网页?
  • Qt编写28181推流分发服务/统计访问数量/无人观看超时关闭/等待重新点播/复用点播
  • CodexField Marketplace：重建内容与智能资产的链上市场结构
  • 微网站素材外贸家具网站
  • 后端服务发现工具，Consul与Eureka Consul vs Eureka：后端服务发现工具全面对比
  • 《动手学深度学习》6.5~6.6
  • 初识RabbitMQ
  • 历史数据分析——中国铝业
  • 网站建设设计公司类网站织梦模板 带手机端展厅设计图片
  • Kafka - 4 Kafka的副本同步机制