Rspamd中Redis主从架构的声誉系统配置优化

在邮件过滤系统Rspamd中，Redis被广泛用于存储和管理IP/域名声誉数据。当采用Redis主从复制架构时，配置不当可能导致写入操作失败。本文将深入分析该问题并提供专业解决方案。

问题现象分析

在生产环境中部署Redis主从集群（1主2从）时，若简单配置所有节点地址：

backend "redis" {
      servers = "主节点:6379,从节点1:6379,从节点2:6379";
}

会出现"READONLY You can't write against a read only replica"错误。这是因为：

1. Rspamd默认对所有配置的Redis节点尝试写入操作
2. Redis从节点默认处于只读模式
3. 写入请求被拒绝导致声誉数据更新失败

核心解决方案

方案一：读写分离配置

Rspamd支持显式声明读写节点：

backend "redis" {
    read_servers = "从节点1:6379,从节点2:6379";
    write_servers = "主节点:6379"; 
}

优势：

• 明确区分读写流量
• 避免向从节点写入数据
• 符合Redis主从架构设计原则

方案二：哨兵模式集成

对于使用Redis Sentinel的场景：

backend "redis" {
    sentinels = "哨兵节点1:26379,哨兵节点2:26379";
    master_name = "指定的主节点名称";
}

特点：

• 自动发现当前主节点
• 故障转移时自动切换写入目标
• 需确保哨兵集群配置正确

最佳实践建议

1. 生产环境推荐：优先采用哨兵模式，具备自动故障转移能力
2. 监控要求：无论采用哪种方案，都应监控：
   • Redis节点状态
   • Rspamd写入错误日志
   • 主从同步延迟
3. 性能考量：读写分离可有效分摊负载，从节点处理读请求，主节点专注写操作

技术原理延伸

Rspamd的声誉系统采用多种Redis数据结构：

• 哈希表存储详细评分
• 有序集合维护排名
• 过期机制实现自动清理

在主从架构下，这些数据结构的所有写操作（HSET/ZADD/EXPIRE等）都必须定向到主节点。通过正确配置，既可保证数据一致性，又能充分利用复制架构的扩展性。

对于大规模部署，建议结合Redis Cluster方案，但需注意Rspamd对Redis集群模式的支持限制。无论采用何种架构，清晰的读写分离策略都是确保系统稳定运行的关键。