Valkey已禁用持久化仍出现DB保存日志，IoT传感器日志异常求助

一、先解决Valkey意外触发RDB快照的问题 #

你看到的DB saved on disk日志说明Valkey在执行RDB快照，这和你配置中save ""禁用快照的设置矛盾，核心原因是配置未正确生效：

• 检查docker-compose配置：确认自定义Valkey配置文件是否正确挂载到容器默认路径（通常为/etc/valkey/valkey.conf）。如果仅本地编写配置但未挂载，容器会加载Valkey默认配置，而默认配置包含save 900 1等自动快照规则，会触发RDB。
• 验证配置有效性：进入Valkey容器执行valkey-cli config get save，若返回结果不是""而是类似900 1 300 10 60 10000，则说明配置未生效。需调整docker-compose的volumes字段，确保自定义配置覆盖默认文件。
• 强制禁用快照的保险措施：即使配置了save ""，也可在docker-compose的command中添加--save ""参数强制生效，示例：

  services:
    valkey:
      image: valkey/valkey
      volumes:
        - ./valkey.conf:/etc/valkey/valkey.conf
      command: valkey-server /etc/valkey/valkey.conf --save ""
  

二、修复业务逻辑的并发竞态问题 #

原逻辑中“检查键是否存在→不存在则写日志”是两步非原子操作，在并发场景下（哪怕仅两个传感器同时上报）会出现竞态条件：两个请求同时执行EXISTS检查，均得到“键不存在”的结果，随后都写入日志，但实际其中一个请求会先创建键，导致另一个请求的日志为误报。

解决核心是将检查与操作合并为原子操作：

方案1：用SETNX简化逻辑 #

若你的存储逻辑是“键不存在则创建并记录日志，存在则直接更新数据”，可使用SETNX原子命令替代分步操作：

# 仅当键不存在时才创建，返回1表示创建成功（键之前不存在），返回0表示键已存在
SETNX sensor:1:data "传感器数据内容"

若命令返回1，再执行日志记录；返回0则直接更新数据即可，从根源避免竞态。

方案2：用Lua脚本实现复杂原子逻辑 #

若业务逻辑更复杂（如需要关联旧值判断），可通过Lua脚本将整个逻辑打包为原子操作：

local sensor_key = KEYS[1]
local sensor_value = ARGV[1]
local exists = redis.call('EXISTS', sensor_key)

if exists == 0 then
    # 切换到日志数据库（假设日志存储在DB 1）
    redis.call('SELECT', 1)
    redis.call('LPUSH', 'sensor_initial_logs', '传感器[' .. sensor_key .. ']首次上报：' .. os.time())
    redis.call('SELECT', 0)
end

# 无论键是否存在，都更新最新数据
redis.call('SET', sensor_key, sensor_value)
return exists

Valkey会保证整个脚本的执行过程不会被其他请求打断，彻底消除并发竞态问题。

三、结合你的特殊观察点补充 #

问题出现时两个传感器日志同时生成，大概率是并发竞态+快照触发的主进程阻塞共同导致：快照fork子进程时，主进程会短暂阻塞，此时传感器请求堆积；阻塞结束后，多个请求同时执行EXISTS检查，均判定键不存在，进而同时写入日志。解决上述两个问题后，这类异常即可消失。

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