不能直接用@Primary切换Redis数据源，因其仅指定启动时默认Bean，无法运行时动态路由；需用ThreadLocal持有当前线程的ConnectionFactory，并配合AOP在方法级按需绑定与清理。
为什么不能直接用 @Primary 注解切换 Redis 数据源
Spring Boot 的 RedisTemplate 默认是单例 Bean，启动时就绑定了一个 LettuceConnectionFactory（或 JedisConnectionFactory）。哪怕你配置了多个 RedisConnectionFactory Bean，@Primary 只能指定「默认用哪一个」，无法在运行时按需切换——它不是动态路由机制。
真正要实现「每个请求走不同 Redis 实例」，得绕过 Spring 容器的自动注入逻辑，在调用前手动绑定连接工厂。这时候 ThreadLocal 就成了最轻量、最可控的上下文载体。
怎么用 ThreadLocal 持有当前线程的 RedisConnectionFactory
核心思路：不替换 RedisTemplate 本身，而是让它每次执行命令前，从 ThreadLocal 中取出当前线程应使用的连接工厂，临时构建一次连接。
关键点：
-
RedisTemplate本身不支持运行时换ConnectionFactory，所以得包装一层代理或重写execute方法 - 推荐继承
RedisTemplate，覆写getConnectionFactory()，让它返回ThreadLocal.get()的值 -
ThreadLocal必须在请求入口（如@Controller方法、Filter 或 AOP）中显式 set，并在 finally 块 clear，否则线程复用（如 Tomcat 线程池）会导致脏数据 - 示例片段：
public class DynamicRedisTemplate extends RedisTemplate<string object> {
private static final ThreadLocal<redisconnectionfactory> connectionFactoryHolder
= ThreadLocal.withInitial(() -> null);
@Override
public RedisConnectionFactory getConnectionFactory() {
RedisConnectionFactory factory = connectionFactoryHolder.get();
return factory != null ? factory : super.getConnectionFactory();
}
public static void setConnectionFactory(RedisConnectionFactory factory) {
connectionFactoryHolder.set(factory);
}
public static void clearConnectionFactory() {
connectionFactoryHolder.remove();
}
}</redisconnectionfactory></string>
如何配合 AOP 在方法上声明目标 Redis 实例
硬编码 DynamicRedisTemplate.setConnectionFactory(...) 太侵入。更实用的是自定义注解 + AOP，在方法执行前后自动绑定/清理。
需要准备：
- 定义注解：
@Target(METHOD)+@Retention(RUNTIME)，比如叫@UseRedis("cluster-a") - AOP 切面拦截该注解，根据参数值（如
"cluster-a"）从 Spring 容器里查出对应命名的RedisConnectionFactoryBean - 注意：Bean 名必须和注解值一致，或维护一个 Map 映射（如
Map） - 切面内必须 try-finally，确保
clearConnectionFactory()执行，否则线程污染风险极高
常见错误现象：ERR wrong number of arguments for 'get' command 或连接超时——大概率是上一个请求没 clean，当前线程拿着旧连接工厂去连了错误地址。
为什么不用 AbstractRoutingDataSource 那套思路
AbstractRoutingDataSource 是 JDBC 场景专用，靠重写 determineCurrentLookupKey() 返回数据源名。但 Redis 没有等价的「路由数据源」抽象类，Lettuce/Jedis 都不提供类似 SPI。
强行模仿会踩这些坑：
- 自己封装
DynamicConnectionFactory，但它内部仍需持有一组真实连接工厂，且每次getConnection()都要 new 连接（性能差）、或缓存连接（状态管理复杂） - 无法兼容
RedisTemplate的序列化器配置（因为序列化器是绑定在RedisTemplate上的，不是 ConnectionFactory） - 事务（
SessionCallback）场景下，同一 callback 内多次操作可能被路由到不同实例，破坏原子性
所以，绕过连接工厂层、在 RedisTemplate 层做动态代理，是最小侵入、最可控的选择。真正的难点不在切换逻辑，而在确保 ThreadLocal 的生命周期与请求完全对齐——漏掉一次 clear()，问题就会在压测或长连接场景下突然爆发。
