从删库到跑路：Redis 这 8 个命令，按下 FLUSHALL 我人都麻了

客户端连接Redis

# 语法# redis-cli -h IP/HOSTNAME -p PORT -a PASSWORD（redis-cli -h host -p port -a password）；redis-cli：命令行客户端，不带参数时连接本机127.0.0.1:6379

[root@localhost ~]# redis-cli# ping：向服务器发送PING测试连通性127.0.0.1:6379>pingPONG# 返回PONG表示连接正常、服务存活127.0.0.1:6379>info#显示当前节点redis运行状态信息# Server # 服务端信息段（版本/操作系统/进程/端口等）redis_version:5.0.3# Redis版本号redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:9529b692c0384fb7 redis_mode:standalone# 运行模式：单机os:Linux4.18.0-553.6.1.el8.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:8.4.1 process_id:10350# 服务进程PIDrun_id:fd68b669756ef777ee5d2d4f2a74e851cc243d6a tcp_port:6379# 监听端口uptime_in_seconds:676# 已运行秒数uptime_in_days:0 hz:10 configured_hz:10 lru_clock:9272993 executable:/usr/bin/redis-server config_file:/etc/redis.conf# 加载的配置文件路径# Clients # 客户端连接信息段connected_clients:1# 当前已连接客户端数client_recent_max_input_buffer:2 client_recent_max_output_buffer:0 blocked_clients:0# Memory # 内存信息段used_memory:853896 used_memory_human:833.88K# Redis已用内存used_memory_rss:13340672 used_memory_rss_human:12.72M# 系统分配给Redis的物理内存used_memory_peak:853896 used_memory_peak_human:833.88K used_memory_peak_perc:100.00% used_memory_overhead:840694 used_memory_startup:791000 used_memory_dataset:13202 used_memory_dataset_perc:20.99% allocator_allocated:1457768 allocator_active:1818624 allocator_resident:11468800 total_system_memory:3810115584 total_system_memory_human:3.55G used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0# 最大内存限制，0=不限制maxmemory_human:0B maxmemory_policy:noeviction# 内存满时淘汰策略：不淘汰allocator_frag_ratio:1.25 allocator_frag_bytes:360856 allocator_rss_ratio:6.31 allocator_rss_bytes:9650176 rss_overhead_ratio:1.16 rss_overhead_bytes:1871872 mem_fragmentation_ratio:16.43# 内存碎片率mem_fragmentation_bytes:12528776 mem_not_counted_for_evict:0 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:49694 mem_aof_buffer:0 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0# Persistence # 持久化信息段（RDB/AOF状态）loading:0# 是否正在加载持久化文件，0=否rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0# 是否正在后台bgsave，0=否rdb_last_save_time:1770879997 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:-1 rdb_current_bgsave_time_sec:-1 rdb_last_cow_size:0 aof_enabled:0# AOF是否开启，0=未开启aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok aof_last_cow_size:0# Stats # 统计信息段total_connections_received:2# 累计接收连接数total_commands_processed:5# 累计处理命令数instantaneous_ops_per_sec:0 total_net_input_bytes:90 total_net_output_bytes:26219 instantaneous_input_kbps:0.00 instantaneous_output_kbps:0.00 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0# Replication # 主从复制信息段role:master# 节点角色：主节点connected_slaves:0# 已连接从节点数master_replid:24b2280440a498439ac89b31c65249a5af62b08f master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0# CPU # CPU占用信息段used_cpu_sys:0.628455 used_cpu_user:0.440542 used_cpu_sys_children:0.000000 used_cpu_user_children:0.000000# Cluster # 集群信息段cluster_enabled:0# 集群未启用# Keyspace # 数据库键空间信息段（此处为空，无db统计）127.0.0.1:6379># info输出完毕，回到命令提示符

安装的相关程序介绍

# ll /usr/bin/redis-* 列出本机所有 Redis 相关可执行程序（ll 是 ls -l 的别名）[root@localhost ~]# ll /usr/bin/redis-*-rwxr-xr-x1root root656280Oct202021redis-benchmark#性能测试程序lrwxrwxrwx1root root12Oct202021redis-check-aof ->redis-server#AOF文件检查程序lrwxrwxrwx1root root12Oct202021redis-check-rdb ->redis-server#RDB文件检查程序-rwxr-xr-x1root root827608Oct202021redis-cli#客户端程序lrwxrwxrwx1root root12Oct202021redis-sentinel ->redis-server#哨兵程序，软连接到服务器端主程序-rwxr-xr-x1root root1800864Oct202021redis-server#服务端主程序

客户端程序redis-cli

# 默认本机无密码连接；不带任何参数时默认连接本机 127.0.0.1 的 6379 端口，无密码redis-cli# 远程客户端连接，注意：Redis没有用户的概念；-h 指定 Redis 服务器 IP；-p 指定端口（默认 6379）；-a 指定连接密码（requirepass）；--no-auth-warning 取消 -a 明文密码带来的安全警告提示redis-cli-h<Redis服务器IP>-p<PORT>-a<PASSWORD>--no-auth-warning

Redis常用命令

info

显示当前节点redis运行状态信息

# INFO 查看 Redis 服务器各项运行信息，不带参数时一次性输出全部分段（Server/Clients/Memory/Persistence/Stats/Replication/Cluster 等）127.0.0.1:6379>INFO# Server # 服务器分段（section）标题redis_version:5.0.3 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:9529b692c0384fb7 redis_mode:standalone os:Linux4.18.0-553.6.1.el8.x86_64 x86_64......# 只显示指定部分内容，INFO命是分段的# 只显示INFO内容# Server这一段；在 INFO 后追加分段名只输出该段，分段名不区分大小写127.0.0.1:6379>INFO Server# Server # 只输出服务器（Server）分段标题及内容redis_version:5.0.3 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:9529b692c0384fb7 redis_mode:standalone os:Linux4.18.0-553.6.1.el8.x86_64 x86_64......# 非交互式执行：在系统 shell 中用 redis-cli 直接带一条命令，结果输出后即退出[root@localhost ~]# redis-cli info Cluster # Cluster # 集群（Cluster）分段标题cluster_enabled:0# 是否启用集群模式：0 表示未启用# 不带命令参数，进入交互式 redis-cli 会话[root@localhost ~]# redis-cli# 在交互式会话中执行 info cluster，分段名同样不区分大小写127.0.0.1:6379>info cluster# Cluster # 集群（Cluster）分段标题cluster_enabled:0# 是否启用集群模式：0 表示未启用

select

切换数据库，相当于MySQL的USE DBNAME指令

# SELECT n 切换数据库；n 为数据库编号 dbindex，Redis 默认有 0~15 共 16 个库，编号范围 0~15；切换成功后提示符会显示当前库号127.0.0.1:6379>select0OK# 成功切换到 0 号库# 切换到 1 号库，提示符变为 6379[1]127.0.0.1:6379>select1OK# 成功切换到 1 号库# 切换到 15 号库，提示符变为 6379[15]127.0.0.1:6379[1]>select15OK# 成功切换到 15 号库# 尝试切换到 16 号库，超出合法范围127.0.0.1:6379[15]>select16(error)ERR DB index is out of range# 16 超出 0~15 范围而报错，且仍停留在 15 号库127.0.0.1:6379[15]>

注意：在Redis cluster模式下不支持多个数据库

KEYS

查看当前库下所有key，此命令慎用

一、 顺丰高级开发工程师在线执行了 Redis 危险命令导致某公司损失 400 万

最近安全事故濒发啊，前几天发生了《顺丰高级运维工程师的删库事件》，今天又看到了 PHP 工程师在线执行了 Redis 危险命令导致某公司损失 400 万。。

什么样的 Redis 命令会有如此威力，造成如此大的损失？

具体消息如下：

据云头条报道，某公司技术部发生 2 起本年度 PO 级特大事故，造成公司资金损失 400 万，原因如下：

由于 PHP 工程师直接操作上线 redis，执行 keys * wxdb（此处省略）cf8* 这样的命令，导致redis锁住，导致 CPU 飙升，引起所有支付链路卡住，等十几秒结束后，所有的请求流量全部挤压到了 rds 数据库中，使数据库产生了雪崩效应，发生了数据库宕机事件。

该公司表示，如再犯类似事故，将直接开除，并表示之后会逐步收回运维部各项权限。

一个命令损失数百万，这，需要赔偿吗？

代码不规范，同事两行泪，撸码需谨慎！

# KEYS pattern 查找key；pattern 为通配符模式：* 匹配任意多个（含 0 个）字符；? 匹配单个字符；[字符] 匹配括号内任意一个字符[root@localhost ~]# redis-cli# 先切回 0 号库，便于查看其中已有的 key127.0.0.1:6379>SELECT0OK# 已切换到 0 号库# * 通配符匹配当前库下所有 key（数据量大时会遍历阻塞，生产环境慎用）127.0.0.1:6379>KEYS *1)"key:91"# 0 号库下匹配到的 key（节选）2)"key:87"......# 切换到 1 号库127.0.0.1:6379>SELECT1OK# 已切换到 1 号库# 查看 1 号库的所有 key127.0.0.1:6379[1]>KEYS *(empty list orset)# 1 号库为空，没有任何 key# MSET 批量同时设置多组 key value，原子操作127.0.0.1:6379[1]>MSET one1two2three3four4# 一次设置4个keyOK# 批量设置成功# *o* 匹配键名中包含字母 o 的所有 key127.0.0.1:6379[1]>KEYS *o*1)"four"# 匹配到含 o 的 key2)"two"3)"one"# t?? 匹配以 t 开头、后面再跟 2 个任意字符的 key（共 3 个字符）127.0.0.1:6379[1]>KEYS t??1)"two"# 唯一匹配到 two# t[w]* 匹配以 t 开头、第二个字符为 w、后面任意的 key127.0.0.1:6379[1]>KEYS t[w]*1)"two"# 唯一匹配到 two# 查看 1 号库全部 key，确认最终共有 4 个键127.0.0.1:6379[1]>KEYS *1)"three"# 1 号库全部 key（共 4 个）2)"four"3)"two"4)"one"

bgsave

手动在后台执行RDB持久化操作

# 交互式执行；BGSAVE 异步后台执行 RDB 持久化保存，派生子进程把数据写盘，不阻塞当前会话127.0.0.1:6379>BGSAVE Background saving started# 后台保存已启动# 非交互式执行；在 shell 中通过 redis-cli 直接调用同一条 BGSAVE 命令[root@localhost ~]# redis-cli BGSAVEBackground saving started# 后台保存已启动

DBSIZE

返回当前库下所有key数量（DBSIZE key数量）

# DBSIZE 返回当前数据库（当前库）中 key 的总数127.0.0.1:6379>DBSIZE(integer)5000000# 0 号库共有 500 万个 key# 切换到 1 号库127.0.0.1:6379>SELECT1OK# 已切换到 1 号库# 查看 1 号库的 key 数量127.0.0.1:6379[1]>DBSIZE(integer)0# 1 号库为空，key 数为 0

FLUSHDB

强制清空当前库中所有key，此命令慎用（FLUSHDB 清空当前库）

# 先切回 0 号库127.0.0.1:6379[1]>select0OK# 已切回 0 号库# 确认 0 号库现有 key 数量127.0.0.1:6379>DBSIZE(integer)5000000# 0 号库现有 500 万个 key# FLUSHDB 清空当前数据库（仅当前库）的所有数据，不影响其他库127.0.0.1:6379>FLUSHDB#清空db0所有数据；FLUSHDB 只清当前库、不影响其他库OK# 清空成功(2.59s)# 该命令实际耗时 2.59 秒# 再次查看 0 号库 key 数量127.0.0.1:6379>DBSIZE(integer)0# 已被清空，key 数为 0# 切到 1 号库，验证其他库不受影响127.0.0.1:6379>SELECT1#db1数据不影响；切到 1 号库验证其他库未被清空OK# 已切换到 1 号库# 查看 1 号库 key 数量127.0.0.1:6379[1]>DBSIZE(integer)4# 1 号库仍有 4 个 key，证明 FLUSHDB 只清当前库

FLUSHALL

强制清空当前Redis服务器所有数据库中的所有key，即删除所有数据，此命令慎用（FLUSHALL 清空所有库）

# FLUSHALL 清空所有数据库（全部 16 个库）的所有数据，比 FLUSHDB 更危险127.0.0.1:6379>FLUSHALL OK# 已清空所有库的数据# 生产建议修改配置使用rename-command禁用此命令；编辑 Redis 配置文件，用 rename-command 把 FLUSHALL 重命名为空字符串以禁用该命令[root@localhost ~]# vim /etc/redis.conf523rename-command FLUSHALL""#flushdb和flushall 配置和AOF功能冲突，需要设置appendonly no，不区分命令大小写699appendonly no# 关闭 AOF 持久化，与禁用 flush 命令相配合# 测试；重启 redis 服务使配置生效[root@localhost ~]# systemctl restart redis# 重新进入交互式会话[root@localhost ~]# redis-cli# 再次执行已被禁用的 FLUSHALL127.0.0.1:6379>FLUSHALL(error)ERR unknowncommand`FLUSHALL`, with args beginning with:# 命令已被重命名禁用，服务器不再认识它# 此时 FLUSHDB 未被禁用，仍可正常执行127.0.0.1:6379>FLUSHDB OK# FLUSHDB 执行成功，说明只有 FLUSHALL 被禁用

SHUTDOWN

可用版本：>=1.0.0

时间复杂度：O（N)，其中 N 为关机时需要保存的数据库键数量。

SHUTDOWN命令执行以下操作：

• 关闭Redis服务，停止所有客户端连接
• 如果有至少一个保存点在等待，执行SAVE命令
• 如果AOF选项被打开，更新AOF文件
• 关闭redis服务器（server)

如果持久化被打开的话，SHUTDOWN命令会保证服务器正常关闭而不丢失任何数据。

另一方面，假如只是单纯地执行SAVE命令，然后再执行QUIT命令，则没有这一保证一一因为在执行 SAVE之后、执行QUIT之前的这段时间中间，其他客户端可能正在和服务器进行通讯，这时如果执行QUIT就会造成数据丢失。

#建议禁用此指令；编辑配置文件，用 rename-command 将 SHUTDOWN 命令重命名为空字符串来禁用，防止误操作关闭服务[root@localhost ~]# vim /etc/redis.confrename-commandshutdown""# 把 shutdown 命令重命名为空即禁用；命令名不区分大小写