ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Redis 作为 AI Agent 状态中枢的工程实践

Redis 作为 AI Agent 状态中枢的工程实践 1. 项目概述Redis 并未“接入 AI”但 Redis 正在成为 AI 工程落地的关键基础设施最近刷到“Redis 已正式接入 AI”这个标题第一反应是点进去看——结果发现不是 Redis 官方发布了什么 AI 模块也不是 Redis 内核嵌入了大模型推理引擎。它背后的真实含义是大量 AI 工程师、Agent 开发者、MCP 协议实践者正把 Redis 用成 AI 系统里最沉默却最关键的“神经突触”状态暂存、技能调度、上下文缓存、会话持久、工具调用队列、分布式协调……它不生成文字但它让 AI 能记住你三分钟前说要订机票它不写代码但它让 Playwright Agent 知道上一步点击了哪个按钮它不理解协议但它把wss://api.xiaozhi.me/mcp/?tokeneyjhbgcioijfuzi1niisinr5cci6ikpxvcj9.这种动态 token 在毫秒级完成分发与校验。这根本不是一次“功能升级”而是一场静默的范式迁移AI 不再只是跑在 GPU 上的黑盒模型它开始依赖一套轻量、可靠、低延迟的状态中枢系统来组织行为逻辑。而 Redis凭借其单线程原子性、内存级吞吐、丰富的数据结构尤其是 Stream、JSON、TimeSeries、成熟的集群与哨兵方案成了当前阶段最被广泛选择的“AI 状态底座”。关键词里的MCPModel Control Protocol和agent-skills就是典型场景——MCP 协议定义了 AI Agent 如何调用外部工具如浏览器操作、API 请求、数据库查询而这些调用的元信息参数、状态、超时、重试次数、执行结果、中间上下文几乎全部落在 Redis 的 Hash、List 和 Stream 中。Python 作为主流胶水语言通过redis-py驱动完成与这套底座的对接形成“LLM MCP Router Redis State Store”的标准三层架构。所以如果你正打算搭建一个能记住对话历史、支持多步工具调用、可横向扩展的 AI Agent或者正在调试playwright mcp与chrome devtools mcp的协同流程又或者在 RuoYi-Vue-Pro 里集成 MCP 功能时卡在会话状态同步上——那你不是在学 Redis你是在学如何让 AI “有记忆、懂协作、不断进化”。这不是 Redis 的新闻而是 AI 工程化落地的现实切口。2. 核心设计思路为什么是 Redis而不是 SQLite、PostgreSQL 或纯内存字典2.1 从 AI Agent 的真实需求反推存储选型逻辑我们先抛开“Redis 很快”这种泛泛而谈的说法直接拆解一个典型 AI Agent 的运行链条用户输入“帮我查一下今天北京到上海的高铁余票并预订一张二等座。”LLM 解析意图 → 触发query_train_tickets技能MCP 协议定义MCP Router 将请求序列化为 JSON写入任务队列后台 Worker 拉取任务 → 调用铁路 API → 获取 JSON 响应Worker 将响应存入“本次会话上下文” → LLM 再次调用生成预订指令触发book_train_ticket技能 → 提交订单 → 更新会话状态为“已下单”整个过程需支持会话 ID 绑定、多 Worker 并发读写、毫秒级状态更新、失败自动重试、历史回溯现在逐项对比几种常见存储方案需求维度RedisPostgreSQLSQLitePython dict进程内单次读写延迟 0.1ms本地网络~1–5ms磁盘 I/O WAL~0.5–2ms文件锁竞争 0.01ms并发安全单线程原子命令天然无竞态需显式加锁SELECT FOR UPDATEWAL 模式下写入阻塞全库多线程需threading.Lock数据结构适配Stream有序日志、JSON嵌套结构、HashKV 映射、ZSet优先级队列JSONB 支持有限复杂嵌套需 ORM 层转换JSON1 扩展支持弱无原生 Stream仅 dict/list无持久化、无跨进程水平扩展官方 Cluster 模式Slot 分片自动 Failover需 Citus/PGShard配置复杂强一致性代价高无原生分布式能力无法扩展过期策略EXPIRE命令精确控制 TTL支持惰性定期双清理pg_cron DELETE需额外维护无原生 TTL需应用层轮询清理无 TTL需手动管理生命周期运维成本单节点启动即用Docker 一行命令docker run -p 6379:6379 redis需配置 wal_level、max_connections、shared_buffers文件权限、锁冲突、备份策略易出错进程重启即丢失无法用于生产环境提示很多团队一开始用 SQLite 存会话结果在压测时发现database is locked错误频发——因为 SQLite 的写锁是数据库级的而 AI Agent 的每个技能调用都可能触发写操作QPS 一过 50 就排队。Redis 的LPUSH/RPOP对 Stream 的操作是 O(1) 原子的10k QPS 下依然稳定。2.2 Redis 在 MCP 协议栈中的具体角色定位MCP 协议本身是传输层协议它只定义消息格式如{type: tool_call, tool_name: search_web, args: {q: redis mcp implementation}}和通信方式WebSocket 或 HTTP。它不管状态存在哪、怎么持久、谁来协调。这就留出了工程实现空间——而 Redis 成为了事实上的“MCP State Plane”。具体分工如下Session Store会话存储用 Redis Hash 存储{session_id: {user_id, last_active_ts, context_window: [...]}}。Key 设为session:{uuid}TTL 设为 24h。每次 LLM 调用前Router 先HGETALL session:{id}加载上下文调用后HSET session:{id} context_window [...]更新。Task Queue任务队列用 Redis Stream 实现严格有序、可回溯、支持消费者组的队列。MCP Router 发布任务XADD mcp:tasks * type tool_call tool_name query_db args {table:users}Worker 通过XREADGROUP GROUP wg1 consumer1 COUNT 1 STREAMS mcp:tasks 拉取。Stream 天然支持 ACKXACK失败任务可XCLAIM重试。Tool Registry技能注册中心用 Redis JSON 存储所有可用技能元数据。JSON.SET tool:playwright_mcp $.name Playwright Browser $.value {description:Control browser via Playwright,endpoint:http://playwright-worker:8000/mcp}。Agent 启动时JSON.MGET tool:* $.name $.endpoint 批量加载。Distributed Lock分布式锁当多个 Worker 可能同时处理同一会话的并行技能如同时查天气查航班用SET lock:session:{id} {worker_id} NX EX 30实现 30 秒租约锁。NX 保证仅当 key 不存在时设置成功EX 避免死锁。Metrics Tracing指标追踪用 Redis TimeSeries 存储每秒请求数、平均延迟、错误率。TS.CREATE mcp:latency LABELS service mcp_router每次调用后TS.ADD mcp:latency * {latency_ms}。配合 Grafana 可实时监控。这套设计不是拍脑袋定的而是从trae ide burp suite mcp server、ruoyi-vue-pro mcp 集成、playwright mcp等真实项目中沉淀出来的。它们共同验证了一个结论MCP 的协议价值在于解耦而 Redis 的价值在于为解耦后的各组件提供统一、低延迟、高可靠的共享状态视图。2.3 为什么不是其他 NoSQLMongoDB / Elasticsearch 的短板在哪有人会问MongoDB 也有文档模型、索引、TTLElasticsearch 更擅长日志分析为啥不用MongoDB 的短板默认写关注write concern为w:1即主节点写入即返回但若主节点宕机前未同步到副本数据可能丢失——这对“预订车票”类事务性操作是不可接受的。Redis 的 AOF RDB 持久化虽非强一致但可通过appendfsync always配置达到类 WAL 的可靠性且延迟可控。MongoDB 的聚合管道Aggregation Pipeline强大但 AI Agent 几乎不需要复杂 JOIN 或分组统计它需要的是GET/SET/XREAD这类 O(1) 操作。MongoDB 的 BSON 解析开销比 Redis 的纯字符串操作高 3–5 倍。分片集群运维复杂度远高于 Redis Cluster尤其在小规模部署 10 节点时收益远低于成本。Elasticsearch 的短板本质是搜索引擎写入走 Lucene Segment延迟在 1s 级别refresh interval无法满足 AI Agent 对“状态实时可见”的要求比如用户刚提交订单LLM 下一句就要确认“订单已生成单号是 XXX”。不支持原生事务_update_by_query是批量操作无法保证单条记录的原子更新。存储成本高ES 为搜索优化会存储倒排索引、doc_values 等冗余结构同样 1GB 数据ES 占用磁盘通常是 Redis 的 3–4 倍。注意ES 并非无用武之地——它适合存 AI Agent 的全量聊天日志用于合规审计、效果回溯、Prompt 优化但绝不适合做运行时状态存储。这是“冷热分离”的经典案例Redis 是热数据中枢ES 是冷数据仓库。3. 核心细节解析从零搭建一个支持 MCP 的 Redis 状态底座3.1 环境准备MacOS / Windows / Docker 三端实操指南MacOSHomebrew 方式推荐开发环境# 安装 Redis最新稳定版 7.2 brew install redis # 启动服务前台运行方便看日志 redis-server /usr/local/etc/redis.conf # 验证是否正常 redis-cli PING # 返回 PONG 即成功关键配置项/usr/local/etc/redis.confbind 127.0.0.1 ::1→ 仅监听本地避免暴露公网port 6379→ 默认端口MCP Router 默认连接此端口requirepass your_strong_password→ 生产环境必须设密码MCP Token 本身不加密Redis 密码是第一道防线maxmemory 2gb→ 设置内存上限防止 OOMmaxmemory-policy allkeys-lru→ 内存满时自动淘汰最久未用 KeyWindows官方 MSI 安装包避坑指南不要下载 redis-windows 旧版已停止维护无 Stream 支持正确路径访问 https://github.com/microsoftarchive/redis/releases → 下载Redis-x64-7.2.0.msi微软维护的官方分支安装时勾选 “Add Redis to PATH” 和 “Install Redis as a Service”启动服务services.msc→ 找到 “Redis” → 右键启动验证redis-cli.exe -h 127.0.0.1 -p 6379 PINGDocker生产环境首选一键集群# 单节点开发测试 docker run -d --name redis-dev -p 6379:6379 -e REDIS_PASSWORDai2024 redis:7.2-alpine # 三节点集群生产可用自动分片 docker network create redis-net docker run -d --name redis-node1 --network redis-net -p 7001:7001 redis:7.2-alpine redis-server --port 7001 --cluster-enabled yes --cluster-config-file nodes.conf --cluster-node-timeout 5000 --appendonly yes docker run -d --name redis-node2 --network redis-net -p 7002:7002 redis:7.2-alpine redis-server --port 7002 --cluster-enabled yes --cluster-config-file nodes.conf --cluster-node-timeout 5000 --appendonly yes docker run -d --name redis-node3 --network redis-net -p 7003:7003 redis:7.2-alpine redis-server --port 7003 --cluster-enabled yes --cluster-config-file nodes.conf --cluster-node-timeout 5000 --appendonly yes # 初始化集群进入任一容器执行 docker exec -it redis-node1 redis-cli --cluster create 172.18.0.2:7001 172.18.0.3:7002 172.18.0.4:7003 --cluster-replicas 0实操心得Docker 部署时务必挂载--volume /path/to/data:/data保证 AOF/RDB 持久化。集群模式下redis-cli --cluster工具会自动分配 Slot无需手动计算哈希槽16384 个但要注意Key 的哈希槽由{}包裹的字符串决定例如session:{abc123}和session:abc123会被路由到不同节点——所以所有会话 Key 必须带{session_id}标签。3.2 Python 驱动redis-py 的正确用法与性能陷阱安装与基础连接pip install redis4.6.0 # 固定版本避免 5.x 的 breaking changeimport redis from redis import ConnectionPool # ✅ 推荐使用连接池避免频繁创建连接 pool ConnectionPool( host127.0.0.1, port6379, passwordai2024, # 生产环境必填 db0, # 默认 DB 0建议按用途分 DB0会话1队列2技能注册 max_connections20, # 根据 Worker 数量调整一般设为 CPU 核数*2 decode_responsesTrue # 自动 decode bytes → str避免 bxxx 烦恼 ) r redis.Redis(connection_poolpool) # ✅ 测试连接 try: r.ping() print(Redis connected!) except redis.ConnectionError: raise RuntimeError(Failed to connect to Redis)关键数据结构实操示例贴合 MCP 场景1. Session StoreHashdef save_session(session_id: str, user_id: str, context: list): key fsession:{session_id} data { user_id: user_id, last_active_ts: int(time.time()), context_window: json.dumps(context), # Redis 不支持直接存 list/dict ttl_seconds: 86400 # 24h } r.hset(key, mappingdata) r.expire(key, 86400) # 显式设 TTL双重保险 def load_session(session_id: str) - dict: key fsession:{session_id} data r.hgetall(key) if not data: return None # 转换 JSON 字符串为 Python 对象 data[context_window] json.loads(data.get(context_window, [])) return data2. Task QueueStreamdef publish_task(task: dict): 发布 MCP 任务到 Stream task[timestamp] int(time.time() * 1000) # 毫秒时间戳 r.xadd(mcp:tasks, {data: json.dumps(task)}) def consume_tasks(consumer_group: str, consumer_name: str, count: int 1): 消费任务需提前创建消费者组 try: # 创建消费者组仅首次执行 r.xgroup_create(mcp:tasks, consumer_group, id0, mkstreamTrue) except redis.exceptions.ResponseError: pass # 组已存在 messages r.xreadgroup( groupnameconsumer_group, consumernameconsumer_name, streams{mcp:tasks: }, countcount, block5000 # 阻塞 5s避免空轮询 ) if not messages: return [] stream_name, msg_list messages[0] tasks [] for msg_id, fields in msg_list: task_data json.loads(fields[bdata]) tasks.append({ msg_id: msg_id, task: task_data }) return tasks def ack_task(consumer_group: str, stream_name: str, msg_id: str): 标记任务完成 r.xack(stream_name, consumer_group, msg_id)3. Tool RegistryJSONdef register_tool(tool_name: str, tool_spec: dict): 注册技能JSON 格式 key ftool:{tool_name} r.json().set(key, $, tool_spec) r.expire(key, 3600) # 技能元数据 1h 过期支持动态更新 def get_tool(tool_name: str) - dict: 获取技能定义 key ftool:{tool_name} try: return r.json().get(key, $)[0] # 返回根对象 except redis.exceptions.ResponseError: return None # 技能不存在注意事项redis-py的 JSON 方法需 Redis 服务器开启 JSON 模块7.0 默认内置无需额外加载。xreadgroup的block参数至关重要——设为0会永久阻塞设为None会立即返回空生产环境推荐50005s。hgetall返回的是dict[str, str]所有值都是字符串JSON 字段需手动json.loads()这是新手最常踩的坑。3.3 MCP Router 与 Redis 的协同工作流以 Playwright MCP 为例假设你正在实现playwright mcp—— 即用 Playwright 控制浏览器响应 MCP 的tool_call消息。整个流程如下Router 接收 WebSocket 消息来自前端或 LLM{ type: tool_call, tool_name: playwright_navigate, args: {url: https://example.com} }Router 校验技能合法性tool_def get_tool(playwright_navigate) if not tool_def: raise ValueError(fTool {tool_name} not registered)生成唯一任务 ID写入 Streamtask_id str(uuid.uuid4()) task_payload { task_id: task_id, tool_name: playwright_navigate, args: {url: https://example.com}, session_id: sess_abc123, created_at: time.time() } publish_task(task_payload) # 写入 mcp:tasks StreamRouter 立即返回 ACK告知前端“已接收”return {status: accepted, task_id: task_id}Playwright Worker 消费任务# 在 Worker 进程中 while True: tasks consume_tasks(playwright_group, worker_01) for task in tasks: try: # 执行 Playwright 操作 result playwright_navigate(task[task][args][url]) # 将结果写回会话上下文 session load_session(task[task][session_id]) session[context_window].append({ role: tool_result, content: result, tool_call_id: task[task][task_id] }) save_session(task[task][session_id], session[user_id], session[context_window]) # 标记任务完成 ack_task(playwright_group, mcp:tasks, task[msg_id]) except Exception as e: # 记录错误不 ACK任务会 5s 后被其他 Worker 重试 logging.error(fTask {task[msg_id]} failed: {e})这个流程里Redis 扮演了三个不可替代的角色解耦器Router 和 Worker 完全异步无需知道对方 IP 或状态缓冲器当 Playwright 浏览器启动慢~2sStream 可暂存数百任务避免前端超时状态同步器save_session更新后下一个 LLM 调用load_session就能拿到最新上下文实现“记忆”。4. 实操过程详解从本地验证到生产部署的完整链路4.1 本地快速验证5 分钟跑通一个 MCP Redis Demo目标模拟用户问“查天气”Router 发送weather_api任务Worker 调用真实 API结果写回会话。步骤 1启动 Redisredis-server --port 6379 --requirepass ai2024 --maxmemory 512mb步骤 2注册天气技能# register_weather.py import redis import json r redis.Redis(host127.0.0.1, port6379, passwordai2024, decode_responsesTrue) r.json().set(tool:weather_api, $, { name: weather_api, description: Get current weather by city name, endpoint: https://api.openweathermap.org/data/2.5/weather, auth_required: False }) print(Weather tool registered!)步骤 3启动 Router模拟# router.py import redis import json import uuid import time r redis.Redis(host127.0.0.1, port6379, passwordai2024, decode_responsesTrue) def handle_mcp_call(city: str): task_id str(uuid.uuid4()) task { task_id: task_id, tool_name: weather_api, args: {q: city, appid: your_api_key}, session_id: demo_session } r.xadd(mcp:tasks, {data: json.dumps(task)}) print(f[Router] Sent task {task_id} for city {city}) return task_id # 模拟用户请求 handle_mcp_call(Beijing)步骤 4启动 Worker模拟# worker.py import redis import json import requests import time r redis.Redis(host127.0.0.1, port6379, passwordai2024, decode_responsesTrue) def consume_and_process(): try: r.xgroup_create(mcp:tasks, weather_group, id0, mkstreamTrue) except: pass while True: messages r.xreadgroup( groupnameweather_group, consumernameweather_worker, streams{mcp:tasks: }, count1, block1000 ) if not messages: continue stream, msg_list messages[0] for msg_id, fields in msg_list: task_data json.loads(fields[data]) print(f[Worker] Processing {task_data[task_id]}) # 调用真实天气 API此处简化为 mock weather_data { city: task_data[args][q], temp: 25.3, condition: Sunny } # 写回会话 session_key fsession:{task_data[session_id]} r.hset(session_key, last_weather, json.dumps(weather_data)) r.expire(session_key, 3600) # ACK r.xack(mcp:tasks, weather_group, msg_id) print(f[Worker] Done {task_data[task_id]}) if __name__ __main__: consume_and_process()步骤 5验证结果# 查看会话状态 redis-cli -a ai2024 hgetall session:demo_session # 输出1) last_weather 2) {\city\: \Beijing\, \temp\: 25.3, \condition\: \Sunny\} # 查看 Stream 长度 redis-cli -a ai2024 xlen mcp:tasks # 应为 1整个过程无需任何框架纯 Python redis-py5 分钟内可验证 MCP 任务流转闭环。这就是 Redis 作为 AI 底座的威力——极简起步无限扩展。4.2 生产环境部署高可用、安全、可观测的 Redis 集群架构设计三节点 Cluster Sentinel 备份Client (Router/Worker) ↓ [Redis Cluster: 3 Master Nodes] ←→ [Sentinel Quorum: 3 Nodes] ↓ Persistent Storage (AOF RDB)Cluster 节点负责分片、读写、自动故障转移FailoverSentinel 节点独立于 Cluster监控主从状态自动触发故障转移提供高可用配置端点Docker Compose 部署脚本production.ymlversion: 3.8 services: # Redis Cluster Nodes redis-node1: image: redis:7.2-alpine command: redis-server /usr/local/etc/redis.conf volumes: - ./redis/conf/node1.conf:/usr/local/etc/redis.conf - ./redis/data/node1:/data ports: - 7001:7001 - 17001:17001 networks: - redis-net redis-node2: image: redis:7.2-alpine command: redis-server /usr/local/etc/redis.conf volumes: - ./redis/conf/node2.conf:/usr/local/etc/redis.conf - ./redis/data/node2:/data ports: - 7002:7002 - 17002:17002 networks: - redis-net redis-node3: image: redis:7.2-alpine command: redis-server /usr/local/etc/redis.conf volumes: - ./redis/conf/node3.conf:/usr/local/etc/redis.conf - ./redis/data/node3:/data ports: - 7003:7003 - 17003:17003 networks: - redis-net # Sentinel Nodes sentinel1: image: redis:7.2-alpine command: redis-sentinel /usr/local/etc/sentinel.conf volumes: - ./redis/conf/sentinel1.conf:/usr/local/etc/sentinel.conf ports: - 26379:26379 depends_on: - redis-node1 - redis-node2 - redis-node3 networks: - redis-net sentinel2: image: redis:7.2-alpine command: redis-sentinel /usr/local/etc/sentinel.conf volumes: - ./redis/conf/sentinel2.conf:/usr/local/etc/sentinel.conf ports: - 26380:26380 depends_on: - redis-node1 - redis-node2 - redis-node3 networks: - redis-net sentinel3: image: redis:7.2-alpine command: redis-sentinel /usr/local/etc/sentinel.conf volumes: - ./redis/conf/sentinel3.conf:/usr/local/etc/sentinel.conf ports: - 26381:26381 depends_on: - redis-node1 - redis-node2 - redis-node3 networks: - redis-net networks: redis-net: driver: bridge关键配置文件node1.conf 示例port 7001 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes appendfilename appendonly.aof save # 关闭 RDB专注 AOF 持久化 maxmemory 4gb maxmemory-policy allkeys-lru requirepass your_production_password bind 0.0.0.0 protected-mode noPython 客户端连接生产集群from redis.cluster import RedisCluster # 使用 Sentinel 提供的 master 地址自动发现 startup_nodes [ {host: localhost, port: 26379}, {host: localhost, port: 26380}, {host: localhost, port: 26381} ] rc RedisCluster( startup_nodesstartup_nodes, passwordyour_production_password, decode_responsesTrue, socket_connect_timeout5, socket_timeout5, retry_on_timeoutTrue ) # 自动路由到正确 Slot rc.set(session:{abc123}, value) # {abc123} 确保 key 路由到同一节点实操心得密码必须全局统一Cluster 模式下所有节点密码相同否则AUTH失败。Key 的 hash tag 是生命线所有会话 Key 必须用{session_id}包裹否则数据分散导致HGETALL无法一次拉取完整上下文。Sentinel 的 quorum 设置sentinel monitor mymaster 127.0.0.1 7001 2表示 3 个 Sentinel 中 2 个同意才触发 Failover避免脑裂。4.3 可观测性建设用 Redis 自身能力监控 AI 系统健康度Redis 内置INFO命令就是最好的监控源无需额外 Agent# 实时查看关键指标 redis-cli -a your_password INFO memory | grep -E (used_memory_human|mem_fragmentation_ratio) redis-cli -a your_password INFO clients | grep -E (connected_clients|client_recent_max_input_buffer) redis-cli -a your_password INFO stats | grep -E (instantaneous_ops_per_sec|rejected_connections|expired_keys) redis-cli -a your_password INFO cluster | grep -E (cluster_state|known_nodes)Grafana 面板关键指标Prometheus redis_exporterredis_connected_clients连接数突增可能预示 Router 泄漏连接redis_keyspace_hits_total / (redis_keyspace_hits_total redis_keyspace_misses_total)缓存命中率 90% 需检查会话 TTL 或 Key 设计redis_expired_keys_total每秒过期 Key 数异常升高说明会话清理逻辑有问题redis_cluster_stats_messages_sent_total集群内部消息量持续高位可能网络分区告警规则示例Prometheus Alert- alert: RedisMemoryUsageHigh expr: redis_memory_used_bytes{jobredis} / redis_memory_max_bytes{jobredis} 0.85 for: 5m labels: severity: warning annotations: summary: Redis memory usage high description: Redis instance {{ $labels.instance }} memory usage is {{ $value | humanizePercentage }} - alert: RedisClusterDown expr: redis_cluster_state{jobredis} 0 for: 1m labels: severity: critical annotations: summary: Redis Cluster is down description: Redis cluster state is down on {{ $labels.instance }}这套监控体系能让你在 AI Agent 出现“突然忘记用户”、“任务堆积不处理”、“响应变慢”等问题时5 分钟内定位到是 Redis 内存满、连接数爆、还是集群分裂——这才是工程化的底气。5. 常见问题与排查技巧实录从新手到专家的避坑指南5.1 连接类问题ConnectionRefused / Authentication Failed现象Python 报错redis.exceptions.ConnectionError: Error 111 connecting to 127.0.0.1:6379. Connection refused.排查路径ps aux | grep redis确认进程是否存在netstat -tuln | grep :6379确认端
返回列表