Docker中Redis开启notify-keyspace-events KEA后客户端无法接收事件

我来帮你梳理下Docker环境下Redis键空间事件收不到的排查思路，结合你提到本地实例正常、配置文件已挂载的情况，大概率是Docker启动细节或网络层面的问题，试试下面这些步骤：

1. 确认容器内Redis的配置确实生效 #

首先要排除“配置文件挂载了但没被正确加载”的情况：

• 进入Redis容器执行命令：

  docker exec -it <你的Redis容器名> redis-cli config get notify-keyspace-events
  

  如果返回结果不是"KEA"，说明配置没生效。这时候要检查你的Docker启动命令：
  • 如果你用docker run启动时额外加了--notify-keyspace-events参数，会覆盖配置文件里的设置，比如docker run redis redis-server --notify-keyspace-events ""会直接清空事件配置。
  • 确保启动命令明确指定加载你的配置文件，比如：

    docker run -v /本地路径/redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.conf
    

2. 验证容器内是否能正常触发事件 #

先在容器内部测试，排除客户端网络问题：

1. 打开第一个终端，进入容器并订阅键空间事件：

   docker exec -it <你的Redis容器名> redis-cli
   # 订阅默认db（0）的所有键空间和键事件
   PSUBSCRIBE __keyspace@0__:* __keyevent@0__:*
   

2. 打开第二个终端，进入容器执行写操作：

   docker exec -it <你的Redis容器名> redis-cli SET test_key "hello"
   

3. 回到第一个终端，如果能收到类似message: __keyspace@0__:test_key, set的消息，说明容器内Redis的事件功能正常，问题出在外部客户端的连接或订阅方式上；如果收不到，那还是配置加载的问题。

3. 检查外部客户端的连接与订阅方式 #

如果容器内测试正常，外部客户端收不到，排查这几点：

• 端口映射是否正确：确保Docker run时加了-p 6379:6379（或你自定义的端口），客户端连接的是主机的对应端口。
• 订阅命令是否正确：键空间事件需要用模式订阅（PSUBSCRIBE），而不是普通订阅（SUBSCRIBE）。如果客户端用了SUBSCRIBE __keyspace@0__:*，是收不到事件的，必须用PSUBSCRIBE。
• 数据库编号是否匹配：如果你客户端连接的不是默认db 0，订阅时要替换成对应的编号，比如__keyspace@1__:*对应db 1的事件。
• 跨容器网络问题：如果客户端在另一个Docker容器里，要确保两个容器在同一自定义网络中（不要用默认的bridge网络），并通过容器名/容器IP连接Redis，而不是主机IP。

4. Dockerfile构建镜像的细节优化（针对你的构建场景） #

在Windows上构建Linux镜像时，容易遇到文件权限或换行符的问题：

• 复制配置文件后，添加权限设置：

  COPY redis.conf /usr/local/etc/redis/redis.conf
  RUN chmod 644 /usr/local/etc/redis/redis.conf
  

  确保Redis进程有读取配置文件的权限。
• 启动命令明确指定配置文件：

  CMD ["redis-server", "/usr/local/etc/redis/redis.conf"]
  

  避免Redis使用默认配置启动。
• 检查Windows下的redis.conf换行符：Windows的CRLF换行符在Linux容器里可能导致Redis解析配置出错，建议把配置文件转换成LF换行符后再复制到镜像中。

先从容器内的配置验证和事件测试入手，逐步缩小问题范围，应该能快速定位到原因。

内容的提问来源于stack exchange，提问作者GreenEyedAndy