spring cloud bus 默认用 redis 替换 rabbitmq 需引入 spring-cloud-starter-bus-redis，排除 amqp starter，并配置 spring.redis.host/port；其基于 redis pub/sub 实现广播，要求所有实例连接同一 redis 实例，不支持消息持久化与断连重投。
Spring Cloud Bus 默认用 RabbitMQ，怎么换成 Redis？
Spring Cloud Bus 默认依赖 RabbitMQ 或 Kafka，但如果你的基础设施已部署 Redis 且不想引入新中间件，可以切换为 Redis 作为消息代理。关键不是“加 Redis”，而是替换 spring-cloud-starter-bus-amqp 或 spring-cloud-starter-bus-kafka，改用 spring-cloud-starter-bus-redis。
注意两点：
- 必须排除默认的 AMQP starter（否则会冲突启动失败），在 Maven 中用
<exclusions></exclusions>干掉spring-cloud-starter-bus-amqp -
spring-cloud-starter-bus-redis依赖spring-boot-starter-data-redis，确保spring.redis.host、spring.redis.port等基础配置已存在，Bus 才能自动连接并监听springCloudBus频道 - Redis 模式下 Bus 不使用 Stream，而是基于
PUBLISH/SUBSCRIBE，因此要求所有实例连接同一 Redis 实例（或主从同步强一致的集群），否则可能漏收事件
为什么 /actuator/bus-refresh 发送 POST 后配置没刷新？
常见现象是调用 POST /actuator/bus-refresh 返回 200，但目标服务的 @Value 或 @ConfigurationProperties 值没变。根本原因通常是：配置中心未生效 + Bus 未触发重绑定。
检查顺序如下：
- 确认你的服务已正确接入配置中心（如 Spring Cloud Config Server），
bootstrap.yml中有spring.cloud.config.discovery.enabled=true且服务能连上 Config Server - 确认目标服务开启了 Actuator 的
bus-refresh端点：management.endpoints.web.exposure.include=bus-refresh,health,info - 确认 Config Server 的
/actuator/refresh（或 Git 仓库变更）已触发过一次配置拉取——Bus 只负责广播“请重载”，不负责拉新配置；它依赖各实例自己向 Config Server 再请求一次GET /{app}/{profile} - 如果用了
@RefreshScope，确保被注解的 Bean 是在运行时动态创建的（比如 Controller、Service），而非早期初始化的单例（如 DataSource）
@RefreshScope 刷新失败：Bean 重建但字段仍是旧值？
典型错误是给一个带 @Value("${my.timeout:5000}") 的类加了 @RefreshScope，刷新后日志显示 “Recreated bean”，但打印该字段还是 5000——其实不是没刷新，而是你读的是字段快照，不是实时注入值。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
根本原因是：@RefreshScope 是代理模式，只对**方法调用**生效。字段直读绕过了代理，永远拿初始化时的值。
- 把字段访问改为 getter 方法，并确保调用方通过 Spring 容器获取该 Bean（不能 new 或静态引用）
- 或者改用
@ConfigurationProperties+@RefreshScope（推荐），因为它是属性绑定机制，刷新时会重新 bind，字段也会更新 - 避免在
@PostConstruct或构造函数中读取@Value，此时 refresh 尚未发生，且之后也不会回填 - 调试时可用
ApplicationContext.getBean("yourBeanName")强制走代理，再调方法验证
Redis Pub/Sub 在多节点时消息丢失怎么办？
Redis 的 SUBSCRIBE 是连接绑定的，一旦客户端断连（如服务重启、网络抖动），期间发布的消息就彻底丢失——这和 Kafka 的 offset 回溯、RabbitMQ 的 durable queue 有本质区别。
这不是 Bug，是 Redis Pub/Sub 的设计限制。应对方式只有两种：
- 接受最终一致性：靠定时健康检查 + 全量重拉（例如每 5 分钟调一次
/actuator/refresh）兜底 - 放弃原生 Pub/Sub，改用 Redis Streams（需 Spring Boot 2.6+ 和 Spring Data Redis 2.6+），它支持 consumer group 和 pending list，可保证至少一次投递；但 Spring Cloud Bus 目前（2024 年主流版本 4.1.x）仍不原生支持 Streams，需自行扩展
BusEnvironmentPostProcessor和RedisMessageProducer - 生产环境若对可靠性要求高，建议别硬扛 Redis Pub/Sub，直接切回 RabbitMQ/Kafka 更省心
Bus 的 Redis 实现本质是“轻量通知”，不是“可靠消息队列”。别把它当 RocketMQ 用。
