阿源的知识库

切换日光/暗黑模式

基础连接与数据模型 ​

学习目标 ​

掌握本篇独立命令的输入、返回与状态变化，按访问形状选择结构，并为键、返回数量和失败重试设置边界。

核心知识点 ​

本篇采用 Redis 8 稳定主版本的基础命令语义；官方文档核对日期：2026-10-06，不声明未验证的补丁版本。官方数据类型 是本章事实依据。

Redis 是网络数据结构服务器；key 和 String value 都是二进制安全的字节序列，Hash/List 等值有专用命令。key 使用业务前缀和版本，例如 lab:{core}:name；花括号内的 hash tag 让本章多键实验落在同一 Cluster 槽，但生产环境不能把全部业务集中到一个槽。内存、过期、淘汰、复制和持久化共同决定数据寿命，Redis 不能自动提供与数据库的跨资源事务。

实验前提：本机独立 Redis 8 服务在 127.0.0.1:6379 运行；通过终端执行 redis-cli -h 127.0.0.1 -p 6379 后在交互提示符输入下面的命令（不是 PowerShell 命令）。有 ACL 时用 --user lab_user --askpass 输入密码。示例注释记录返回，不需要把输出复制成输入；不同客户端的数组排版可能不同。

连接例不改变业务数据；TYPE/EXISTS 例开始前执行 DEL lab:{core}:name lab:{core}:missing 清理指定实验键，结束后再次执行同样清理。不要在业务环境运行学习写入。

Standalone：识别单实例部署 ​

用于确认当前服务是否为独立实例，并理解单实例的容量与故障边界。

redis
# 初始：连接本机独立实验服务 127.0.0.1:6379。
INFO server
# 输出：响应含 redis_mode:standalone，redis_version 为实际服务版本。

Standalone 不分片，一个实例承担该数据集；单实例故障会中断访问，持久化不等于高可用。复制、Sentinel 和 Cluster 是不同的拓扑选择，不是客户端序列化设置。官方依据：INFO。

Replication：识别主从复制角色 ​

用于读取主节点与副本角色，并理解复制提供冗余但可能存在读取延迟。

redis
# 初始：本机实验实例是主节点；尚未配置副本。
INFO replication
# 输出：含 role:master、connected_slaves:0；接入副本后数量随实际拓扑变化。

主从复制通常异步，副本可能尚未收到最近写入；主从本身不自动完成故障转移，也不增加单个主节点的写容量。配置好的副本会报告 role:slave 和主节点连接信息；这里保留服务端字段的原名。官方依据：Replication。

Redis Sentinel：通过监控服务发现当前主节点 ​

用于查询 Sentinel 管理的主节点地址，区分故障转移监控与数据存储服务。

redis
# 初始：另用 redis-cli -h 127.0.0.1 -p 26379 连接已配置的实验 Sentinel。
# 前置：Sentinel 监控名为 lab-master，当前主节点地址为 127.0.0.1:6379。
SENTINEL get-master-addr-by-name lab-master
# 输出：数组为 "127.0.0.1"、"6379"；故障转移后地址可能改变。

Sentinel 监控主从、协调自动故障转移并供客户端发现主节点，不承担业务数据分片；客户端必须支持 Sentinel 发现。生产需要多个独立故障域的 Sentinel 与合理 quorum；不要在普通 6379 数据连接执行本例，未部署 Sentinel 时跳过。官方依据：Redis Sentinel。

Redis Cluster：识别数据分片状态 ​

用于读取 Cluster 节点的槽覆盖与健康状态，区分分片扩容和单主故障转移。

redis
# 初始：另用 redis-cli -c 连接已配置、健康的实验 Cluster 节点。
CLUSTER INFO
# 输出：健康完整集群含 cluster_state:ok、cluster_slots_assigned:16384。

Redis Cluster 按 16384 个 hash slot 分片，主节点拥有槽，副本用于故障转移；客户端需要处理 MOVED/ASK 重定向。多键命令受同槽约束且仅数据库 0；分片并不保证异步复制故障时不丢写入。普通 standalone 会报 cluster support disabled，未部署 Cluster 时跳过本例。官方依据：Redis Cluster。

RESP：协商客户端与服务端的线协议 ​

用于观察连接的协议版本，理解 redis-cli 显示文本与实际网络编码的区别。

redis
# 初始：Redis 8 实验连接已经认证，客户端支持 RESP3。
HELLO 3
HELLO 2
# 关键变化：当前连接先协商 RESP3，再恢复 RESP2。
# 输出：第一响应含 proto=3 的 map，第二响应含 proto=2 的数组。

RESP（Redis Serialization Protocol）为命令与响应定义类型、长度和边界；RESP2 常见 simple string、bulk string、integer、array，RESP3 增加 map、boolean、push 等类型。命令按字符串数组传输；长度按字节计数且使用 CRLF 分隔，因此 String 可以包含任意字节，而不是靠空格或换行拆 value。客户端负责解码，HELLO 的 map/array 终端排版随客户端而变。官方依据：RESP specification 与 HELLO。

Event loop：理解核心命令的串行执行 ​

用于观察原子计数的连续状态，并理解事件循环中的慢命令对其他客户端的影响。

redis
# 初始：数据库 0 的 lab:{core}:serial 已不存在，仅实验客户端写入。
INCR lab:{core}:serial
INCR lab:{core}:serial
GET lab:{core}:serial
# 关键变化：计数从隐含 0 递增到 1，再到 2，没有客户端读改写窗口。
# 输出：整数 1、整数 2、"2"；结束后 DEL lab:{core}:serial 清理。

本章常规核心数据命令由主线程串行执行；事件循环通过 I/O 多路复用服务多个连接，网络 I/O 和持久化等工作可使用后台线程或进程，所以不能说整个 Redis 只有一个线程。长时间运行的慢命令可能阻塞其他客户端的命令执行；增加连接或 CPU 核数不能直接让同一实例的这些命令并行。此样例验证计数结果，线程模型依据官方说明，不能从两个返回值推断线程数；模块和专用查询引擎另有执行模型。官方依据：Single threaded nature 与慢命令延迟。

常用用法 ​

PING：检查当前连接能否与服务端交互 ​

用于检查当前连接能否与服务端交互。

redis
# 初始：本机 127.0.0.1:6379 实验连接已建立，name 和 missing 键不存在。
PING
# 关键变化：读取连接响应，PONG 表明服务收到请求。
# 输出：PONG。

连接可达不等于拥有业务命令权限，也不保证复制节点的数据最新。 官方参考：PING。

AUTH：验证学习账号并确认认证后的命令权限 ​

用于验证学习账号并确认认证后的命令权限。

redis
# 初始：本机实验 ACL 已配置 lab_user，当前连接尚未认证。
AUTH lab_user "lab-only-password"
PING
# 关键变化：连接身份变为 lab_user。
# 输出：AUTH 为 OK，PING 为 PONG。

仅在独立本机实验服务预先配置 ACL 用户 lab_user 和此演示密码；生产密码不写到历史、脚本或日志。正常连接优先用 redis-cli --user lab_user --askpass，在 TLS 环境启用 --tls 并验证证书；ACL 还需限制 key 范围和命令。 官方参考：AUTH。

SELECT：切换独立连接的逻辑数据库以理解命名空间 ​

用于切换独立连接的逻辑数据库以理解命名空间。

redis
# 初始：standalone 当前连接使用数据库 0，至少配置两个数据库。
SELECT 1
SELECT 0
# 关键变化：当前数据库先变为 1，再恢复为 0。
# 输出：两次均为 OK，最终回到数据库 0。

本例仅适用于配置了至少两个数据库的 standalone；Redis Cluster 仅支持数据库 0，禁止依赖 SELECT 隔离租户。逻辑数据库共享服务资源。 官方参考：SELECT。

TYPE：识别值的数据结构以选择匹配的操作命令 ​

用于识别值的数据结构以选择匹配的操作命令。

redis
# 初始：本机 127.0.0.1:6379 实验连接已建立，name 和 missing 键不存在。
SET lab:{core}:name Ann
TYPE lab:{core}:name
# 关键变化：name 写入 Ann，TYPE 读取其 String 类型。
# 输出：SET 为 OK，TYPE 为 string。

对 String 执行 HGET 会产生 WRONGTYPE；缺失 key 的 TYPE 是 none。清理：DEL lab:{core}:name。 官方参考：TYPE。

EXISTS：检查明确的键是否存在并解释返回的计数 ​

用于检查明确的键是否存在并解释返回的计数。

redis
# 初始：本机 127.0.0.1:6379 实验连接已建立，name 和 missing 键不存在。
SET lab:{core}:name Ann
EXISTS lab:{core}:name lab:{core}:missing
# 关键变化：name 被创建，missing 仍不存在，因此存在计数为 1。
# 输出：SET 为 OK，EXISTS 为整数 1。

先确保 missing 不存在；重复传入同一现有 key 会重复计数。检查后再写有竞争窗口，条件写应使用 SET NX。清理：DEL lab:{core}:name。 官方参考：EXISTS。

易混点 ​

命令返回的整数有的表示数量、有的表示旧值或新值，应按命令解释；nil 与空字符串不同。单命令原子不等于跨命令或跨数据库的业务事务。

课后小问 ​

  1. 本篇怎样验证示例没有依赖上一次实验？

答案：每个小节先清理明确实验 key，再按本段重建输入，读回结果后清理；连接与认证例按注明的连接前置条件执行。

  1. 网络超时后能否直接重试写操作？

答案：不能由超时推断服务端未执行。对计数、入队、事件追加等写操作应设计幂等、重试上限与恢复路径。

本节小结 ​

按输入与输出验证命令语义，再评估数据量、阻塞时间、精度和失败路径；实验清理只针对明确学习 key。

快速回顾 ​

能根据本篇 H3 搜索命令、重建初始状态、解释返回值，并说明哪些边界需要客户端或业务协议补齐。