企业官网建设流程全解析

1. Redis通用命令概述

Redis作为当今最流行的内存数据库之一，其强大之处不仅在于丰富的数据结构，更在于那些"一招鲜吃遍天"的通用命令。这些命令就像是Redis世界的瑞士军刀，无论你操作的是字符串、哈希还是集合，都能得心应手。在实际项目中，我发现掌握这些通用命令往往能解决80%的日常需求。

以KEYS命令为例，虽然文档中明确警告不要在线上环境使用，但在开发调试阶段，它能快速帮我们定位问题键。记得有一次排查缓存污染问题时，我就是用KEYS user:*快速锁定了问题键的范围。不过要特别注意，生产环境一定要用SCAN替代，这个坑我后面会详细讲。

2. 键空间操作命令详解

2.1 键查询与管理

EXISTS命令是我日常使用频率最高的命令之一，它的时间复杂度是O(1)，特别适合在业务逻辑中做前置检查。比如在电商系统中，下单前检查优惠券是否存在：

> EXISTS coupon:2023summer (integer) 1

TYPE命令在动态类型语言对接Redis时特别有用。有次我们Python服务突然报错，就是因为误把哈希类型当字符串操作，后来在代码中增加了类型检查：

if redis_client.type('user:1001') != b'hash': raise TypeError("Expected hash type")

DEL命令看似简单，但在批量删除时有个性能陷阱。删除10万个键时，直接DEL会导致Redis阻塞，更优的做法是：

redis-cli --scan --pattern "temp:*" | xargs -L 1000 redis-cli del

2.2 键过期控制

TTL和PTTL这对命令在实现分布式锁时必不可少。我们团队实现的锁续期机制就是基于PTTL的毫秒级精度：

local lock_key = KEYS[1] local ttl = redis.call('PTTL', lock_key) if ttl < 3000 then -- 剩余时间小于3秒时续期 redis.call('PEXPIRE', lock_key, 5000) return 1 end return 0

EXPIREAT在定时任务场景特别有用。比如双十一活动结束自动下架：

> EXPIREAT promotion:1111 1730332800 # 2024-11-11 00:00:00

3. 数据操作通用命令

3.1 序列化与反序列化

DUMP+RESTORE组合是Redis间数据迁移的利器。我们曾经用这个方案在不停服的情况下完成了数据分片迁移：

# 源Redis DUMP user:1001 > user_1001.dump # 目标Redis cat user_1001.dump | redis-cli -x RESTORE user:1001 0

重要提示：RESTORE会覆盖已存在的键，操作前务必先用EXISTS检查

3.2 原子性操作

MULTI/EXEC事务在库存扣减场景中必不可少。但要注意Redis事务和关系型数据库的区别 - 它实际上是将命令打包执行，中间不会回滚：

> MULTI > DECR stock:item_1001 > INCR order_count > EXEC

更复杂的场景建议使用Lua脚本，比如秒杀系统中的库存检查+扣减：

local stock = tonumber(redis.call('GET', KEYS[1])) if stock > 0 then redis.call('DECR', KEYS[1]) return 1 end return 0

4. 系统运维命令

4.1 内存优化命令

MEMORY USAGE是我们定期进行容量规划的核心工具。结合OBJECT ENCODING可以找出内存消耗大户：

> MEMORY USAGE big_hash_key (integer) 1048576 > OBJECT ENCODING big_hash_key "hashtable" # 可以考虑用ziplist优化

MEMORY PURGE在Redis 4.0+版本中能主动触发内存碎片整理。我们设置了定时任务在业务低峰期执行：

0 4 * * * /usr/bin/redis-cli MEMORY PURGE >/dev/null

4.2 持久化相关

BGSAVE虽然能后台保存，但在大内存实例上要谨慎。我们曾经因为频繁执行BGSAVE导致AOF重写堆积：

# 安全做法是先检查是否有其他持久化在进行 > INFO persistence | grep rdb_bgsave_in_progress :0 > BGSAVE

5. 生产环境避坑指南

5.1 KEYS命令的替代方案

所有Redis开发者都应该把这个警告刻在脑子里：生产环境绝对不要用KEYS！我们血的教训是：一个KEYS *操作让整个集群卡顿了8秒。正确的做法是用SCAN迭代：

def safe_keys(pattern, batch_size=1000): cursor = '0' keys = [] while True: cursor, partial_keys = redis_client.scan( cursor=cursor, match=pattern, count=batch_size ) keys.extend(partial_keys) if cursor == 0: break return keys

5.2 大键处理的黄金法则

遇到超过1MB的大键时要特别小心。我们总结的处理流程是：

1. 用DEBUG OBJECT分析键结构
2. 考虑拆分成多个小键
3. 如果必须保留大键，操作时加上CLIENT PAUSE保护

> CLIENT PAUSE 5000 # 暂停客户端5秒 > DEL big_key > CLIENT UNPAUSE

5.3 连接池最佳实践

CLIENT LIST是诊断连接泄漏的神器。这是我们运维脚本中的关键片段：

# 统计各客户端的连接时长 redis-cli CLIENT LIST | awk -F'[=,]' '{print $6,$2}' | sort -n

在Java应用中，我们配置Jedis连接池时会特别注意这些参数：

JedisPoolConfig config = new JedisPoolConfig(); config.setMaxTotal(100); // 根据QPS调整 config.setMaxIdle(20); config.setMinIdle(5); config.setTestOnBorrow(true); // 关键！避免拿到坏连接

6. 性能优化实战技巧

6.1 Pipeline批量操作

在用户画像系统中，我们通过Pipeline将100次查询合并为1次网络往返：

with redis_client.pipeline() as pipe: for user_id in user_ids: pipe.hgetall(f'user:{user_id}') profiles = pipe.execute()

性能对比：普通操作QPS约5万，Pipeline可达20万+

6.2 巧妙使用UNLINK

DEL是同步删除，UNLINK是异步删除。在大键删除时差异明显：

# 测试删除1GB的键 time redis-cli DEL big_key # 2.3s time redis-cli UNLINK big_key # 0.01s

6.3 内存优化三把斧

1. 用HASH代替多个STRING存储对象
2. 对小集合使用ZIPLIST编码
3. 对稀疏数据使用HyperLogLog

这是我们优化用户标签内存的实例：

# 优化前：100万用户*10标签 = 1000万STRING键 # 优化后： HSET user_tags:1001 fashion 1 sports 1 tech 0

7. 监控与诊断命令

7.1 实时监控命令

INFO命令的输出是我们监控系统的核心数据源。特别是这几个关键指标：

# 内存使用率 used_memory_human mem_fragmentation_ratio # 持久化状态 rdb_last_bgsave_status aof_last_bgrewrite_status # 客户端统计 connected_clients blocked_clients

7.2 慢查询分析

我们通过SLOWLOG发现并优化了多个性能瓶颈：

# 获取最近的10条慢查询 SLOWLOG GET 10

配置建议：

# redis.conf slowlog-log-slower-than 10000 # 10毫秒 slowlog-max-len 1024 # 记录条数

7.3 热点键排查

redis-cli --hotkeys是Redis 4.0+自带的诊断工具：

redis-cli --hotkeys --intrinsic-latency 100

对于旧版本，我们通过统计命令次数来识别热点：

# 监控所有命令 redis-cli MONITOR | awk '{print $3}' | sort | uniq -c | sort -nr