孔良1. Redis命令体系概览
Redis作为内存数据库的典型代表，其命令体系设计体现了"简单即美"的哲学。我初次接触Redis时，最惊讶的是它仅用几十个核心命令就能支撑起复杂的应用场景。经过多年实战，我发现这些命令背后隐藏着精妙的设计逻辑。
Redis命令主要分为五大类：字符串操作、哈希表操作、列表操作、集合操作和有序集合操作。每类命令都有其独特的应用场景：
- 字符串命令（SET/GET/INCR）适合缓存和计数器
- 哈希命令（HSET/HGETALL）适合对象存储
- 列表命令（LPUSH/LRANGE）实现消息队列
- 集合命令（SADD/SINTER）处理关系运算
- 有序集合（ZADD/ZRANGE）构建排行榜
经验之谈：新手常犯的错误是滥用字符串类型存储复杂对象，实际上哈希类型在存储结构化数据时内存效率更高。我曾优化过一个用户配置存储方案，改用哈希后内存消耗降低了40%。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心命令深度解析
2.1 字符串操作实战
字符串是Redis最基础的数据类型，但其中暗藏玄机。SET命令看似简单，其实支持多种修饰符：
bash复制SET key value [EX seconds] [PX milliseconds] [NX|XX]
- EX/PX设置过期时间（秒/毫秒）
- NX表示键不存在时才设置
- XX表示键存在时才设置
这个特性可以实现分布式锁的基础版本：
java复制// 伪代码示例
String result = jedis.set("lock_key", "1", "NX", "EX", 30);
if("OK".equals(result)) {
// 获取锁成功
} else {
// 获取锁失败
}
踩坑记录：早期项目我曾用SETNX+EXPIRE组合命令实现锁，结果出现了死锁。原因是这两个命令不是原子操作，中间可能发生崩溃。后来改用带EX参数的SET命令才解决。
2.2 哈希表高效用法
哈希表特别适合存储对象属性。假设存储用户信息：
bash复制HSET user:1001 name "张三" age 28 email "zhangsan@example.com"
HGETALL user:1001
与字符串方案对比：
| 方案 | 命令示例 | 内存占用 | 网络开销 |
|---|---|---|---|
| 字符串 | SET user:1001:name "张三" | 高 | 多次请求 |
| 哈希 | HSET user:1001 name "张三" | 低 | 单次请求 |
实测在存储20个属性的对象时，哈希方案能减少35%的内存使用。
3. Java客户端选型与实践
3.1 Jedis vs Lettuce
Java生态中主流Redis客户端对比：
| 特性 | Jedis | Lettuce |
|---|---|---|
| 连接方式 | 直连 | 基于Netty的异步 |
| 线程安全 | 连接池保证 | 原生线程安全 |
| 协议支持 | RESP2 | RESP2/RESP3 |
| 性能 | 较高 | 极高 |
| 功能完备性 | 完整 | 完整 |
对于常规应用，Jedis简单易用；高并发场景建议使用Lettuce。我曾在一个QPS超过5万的系统中将Jedis替换为Lettuce，CPU使用率下降了20%。
3.2 Jedis最佳实践
基础使用示例：
java复制// 创建连接池配置
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(128);
poolConfig.setMaxIdle(32);
poolConfig.setMinIdle(8);
// 创建连接池
try (JedisPool jedisPool = new JedisPool(poolConfig, "redis-host", 6379);
Jedis jedis = jedisPool.getResource()) {
// 执行命令
jedis.set("foo", "bar");
String value = jedis.get("foo");
}
关键配置参数：
- maxTotal：最大连接数（建议QPS/1000）
- maxIdle：最大空闲连接
- minIdle：最小空闲连接
- testOnBorrow：获取连接时验证（性能敏感场景慎用）
血泪教训：曾因maxTotal设置过大导致Redis连接数爆满，整个服务瘫痪。后来采用动态调整策略，根据监控指标自动缩放连接池大小。
4. 高级特性与性能优化
4.1 管道技术(Pipeline)
批量操作时使用管道可提升10倍以上性能：
java复制try (Jedis jedis = jedisPool.getResource()) {
Pipeline p = jedis.pipelined();
for (int i = 0; i < 1000; i++) {
p.set("key-" + i, "value-" + i);
}
p.sync();
}
注意事项：
- 管道中的命令数量不宜过多（建议<1万）
- 需要处理同步异常
- 不适用于有依赖关系的命令序列
4.2 Lua脚本实战
复杂操作使用Lua脚本保证原子性：
lua复制-- 限流脚本示例
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local current = tonumber(redis.call('GET', key) or "0")
if current + 1 > limit then
return 0
else
redis.call("INCRBY", key, 1)
redis.call("EXPIRE", key, 60)
return 1
end
Java调用方式：
java复制String script = "上面Lua脚本内容";
Object result = jedis.eval(script, Collections.singletonList("rate_limit_key"),
Collections.singletonList("100"));
性能数据对比（单位：ops/sec）：
| 操作方式 | 单线程 | 100并发 |
|---|---|---|
| 单命令 | 50,000 | 120,000 |
| 管道 | 400,000 | 900,000 |
| Lua脚本 | 80,000 | 300,000 |
5. 生产环境避坑指南
5.1 连接泄露排查
典型症状：Redis连接数持续增长，最终达到上限。排查步骤：
- 使用
CLIENT LIST命令查看连接来源 - 检查代码中是否有未关闭的Jedis实例
- 使用try-with-resources语法确保资源释放
- 监控连接池使用情况
我曾遇到过一个连接泄露案例，原因是开发者在异常处理路径中漏掉了jedis.close()调用，导致每天泄漏约500个连接。
5.2 内存优化技巧
- 使用
ziplist编码优化小哈希：bash复制# 配置阈值 hash-max-ziplist-entries 512 hash-max-ziplist-value 64 - 合理设置过期时间，避免数据无限增长
- 大Key拆分：将超过10KB的Key拆分为多个小Key
- 使用SCAN替代KEYS命令遍历数据
5.3 高可用方案对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 主从复制 | 配置简单 | 故障需手动切换 | 读多写少 |
| Sentinel | 自动故障转移 | 配置复杂 | 中小规模 |
| Cluster | 自动分片 | 客户端需支持 | 大数据量 |
在电商秒杀系统中，我们采用Redis Cluster方案，通过预先分片将库存数据分散到不同节点，避免了单点瓶颈。实测可支撑10万级QPS的秒杀请求。