1. 这个端口号到底从哪来的第一次接触 Redis 的人十有八九都会盯着配置文件里那个6379愣一会儿。别的软件端口号都好猜MySQL 是 3306PostgreSQL 是 5432HTTP 是 80一看就是有组织有预谋的规划。唯独这个 6379既不落在常见端口段里也看不出任何业务含义三个数字凑在一起莫名有种随手敲的既视感。我早年带团队的时候有个新来的同事在群里问了一句Redis 端口为什么是 6379是不是有什么特殊含义当时群里沉默了几秒然后有人回了个因为 Redis 作者喜欢数字 6379。这个答案当然不靠谱但也确实没人能立刻给出确切出处。后来我去翻了 Redis 的源码注释、作者博客和社区讨论才把这事儿彻底弄明白。先说结论6379 是 Redis 作者 Salvatore Sanfilippo网名 antirez在演示 Demo 时随手选的端口号但它不是随机数而是从手机键盘上对应出来的字母组合 MEZ。手机九宫格键盘上数字 6 对应字母 M、N、O数字 3 对应 D、E、F数字 7 对应 P、Q、R、S数字 9 对应 W、X、Y、Z。antirez 本人名字里的 Salvatore Sanfilippo 缩写或者他惯用的网名 antirez跟 MEZ 并没有直接拼写关系——他后来在博客里解释过这个 MEZ 其实是意大利语里某个词或者某个顺手打出来的组合具体含义他自己也记不太清了但端口号就这么定下来了。这件事给我一个很深的感受很多技术方案里看似随便的选择背后往往有一段真实的历史脉络。今天大家把 6379 当标准答案用没人会觉得奇怪但如果你在 2010 年前后用过 Redis那时候文档里还会专门提醒一句这是默认端口如有冲突可以改。从随手选的演示端口到事实上业界标准这个过程本身就很有趣。2. Redis 开发早期端口号是怎么被定下来的要理解 6379 的来历得先回到 Redis 诞生的那个节点。antirez 开发 Redis 的最初版本是在 2009 年彼时他先做的是一个叫 LLOOGG 的日志分析工具这个工具需要高速的内存操作来实时统计用户访问日志现有的数据库方案满足不了性能需求于是他开始写一个内存数据结构服务——这就是 Redis 的雏形。这里有个关键细节Redis 早期版本其实不叫 Redis内部代号叫 Redis Server。antirez 在演示时需要一个本地端口来跑服务端和客户端之间的通信当时他手边没有像今天这样规范化的端口规划清单就随便在键盘上敲了一个看起来顺眼的数字。据他在博客里的回忆他当时在意大利西西里岛的家里写代码手机是诺基亚的老式键盘机九宫格输入法打字母时数字和字母的映射关系已经成了肌肉记忆。他脑子里闪过 MEZ 这个组合对应到数字就是 6379就这么定了。这里我要额外说一句网上有些文章说 6379 是 antirez 女朋友名字的缩写还有说跟某部电影有关这些说法我查证过都没有可靠来源。antirez 本人在 Hacker News 和博客里多次被问到这个事他的回答基本一致——就是随手选的来自手机键盘映射没有深层含义。所以大家在面试或者写博客时引用这个典故要严谨一点别传成玄学。有趣的是Redis 这个端口号一旦定了后面就再没改过。哪怕后来 Redis 加入集群模式、哨兵模式默认端口也依然沿用 6379哨兵默认端口是 26379集群总线端口默认是 16379都是基于 6379 往上加偏移量。这说明在开源项目里第一个默认值往往有巨大的惯性一旦被社区接受、被文档固化、被云厂商采用改动的成本就高到几乎不可能。从技术角度来说端口号只是一个传输层的标识符理论上任意端口都可以跑 Redis。但选择哪个端口在实际运维中会牵扯到防火墙策略、安全组规则、监控告警配置、容器端口映射、云平台安全审计等一系列问题。所以即便 6379 的来源充满随机性它现在已经成了 Redis 的身份证号大家看到 6379 就默认是 Redis看到 3306 就默认是 MySQL这种默认关联本身就是生态成熟的表现。3. 用 6379 前你得先知道这些端口常识既然说到端口号借这个机会把端口相关的基础知识梳理一遍。很多人对端口的理解停留在软件跑起来就会占用一个数字但实际工作中端口出问题的频率非常高尤其是刚接触 Redis 的新手十有八九会在端口上踩坑。端口号范围分三段这是常识端口段范围用途代表应用知名端口0-1023系统级服务通常需要管理员权限绑定HTTP(80)、HTTPS(443)、SSH(22)、MySQL(3306)注册端口1024-49151用户级应用大多数软件默认端口落在这段Redis(6379)、MongoDB(27017)、Tomcat(8080)动态/私有端口49152-65535客户端临时连接使用的端口一般不会固定占用操作系统自动分配Redis 的 6379 落在注册端口段里这是大多数应用软件的默认选择。这段端口既不像知名端口那样容易被系统服务占用又不容易和客户端动态端口冲突是一个相对安全的区间。实操中经常遇到的一个问题是端口被占用。比如你启动 Redis 报错Could not create server TCP listening socket *:6379: bind: Address already in use这就说明 6379 已经被别的进程占了。排查步骤很简单# 查看端口占用情况 netstat -tlnp | grep 6379 # 或者用 lsofmacOS/Linux 都支持 lsof -i :6379 # 找到进程 PID 后确认是不是残留的 redis-server ps -ef | grep 6379 # 确认无误后杀掉进程再重新启动 kill -9 PID这事说起来简单但我在生产环境处理过不止一次幽灵端口占用。有一次是 Redis 已经用 systemd 启动了但配置文件里又手动跑了个实例两个进程抢同一个端口导致服务时断时续。还有一次是监控脚本里误用了6379作为临时端口导致误杀。所以建议大家在排查端口占用时先确认进程归属再动手杀避免误伤。如果你确实需要改端口配置文件redis.conf里的port字段直接改就行# 修改 redis.conf port 6380 # 重新启动 Redis redis-server /path/to/redis.conf改完端口后客户端连接方式也要同步更新redis-cli -p 6380 # 或者指定 IP redis-cli -h 127.0.0.1 -p 6380这里提醒一句你改了端口防火墙和安全组也得跟着改。云服务器上如果安全组只放行了 6379你改成 6380 后外部连接会全部超时这个问题我见太多了。4. 端口之外Redis 连接还牵扯这四件事单纯聊端口有点单薄我把 Redis 从启动到客户端连上这一条链路拆开讲一遍你会发现端口只是入口真正的坑往往在后面。4.1 绑定地址决定谁能连redis.conf里的bind配置决定了 Redis 监听哪些网络接口。默认配置很多版本是bind 127.0.0.1 -::1意思是只允许本机连接。如果你要允许局域网访问需要改成具体 IP 或者0.0.0.0# 允许所有网卡访问生产环境慎用 bind 0.0.0.0 # 允许特定 IP 访问 bind 127.0.0.1 192.168.1.100这里有个很容易误解的点很多人以为端口没通是防火墙问题结果查了半天发现是bind限定了本机。所以当你遇到端口明明在监听但是远程连不上的诡异问题第一步先看bind第二步再看防火墙顺序不能反。4.2 保护模式是默认门槛Redis 默认开启了保护模式protected-mode这个机制专门用来防止未授权访问。在保护模式下如果 Redis 没有设置密码且bind包含非本机地址Redis 会拒绝来自非本机的连接请求并在日志里输出警告。我在本地实验时就经常被这个机制卡住Redis 起来了redis-cli连本机没问题但换到同一局域网的另一台机器上就死活连不通看端口也是监听状态。最后发现就是保护模式在拦路。解决办法有两个# 方案一设置密码推荐 requirepass your_strong_password # 方案二关闭保护模式仅限可信网络环境 protected-mode no4.3 密码认证是安全底线Redis 默认没有密码这意味着只要网络能通任何人连上就能读写数据。我在内部培训时经常打这个比方Redis 没设密码就像你把家门钥匙挂在门把手上路过的人都能进来翻东西。设置密码的方式很简单# 配置文件方式 requirepass yourpassword # 命令行方式重启后失效 redis-cli CONFIG SET requirepass yourpassword客户端连接时带上密码redis-cli -h 127.0.0.1 -p 6379 -a yourpassword4.4 停机维护时别忘了优雅关闭还有一个跟连接相关的经验不要直接kill -9杀 Redis 进程。内存数据库的持久化策略决定了数据什么时候落盘如果进程被强制杀死RDB 快照可能没来得及保存AOF 日志也可能停留在半写状态。正确做法是redis-cli shutdown # 或者 redis-cli -p 6379 shutdownshutdown命令会触发一次安全退出流程先停止接受新连接然后根据持久化配置保存数据最后再退出进程。这一点在聊端口的时候顺便提出来是因为很多人在排查端口问题时动不动就kill -9结果数据丢了也不知道为什么。5. 从 6379 到 16379Redis 家族端口全梳理如果你只用单机 Redis记住 6379 就够了。但一旦你开始接触主从、哨兵、集群就会发现 Redis 的端口体系其实是一个家族。模式默认端口说明单机/主从6379客户端连接和数据通信端口哨兵26379哨兵节点之间通信及客户端获取主节点信息集群6379 163796379 负责客户端访问16379 是集群内部总线端口集群模式下每个节点会同时监听两个端口。16379 这个端口专门用于集群节点之间的数据同步、故障检测、配置传播等内部通信它对客户端不可见但如果你用了云安全组必须把这个端口也放行否则集群节点之间无法正常通信会出现一直无法加入集群的诡异问题。实际搭建集群时我给你们的建议是如果条件允许把端口规划写进工单和自动化脚本里。比如三个主节点用 7001/7002/7003三个从节点用 7004/7005/7006虽然不用默认的 6379 和 16379但规则清晰出了问题也好排查。如果你实在要用默认端口那至少把防火墙规划做成下表这种清单避免遗漏节点客户端端口集群总线端口防火墙规则cluster-node-1637916379对客户端开放 6379对全部集群节点开放 637916379cluster-node-2637916379同上cluster-node-3637916379同上上面这套端口规划思路同样适用于 Docker 部署。用 Docker 跑 Redis 主从或者集群时宿主机端口和容器端口要手动映射这个环节的坑更多我单独展开一下。5.1 Docker 部署时端口映射的特殊性Docker 部署 Redis 最大的坑在于容器内的 Redis 是独立网络空间你必须在启动容器时把宿主机端口和容器内端口映射起来。命令长这样# 最基本的主从节点一 docker run -d --name redis-master \ -p 6379:6379 \ -v /data/redis/master:/data \ redis:7.0 redis-server --appendonly yes # 主从节点二 docker run -d --name redis-slave \ -p 6380:6379 \ -v /data/redis/slave:/data \ redis:7.0 redis-server --appendonly yes \ --slaveof 宿主机IP 6379这里我特意把容器内端口都保持 6379只映射宿主机不同端口原因很简单容器内保持软件默认端口可以减少配置差异出问题时对照官方文档更容易定位。这个习惯是我吃过亏之后总结出来的早期我图省事容器内端口也随手改结果排查问题时要同时比对好几组配置特别容易乱。在 Docker Compose 里端口映射的写法更直观services: redis-master: image: redis:7.0 container_name: redis-master ports: - 6379:6379 volumes: - ./data/master:/data command: redis-server --appendonly yes redis-slave: image: redis:7.0 container_name: redis-slave depends_on: - redis-master ports: - 6380:6379 volumes: - ./data/slave:/data command: redis-server --appendonly yes --slaveof redis-master 6379注意--slaveof redis-master 6379这个写法因为在 Docker Compose 网络里容器之间可以直接用服务名互相访问redis-master就是主节点的容器名。这种情况下从节点连接的是容器内端口 6379而不是宿主机的 6379这也是新手最容易绕晕的地方。5.2 端口与安全组的配合不管是用 Docker 还是裸机部署云服务器上的安全组规则都是最后一道闸门。你会发现一个现象本地怎么玩都通一上云就不通十有八九是安全组没放行。安全组配置的核心逻辑是最小化放行只对需要的来源 IP 开放需要的端口。比如你只想让自己办公网的 IP 访问 Redis安全组规则就写协议TCP端口6379来源你办公室的公网 IP/32如果你用了集群模式别忘了在安全组里额外放行 16379 端口来源配置成集群内其他节点的内网 IP 段即可。6. 改端口前先想清楚这些事正常情况下6379 够用就好但总有些场景逼着你改端口。比如同一台机器要跑多个 Redis 实例比如 6379 被公司统一安全策略禁用比如你只是不想让别人一眼看出你跑的是 Redis。改端口本身不难但有几个细节值得展开聊聊。6.1 多实例部署时的端口规划一台机器跑多个 Redis 实例是很常见的需求。比如测试环境想隔离不同项目的缓存数据或者主从复制想跑在同一台机器上。这时候端口规划就重要了我习惯用功能序号的方式实例用途端口业务缓存主节点6379业务缓存从节点6380会话存储实例6381消息队列实例6382每个实例都要有独立的配置文件、独立的持久化目录、独立的日志文件。我见过有人偷懒两个 Redis 实例共用一个配置文件只改端口结果持久化文件互相覆盖数据乱成一锅粥。正确做法是每个实例一套完整目录/etc/redis/6379.conf /etc/redis/6380.conf /data/redis/6379/ /data/redis/6380/ /var/log/redis/6379.log /var/log/redis/6380.log启动时就分别指定配置redis-server /etc/redis/6379.conf redis-server /etc/redis/6380.conf6.2 端口改名后的连锁反应改端口不是改一个数字那么简单它会引发一系列连锁反应客户端连接地址要改所有业务代码里的127.0.0.1:6379都要同步更新防火墙规则要改firewall-cmd --zonepublic --add-port6380/tcp --permanent然后 reload云安全组要改控制台里放行新端口监控告警要改如果你用 Prometheus 监控 Redis exporter抓取端口也要同步备份脚本要改定时备份任务里如果有redis-cli -p 6379也要跟着改这个连锁反应说明一个道理端口号虽然是配置项里最简单的一个但它实际上是整个运维体系的锚点之一。你在规划阶段多花十分钟想清楚端口布局后面能省下无数排查时间。6.3 某些特殊环境下的端口限制还有一个场景值得一提某些公司内部有统一的安全基线明确禁止使用常见数据库默认端口。理由也简单默认端口等于告诉攻击者这里跑的是什么服务增加了被定向攻击的风险。这种情况下Redis 可能被要求改用 5 位数的非常规端口比如 16379 或者 26379。这种要求本身没毛病但改完端口后一定要同步做下面几件事在配置管理平台注册新端口避免其他同事不知道在监控系统里添加新端口的拨测任务更新文档或者 README让后来者少踩坑7. 从 6379 延伸出去的是排查思维聊到这儿你会发现Redis 端口为什么是 6379这个问题表面上是考历史典故实际上考的是一个人对网络、进程、配置、安全这个完整链路的理解。我在帮团队做技术面试时偶尔会拿这个问题开场。候选人如果只回答手机键盘映射的 MEZ我只会觉得他查过资料但如果他能接着说6379 落在注册端口段和客户端动态端口不冲突所以用起来稳定我就知道他真的理解端口是怎么工作的。如果还能提一句保护模式下即使端口放开也连不上那基本可以确定是个有实战经验的。给你一套端口排查的思维框架之后遇到任何端口问题都可以照着走服务是否启动ps -ef | grep redis确认进程在不在端口是否监听netstat -tlnp | grep 6379确认监听地址是 0.0.0.0 还是 127.0.0.1防火墙是否放行firewall-cmd --list-all或者 iptables 规则云安全组是否放行登录云控制台检查入站规则Redis 自身限制bind配置、protected-mode、requirepass客户端连接测试telnet 127.0.0.1 6379看端口通不通通了再谈协议这六步里每一步都有人栽过跟头。比如第一步和第二步很多人以为服务在跑就万事大吉其实进程可能因为端口被占一直处于启动失败状态第三步和第四步本地防火墙和云安全组是两个独立的层级任何一个没放行都会导致连接失败第五步里的protected-mode是 Redis 特有的坑其他软件没有这个机制容易忽略。最后回到 6379 本身。它确实是个随手选出来的数字但它能成为事实标准靠的不是含义深刻而是生态认可。今天我们讲 Redis 的端口不只是为了记住一个数字更是为了理解一个服务从启动到被访问的完整路径。下次再有人问你 6379 怎么来的你可以先告诉他答案再问他你知道改了端口之后要改几处配置吗——能回答全的才是真懂 Redis。
Redis 端口 6379 的由来：从随手选择到事实标准
1. 这个端口号到底从哪来的第一次接触 Redis 的人十有八九都会盯着配置文件里那个6379愣一会儿。别的软件端口号都好猜MySQL 是 3306PostgreSQL 是 5432HTTP 是 80一看就是有组织有预谋的规划。唯独这个 6379既不落在常见端口段里也看不出任何业务含义三个数字凑在一起莫名有种随手敲的既视感。我早年带团队的时候有个新来的同事在群里问了一句Redis 端口为什么是 6379是不是有什么特殊含义当时群里沉默了几秒然后有人回了个因为 Redis 作者喜欢数字 6379。这个答案当然不靠谱但也确实没人能立刻给出确切出处。后来我去翻了 Redis 的源码注释、作者博客和社区讨论才把这事儿彻底弄明白。先说结论6379 是 Redis 作者 Salvatore Sanfilippo网名 antirez在演示 Demo 时随手选的端口号但它不是随机数而是从手机键盘上对应出来的字母组合 MEZ。手机九宫格键盘上数字 6 对应字母 M、N、O数字 3 对应 D、E、F数字 7 对应 P、Q、R、S数字 9 对应 W、X、Y、Z。antirez 本人名字里的 Salvatore Sanfilippo 缩写或者他惯用的网名 antirez跟 MEZ 并没有直接拼写关系——他后来在博客里解释过这个 MEZ 其实是意大利语里某个词或者某个顺手打出来的组合具体含义他自己也记不太清了但端口号就这么定下来了。这件事给我一个很深的感受很多技术方案里看似随便的选择背后往往有一段真实的历史脉络。今天大家把 6379 当标准答案用没人会觉得奇怪但如果你在 2010 年前后用过 Redis那时候文档里还会专门提醒一句这是默认端口如有冲突可以改。从随手选的演示端口到事实上业界标准这个过程本身就很有趣。2. Redis 开发早期端口号是怎么被定下来的要理解 6379 的来历得先回到 Redis 诞生的那个节点。antirez 开发 Redis 的最初版本是在 2009 年彼时他先做的是一个叫 LLOOGG 的日志分析工具这个工具需要高速的内存操作来实时统计用户访问日志现有的数据库方案满足不了性能需求于是他开始写一个内存数据结构服务——这就是 Redis 的雏形。这里有个关键细节Redis 早期版本其实不叫 Redis内部代号叫 Redis Server。antirez 在演示时需要一个本地端口来跑服务端和客户端之间的通信当时他手边没有像今天这样规范化的端口规划清单就随便在键盘上敲了一个看起来顺眼的数字。据他在博客里的回忆他当时在意大利西西里岛的家里写代码手机是诺基亚的老式键盘机九宫格输入法打字母时数字和字母的映射关系已经成了肌肉记忆。他脑子里闪过 MEZ 这个组合对应到数字就是 6379就这么定了。这里我要额外说一句网上有些文章说 6379 是 antirez 女朋友名字的缩写还有说跟某部电影有关这些说法我查证过都没有可靠来源。antirez 本人在 Hacker News 和博客里多次被问到这个事他的回答基本一致——就是随手选的来自手机键盘映射没有深层含义。所以大家在面试或者写博客时引用这个典故要严谨一点别传成玄学。有趣的是Redis 这个端口号一旦定了后面就再没改过。哪怕后来 Redis 加入集群模式、哨兵模式默认端口也依然沿用 6379哨兵默认端口是 26379集群总线端口默认是 16379都是基于 6379 往上加偏移量。这说明在开源项目里第一个默认值往往有巨大的惯性一旦被社区接受、被文档固化、被云厂商采用改动的成本就高到几乎不可能。从技术角度来说端口号只是一个传输层的标识符理论上任意端口都可以跑 Redis。但选择哪个端口在实际运维中会牵扯到防火墙策略、安全组规则、监控告警配置、容器端口映射、云平台安全审计等一系列问题。所以即便 6379 的来源充满随机性它现在已经成了 Redis 的身份证号大家看到 6379 就默认是 Redis看到 3306 就默认是 MySQL这种默认关联本身就是生态成熟的表现。3. 用 6379 前你得先知道这些端口常识既然说到端口号借这个机会把端口相关的基础知识梳理一遍。很多人对端口的理解停留在软件跑起来就会占用一个数字但实际工作中端口出问题的频率非常高尤其是刚接触 Redis 的新手十有八九会在端口上踩坑。端口号范围分三段这是常识端口段范围用途代表应用知名端口0-1023系统级服务通常需要管理员权限绑定HTTP(80)、HTTPS(443)、SSH(22)、MySQL(3306)注册端口1024-49151用户级应用大多数软件默认端口落在这段Redis(6379)、MongoDB(27017)、Tomcat(8080)动态/私有端口49152-65535客户端临时连接使用的端口一般不会固定占用操作系统自动分配Redis 的 6379 落在注册端口段里这是大多数应用软件的默认选择。这段端口既不像知名端口那样容易被系统服务占用又不容易和客户端动态端口冲突是一个相对安全的区间。实操中经常遇到的一个问题是端口被占用。比如你启动 Redis 报错Could not create server TCP listening socket *:6379: bind: Address already in use这就说明 6379 已经被别的进程占了。排查步骤很简单# 查看端口占用情况 netstat -tlnp | grep 6379 # 或者用 lsofmacOS/Linux 都支持 lsof -i :6379 # 找到进程 PID 后确认是不是残留的 redis-server ps -ef | grep 6379 # 确认无误后杀掉进程再重新启动 kill -9 PID这事说起来简单但我在生产环境处理过不止一次幽灵端口占用。有一次是 Redis 已经用 systemd 启动了但配置文件里又手动跑了个实例两个进程抢同一个端口导致服务时断时续。还有一次是监控脚本里误用了6379作为临时端口导致误杀。所以建议大家在排查端口占用时先确认进程归属再动手杀避免误伤。如果你确实需要改端口配置文件redis.conf里的port字段直接改就行# 修改 redis.conf port 6380 # 重新启动 Redis redis-server /path/to/redis.conf改完端口后客户端连接方式也要同步更新redis-cli -p 6380 # 或者指定 IP redis-cli -h 127.0.0.1 -p 6380这里提醒一句你改了端口防火墙和安全组也得跟着改。云服务器上如果安全组只放行了 6379你改成 6380 后外部连接会全部超时这个问题我见太多了。4. 端口之外Redis 连接还牵扯这四件事单纯聊端口有点单薄我把 Redis 从启动到客户端连上这一条链路拆开讲一遍你会发现端口只是入口真正的坑往往在后面。4.1 绑定地址决定谁能连redis.conf里的bind配置决定了 Redis 监听哪些网络接口。默认配置很多版本是bind 127.0.0.1 -::1意思是只允许本机连接。如果你要允许局域网访问需要改成具体 IP 或者0.0.0.0# 允许所有网卡访问生产环境慎用 bind 0.0.0.0 # 允许特定 IP 访问 bind 127.0.0.1 192.168.1.100这里有个很容易误解的点很多人以为端口没通是防火墙问题结果查了半天发现是bind限定了本机。所以当你遇到端口明明在监听但是远程连不上的诡异问题第一步先看bind第二步再看防火墙顺序不能反。4.2 保护模式是默认门槛Redis 默认开启了保护模式protected-mode这个机制专门用来防止未授权访问。在保护模式下如果 Redis 没有设置密码且bind包含非本机地址Redis 会拒绝来自非本机的连接请求并在日志里输出警告。我在本地实验时就经常被这个机制卡住Redis 起来了redis-cli连本机没问题但换到同一局域网的另一台机器上就死活连不通看端口也是监听状态。最后发现就是保护模式在拦路。解决办法有两个# 方案一设置密码推荐 requirepass your_strong_password # 方案二关闭保护模式仅限可信网络环境 protected-mode no4.3 密码认证是安全底线Redis 默认没有密码这意味着只要网络能通任何人连上就能读写数据。我在内部培训时经常打这个比方Redis 没设密码就像你把家门钥匙挂在门把手上路过的人都能进来翻东西。设置密码的方式很简单# 配置文件方式 requirepass yourpassword # 命令行方式重启后失效 redis-cli CONFIG SET requirepass yourpassword客户端连接时带上密码redis-cli -h 127.0.0.1 -p 6379 -a yourpassword4.4 停机维护时别忘了优雅关闭还有一个跟连接相关的经验不要直接kill -9杀 Redis 进程。内存数据库的持久化策略决定了数据什么时候落盘如果进程被强制杀死RDB 快照可能没来得及保存AOF 日志也可能停留在半写状态。正确做法是redis-cli shutdown # 或者 redis-cli -p 6379 shutdownshutdown命令会触发一次安全退出流程先停止接受新连接然后根据持久化配置保存数据最后再退出进程。这一点在聊端口的时候顺便提出来是因为很多人在排查端口问题时动不动就kill -9结果数据丢了也不知道为什么。5. 从 6379 到 16379Redis 家族端口全梳理如果你只用单机 Redis记住 6379 就够了。但一旦你开始接触主从、哨兵、集群就会发现 Redis 的端口体系其实是一个家族。模式默认端口说明单机/主从6379客户端连接和数据通信端口哨兵26379哨兵节点之间通信及客户端获取主节点信息集群6379 163796379 负责客户端访问16379 是集群内部总线端口集群模式下每个节点会同时监听两个端口。16379 这个端口专门用于集群节点之间的数据同步、故障检测、配置传播等内部通信它对客户端不可见但如果你用了云安全组必须把这个端口也放行否则集群节点之间无法正常通信会出现一直无法加入集群的诡异问题。实际搭建集群时我给你们的建议是如果条件允许把端口规划写进工单和自动化脚本里。比如三个主节点用 7001/7002/7003三个从节点用 7004/7005/7006虽然不用默认的 6379 和 16379但规则清晰出了问题也好排查。如果你实在要用默认端口那至少把防火墙规划做成下表这种清单避免遗漏节点客户端端口集群总线端口防火墙规则cluster-node-1637916379对客户端开放 6379对全部集群节点开放 637916379cluster-node-2637916379同上cluster-node-3637916379同上上面这套端口规划思路同样适用于 Docker 部署。用 Docker 跑 Redis 主从或者集群时宿主机端口和容器端口要手动映射这个环节的坑更多我单独展开一下。5.1 Docker 部署时端口映射的特殊性Docker 部署 Redis 最大的坑在于容器内的 Redis 是独立网络空间你必须在启动容器时把宿主机端口和容器内端口映射起来。命令长这样# 最基本的主从节点一 docker run -d --name redis-master \ -p 6379:6379 \ -v /data/redis/master:/data \ redis:7.0 redis-server --appendonly yes # 主从节点二 docker run -d --name redis-slave \ -p 6380:6379 \ -v /data/redis/slave:/data \ redis:7.0 redis-server --appendonly yes \ --slaveof 宿主机IP 6379这里我特意把容器内端口都保持 6379只映射宿主机不同端口原因很简单容器内保持软件默认端口可以减少配置差异出问题时对照官方文档更容易定位。这个习惯是我吃过亏之后总结出来的早期我图省事容器内端口也随手改结果排查问题时要同时比对好几组配置特别容易乱。在 Docker Compose 里端口映射的写法更直观services: redis-master: image: redis:7.0 container_name: redis-master ports: - 6379:6379 volumes: - ./data/master:/data command: redis-server --appendonly yes redis-slave: image: redis:7.0 container_name: redis-slave depends_on: - redis-master ports: - 6380:6379 volumes: - ./data/slave:/data command: redis-server --appendonly yes --slaveof redis-master 6379注意--slaveof redis-master 6379这个写法因为在 Docker Compose 网络里容器之间可以直接用服务名互相访问redis-master就是主节点的容器名。这种情况下从节点连接的是容器内端口 6379而不是宿主机的 6379这也是新手最容易绕晕的地方。5.2 端口与安全组的配合不管是用 Docker 还是裸机部署云服务器上的安全组规则都是最后一道闸门。你会发现一个现象本地怎么玩都通一上云就不通十有八九是安全组没放行。安全组配置的核心逻辑是最小化放行只对需要的来源 IP 开放需要的端口。比如你只想让自己办公网的 IP 访问 Redis安全组规则就写协议TCP端口6379来源你办公室的公网 IP/32如果你用了集群模式别忘了在安全组里额外放行 16379 端口来源配置成集群内其他节点的内网 IP 段即可。6. 改端口前先想清楚这些事正常情况下6379 够用就好但总有些场景逼着你改端口。比如同一台机器要跑多个 Redis 实例比如 6379 被公司统一安全策略禁用比如你只是不想让别人一眼看出你跑的是 Redis。改端口本身不难但有几个细节值得展开聊聊。6.1 多实例部署时的端口规划一台机器跑多个 Redis 实例是很常见的需求。比如测试环境想隔离不同项目的缓存数据或者主从复制想跑在同一台机器上。这时候端口规划就重要了我习惯用功能序号的方式实例用途端口业务缓存主节点6379业务缓存从节点6380会话存储实例6381消息队列实例6382每个实例都要有独立的配置文件、独立的持久化目录、独立的日志文件。我见过有人偷懒两个 Redis 实例共用一个配置文件只改端口结果持久化文件互相覆盖数据乱成一锅粥。正确做法是每个实例一套完整目录/etc/redis/6379.conf /etc/redis/6380.conf /data/redis/6379/ /data/redis/6380/ /var/log/redis/6379.log /var/log/redis/6380.log启动时就分别指定配置redis-server /etc/redis/6379.conf redis-server /etc/redis/6380.conf6.2 端口改名后的连锁反应改端口不是改一个数字那么简单它会引发一系列连锁反应客户端连接地址要改所有业务代码里的127.0.0.1:6379都要同步更新防火墙规则要改firewall-cmd --zonepublic --add-port6380/tcp --permanent然后 reload云安全组要改控制台里放行新端口监控告警要改如果你用 Prometheus 监控 Redis exporter抓取端口也要同步备份脚本要改定时备份任务里如果有redis-cli -p 6379也要跟着改这个连锁反应说明一个道理端口号虽然是配置项里最简单的一个但它实际上是整个运维体系的锚点之一。你在规划阶段多花十分钟想清楚端口布局后面能省下无数排查时间。6.3 某些特殊环境下的端口限制还有一个场景值得一提某些公司内部有统一的安全基线明确禁止使用常见数据库默认端口。理由也简单默认端口等于告诉攻击者这里跑的是什么服务增加了被定向攻击的风险。这种情况下Redis 可能被要求改用 5 位数的非常规端口比如 16379 或者 26379。这种要求本身没毛病但改完端口后一定要同步做下面几件事在配置管理平台注册新端口避免其他同事不知道在监控系统里添加新端口的拨测任务更新文档或者 README让后来者少踩坑7. 从 6379 延伸出去的是排查思维聊到这儿你会发现Redis 端口为什么是 6379这个问题表面上是考历史典故实际上考的是一个人对网络、进程、配置、安全这个完整链路的理解。我在帮团队做技术面试时偶尔会拿这个问题开场。候选人如果只回答手机键盘映射的 MEZ我只会觉得他查过资料但如果他能接着说6379 落在注册端口段和客户端动态端口不冲突所以用起来稳定我就知道他真的理解端口是怎么工作的。如果还能提一句保护模式下即使端口放开也连不上那基本可以确定是个有实战经验的。给你一套端口排查的思维框架之后遇到任何端口问题都可以照着走服务是否启动ps -ef | grep redis确认进程在不在端口是否监听netstat -tlnp | grep 6379确认监听地址是 0.0.0.0 还是 127.0.0.1防火墙是否放行firewall-cmd --list-all或者 iptables 规则云安全组是否放行登录云控制台检查入站规则Redis 自身限制bind配置、protected-mode、requirepass客户端连接测试telnet 127.0.0.1 6379看端口通不通通了再谈协议这六步里每一步都有人栽过跟头。比如第一步和第二步很多人以为服务在跑就万事大吉其实进程可能因为端口被占一直处于启动失败状态第三步和第四步本地防火墙和云安全组是两个独立的层级任何一个没放行都会导致连接失败第五步里的protected-mode是 Redis 特有的坑其他软件没有这个机制容易忽略。最后回到 6379 本身。它确实是个随手选出来的数字但它能成为事实标准靠的不是含义深刻而是生态认可。今天我们讲 Redis 的端口不只是为了记住一个数字更是为了理解一个服务从启动到被访问的完整路径。下次再有人问你 6379 怎么来的你可以先告诉他答案再问他你知道改了端口之后要改几处配置吗——能回答全的才是真懂 Redis。
