AWS ElastiCache多副本配置下Redis Scan命令返回结果不一致问题

核心原因 #

你的猜测方向正确，但更精准的问题点是：

• Scan命令的cursor值完全绑定单个Redis节点——每个节点独立维护自身的遍历状态，cursor仅对当前节点有效，无法在不同节点间复用。
• 当使用replicasClient时，ElastiCache多副本配置下，客户端默认会以轮询策略分发请求到不同副本节点。这就导致：第一次Scan请求落到副本A，返回cursor X；第二次请求可能切换到副本B，用cursor X继续扫描，但副本B的cursor X对应的遍历进度和副本A完全无关，相当于在副本B上从X开始重新遍历，直接破坏了Scan的连续性，最终造成部分键遗漏（甚至重复）。
• 1主1副时无问题，是因为只有一个副本节点，所有Scan请求都落在同一个节点上，cursor的连续性得以保持，因此能完整遍历所有键。

解决方案 #

1. 切换到主节点执行扫描 #

直接使用主节点客户端（而非副本客户端）执行Scan，主节点数据权威完整，且不存在节点切换问题：

def scan(pattern: String): Seq[String] = {
    val CHUNKSIZE = 10000  
    val buffer = ListBuffer[String]()
    var index = 0 
    do { 
        val cursor = synchronized { 
            Await.result({ 
                // 替换为指向主节点的客户端实例
                masterClient.scan(index, Some(CHUNKSIZE), Some(pattern)) 
            } 
        } , 1.minute) 
        buffer.addAll(cursor.data) 
        index = cursor.index 
        } while (index > 0) 
    buffer.toSeq 
}

2. 绑定单个副本节点执行扫描 #

如果必须用副本节点减轻主节点压力，需确保整个Scan迭代过程固定连接同一个副本节点，避免客户端轮询切换：

• 直接创建指向单个副本节点的独立客户端实例，而非使用自动轮询的replicasClient；
• 或修改客户端负载均衡策略，在一次Scan会话中保持连接同一个节点（具体配置需参考etaty库的客户端参数）。

3. 验证副本同步状态 #

确认所有副本节点已完成与主节点的数据同步：

• 登录每个副本节点执行INFO replication命令，检查master_link_status为up，sync_full状态正常，避免因副本数据未完全同步导致结果缺失。

补充说明 #

即便扫描期间键集合固定，跨节点的Scan也会因cursor不兼容导致结果异常——每个节点的遍历状态独立，cursor无法在不同节点间复用。

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