systemctl status redis 是最直接、最可靠的判断方式——只要服务由 systemd 管理（CentOS 7+ 默认如此），这条命令就能明确告诉你 Redis 是否在运行、有没有崩溃重启、最近一次日志报了什么错。
systemctl status redis 是最直接、最可靠的判断方式——只要服务由 systemd 管理（CentOS 7+ 默认如此），这条命令就能明确告诉你 Redis 是否在运行、有没有崩溃重启、最近一次日志报了什么错。
用 systemctl status redis 看服务级状态
这是第一道检查线，不依赖网络或 Redis 自身是否响应，只看进程和服务管理器的状态。
- 输出中出现
Active: active (running)表示服务已启动且未被 systemd 杀掉 - 如果显示
failed或inactive (dead)，说明服务根本没起来，不用急着连redis-cli，先查日志：journalctl -u redis -n 50 --no-pager - 注意
Loaded:行里的路径，比如/etc/systemd/system/redis.service，说明你用的是自定义 unit 文件；如果是/usr/lib/systemd/system/redis.service，则是包自带配置——改配置前得确认来源 - 别只扫一眼“active”，还要看
Main PID:对应的进程是否存在：ps -p 1234（把 1234 换成实际 PID），避免僵尸服务假死
用 redis-cli ping 验证服务可响应
systemctl 说“活”不代表 Redis 能干活。常见情况是进程卡住、内存 OOM 被内核 kill 后残留 systemd 状态，或者配置错监听地址导致本地连不上。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 执行
redis-cli ping，返回PONG才算真正可用；超时或报Connection refused就得排查网络或 bind 配置 - 如果 Redis 绑了
127.0.0.1但你用redis-cli -h localhost连失败，可能是localhost解析走 IPv6（::1），而 Redis 没监听它——换成redis-cli -h 127.0.0.1或检查bind配置项 - 非默认端口记得加
-p 6380；带密码的要加-a "mypass"，否则ping会卡住或报NOAUTH
用 redis-cli info 查关键指标是否异常
服务活着、能响应，不等于健康。很多线上问题（如内存爆满、连接数打满、慢查询堆积）不会让服务挂，但会让业务变慢甚至失败。
-
redis-cli info memory | grep -E "(used_memory_human|mem_fragmentation_ratio)"：看used_memory_human是否接近maxmemory，mem_fragmentation_ratio > 1.5可能有内存碎片问题 -
redis-cli info clients | grep "connected_clients"：对比maxclients配置值，超过 90% 就该预警 -
redis-cli info stats | grep -E "(rejected_connections|expired_keys|evicted_keys)"：出现rejected_connections说明连接被打满；evicted_keys非零且持续增长，说明maxmemory-policy在频繁淘汰 - 别用裸
info——输出太长容易漏关键字段，按需加模块名，比如info cpu或info replication
端口和进程级兜底检查
当 systemctl 和 redis-cli 都失灵时，回归操作系统层确认“物理存在”。
-
ss -tlnp | grep ':6379'（比netstat更快更准）：确认端口确实在监听，且pid和systemctl显示的一致；如果没输出，Redis 根本没绑定端口 -
ps aux | grep redis-server：找真实进程，注意区分redis-server（主进程）和redis-sentinel（哨兵进程），别看错行 -
lsof -i :6379：如果ss没结果但lsof有，可能是 SELinux 或 cgroup 限制了 socket 可见性（少见但真实存在） - 防火墙干扰常被忽略：
iptables -L -n | grep 6379或firewall-cmd --list-ports，尤其在云服务器上，安全组和系统防火墙可能双重重叠拦截
真正难的不是“怎么查”，而是查完发现 systemctl status 显示 running、ping 返回 PONG、info memory 看着也正常，但业务却间歇性超时——这时候得盯 latency 和 slowlog，而不是反复刷 status。
