租户ID需通过RabbitMQ消息头（如X-Tenant-ID）显式透传至消费端，消费端从中提取并设置到TenantContext，再由AbstractRoutingDataSource的determineCurrentLookupKey()方法返回该ID以触发数据源切换；必须在消费入口设值、退出前reset，避免上下文泄漏。
租户 ID 怎么透传到 RabbitMQ 消费端并用于数据源切换
关键不是 RabbitMQ 本身支持多租户，而是你得把租户上下文带进去。RabbitMQ 的 Message 不自动携带线程上下文，所以消费端拿不到 TenantContextHolder 里的值，除非你显式传递。
推荐做法是在生产端把租户标识塞进消息头（MessageProperties），而不是消息体里——这样不污染业务 payload，也方便中间件做路由或审计：
MessageProperties props = new MessageProperties();
props.setHeader("X-Tenant-ID", "tenant-a");
Message message = new Message(payload, props);
消费端用 ChannelAwareMessageListener 或 Spring AMQP 的 @RabbitListener 注解配合 Message 参数获取头信息：
@RabbitListener(queues = "order.queue")
public void onOrder(Message message) {
String tenantId = (String) message.getMessageProperties().getHeaders().get("X-Tenant-ID");
TenantContext.setTenantId(tenantId); // 触发动态数据源切换
// 后续 DAO 操作会自动走对应租户的数据源
}
- 别用
ThreadLocal在生产端设租户 ID 后期望消费端能继承——RabbitMQ 消费是新线程，上下文断了 - 避免在消息体 JSON 里重复嵌套
tenantId字段，既冗余又容易和业务字段耦合 - 如果用了 Spring Cloud Sleuth，注意
MessageProperties头可能被覆盖，建议用明确前缀如X-Tenant-ID
Spring Boot + AbstractRoutingDataSource 怎么根据租户动态选数据源
AbstractRoutingDataSource 是核心，但它只管“查”，不管“设”。你必须在每次数据库操作前，通过 determineCurrentLookupKey() 返回正确的 key，而这个 key 必须由当前租户 ID 决定。
立即学习“Java免费学习笔记（深入）”；
典型陷阱是：没清空 ThreadLocal，导致上一个请求的租户 ID 泄漏到下一个请求；或者在异步线程（比如 RabbitMQ 消费线程）里忘了设置。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 确保
TenantContext是基于ThreadLocal<String>实现，且提供reset()方法 - 在消费方法入口调用
TenantContext.setTenantId(...)，退出前务必TenantContext.reset()（建议用 try-finally） -
determineCurrentLookupKey()里直接 returnTenantContext.getTenantId()，不要加默认值或 fallback——出错比静默路由更安全 - 数据源 Map 初始化时，key 必须和
setTenantId()传入的字符串完全一致（大小写、空格、前缀都敏感）
RabbitMQ 连接工厂能不能按租户隔离？一般不需要
绝大多数场景下，**不要为每个租户建独立的 CachingConnectionFactory**。RabbitMQ 是共享通道型中间件，连接池复用率高，单独配一套连接工厂反而引发资源泄漏、心跳超时、连接数爆炸等问题。
真正要隔离的是「数据」层面：消息内容、消费逻辑、数据库连接。RabbitMQ 本身靠 exchange/routing key/queue 做逻辑隔离就够了。
- 如果租户间有严格网络隔离要求（比如不同 VPC、不同 RabbitMQ 集群），才考虑多
ConnectionFactory，但这时通常已超出 Spring AMQP 自动配置范围，需手动注册多个RabbitTemplate - 共用连接工厂时，确保
channelCacheSize足够（默认 25），避免高并发下 channel 创建瓶颈 - 别在监听器里 new 一个
ConnectionFactory—— 它重量级，且无法被 Spring 管理生命周期
事务怎么跨租户消息 + 数据库操作保证一致性
RabbitMQ 和数据库事务无法跨系统两阶段提交。如果你在消费端一边写 DB 一边发下游消息，必须接受“最多一次”或“至少一次”的语义，不能强求 ACID。
常用折中方案是：DB 写成功后，再发消息（业务上可接受延迟）；或用本地事务表 + 定时任务补偿（适合对实时性要求不高但强一致的场景）。
- 别在同一个数据库事务里调用
rabbitTemplate.convertAndSend()—— Spring AMQP 默认不参与 JPA/Hibernate 事务 - 如果启用了
publisher-confirms，记得消费端处理失败时主动 nack 并拒绝重试（避免无限循环刷脏数据） - 租户维度的幂等性必须自己做：用
message.getMessageProperties().getDeliveryTag()或业务唯一键（如 order_id + tenant_id）做去重
动态数据源路由本身不复杂，难的是上下文传递的时机和清理点——漏掉一次 reset()，就可能让后续所有消息都写错库。
