Redis 不支持 Spring @Transactional，因其无回滚机制且事务不与数据库联动；混合操作需解耦，用最终一致性、Lua 脚本或分布式事务框架保障一致性。
Redis 本身没有 @Transactional 对应的事务机制
Spring 的 @Transactional 是为 JDBC（如 MySQL、PostgreSQL）设计的，底层依赖 DataSourceTransactionManager 管理数据库连接和提交/回滚。Redis 没有 ACID 事务语义中的“回滚”能力——它的 EXEC 只保证命令按序执行，但一旦某条命令失败（比如类型错误），其余命令仍会继续执行，不会自动撤销前面已成功执行的操作。
所以当你在加了 @Transactional 的方法里混用 Redis 和 DB 操作时：
- 数据库操作受 Spring 事务控制，异常时可回滚
- Redis 操作完全不受影响，
redisTemplate.opsForValue().increment()返回null或执行成功，都跟 Spring 事务无关 - 更危险的是：如果事务最终回滚，DB 数据还原了，但 Redis 里的计数器、缓存、分布式锁等早已被修改，造成状态不一致
@Transactional 回滚时 Redis 连接可能被提前关闭
Spring 在事务回滚阶段会释放绑定的数据库连接，同时也会清理当前线程绑定的资源。某些 Redis 客户端（尤其是老版本 lettuce 或配置不当的 jedis）在事务上下文结束时，会误判为资源清理时机，主动关闭或重置 Redis 连接池中的连接，导致后续 Redis 调用（如 increment）返回 null ——这不是 Redis 故障，而是客户端被“连带清理”了。
典型现象：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 早上首次调用失败，返回
null - 重启后正常，因为连接池重建
- 日志里看不到 Redis 报错，但
redisTemplate的execute方法返回空值
混合操作必须显式解耦，不能依赖 @Transactional 覆盖 Redis
如果你需要“DB 写入 + Redis 更新”原子性，@Transactional 无法提供保障，必须换策略：
- 用「最终一致性」：DB 成功后再发消息（如 RabbitMQ / Kafka）异步更新 Redis，配合补偿任务
- 用「Redis 事务 + Lua 脚本」兜底：把多个 Redis 操作封装进一个 Lua 脚本，保证原子执行（注意：这仍不与 DB 事务联动）
- 避免在同一个
@Transactional方法里直接调用redisTemplate写操作；读可以，写建议移出事务边界，或改用@CacheEvict/@CachePut等声明式缓存注解（它们不参与事务，但行为可预测） - 若必须强一致，考虑用 Seata 等分布式事务框架，但代价是复杂度和性能开销显著上升
最容易被忽略的一点：@Transactional 不会拦截 RedisTemplate 的任何方法
Spring AOP 的 @Transactional 切面只织入到被代理 Bean 的 public 方法上，而 redisTemplate.opsForValue().increment() 是链式调用，最终落到 RedisCallback 或 SessionCallback 执行，这些回调不在事务代理链路中。哪怕你把整个方法标为 @Transactional(rollbackFor = Exception.class)，Redis 那行代码也从来不会经过事务拦截器——它只是普通 Java 方法调用。
换句话说：@Transactional 对 Redis 操作根本“看不见”，也就谈不上“生效”或“失效”，它压根就不负责那一层。
