两年前接手一套订单中台对接项目时碰到的第一个需求就很别扭老系统的回执消息跑在一套 ActiveMQ 上新接入的物流平台只肯通过他们自己的 broker 投递轨迹数据。两套 broker 地址不同、账号不同、连队列命名风格都不一样可中间层只有一个 Spring 应用。换句话说这个spring 项目必须同时连接两个 activemq 服务器还要保证消息不串门、启动不互相拖累、一个挂掉另一个照常跑。这类需求在系统整合、并购后的双中台并存、灰度迁移过渡期非常常见但 Spring 官方文档几乎都是围绕一个应用一个 ConnectionFactory写的真到要连两套时坑全在细节里。下面这套东西适合已经能跑通单 broker、正准备上双 broker 的开发者也适合被消息发错地方只连上一个折磨过的同行对照排查。1. 先把场景说清楚什么情况下要并联两套 ActiveMQ1.1 三种最常见的真实动因第一种是系统整合期的双活并存。两家业务合并各自的中台都有一套自己维护多年的 broker谁也不敢先动手迁。这种情况下两套 broker 不是临时状态可能共存半年以上中间层必须稳定支撑双向收发。这类场景的特点是消息量大、可靠性要求高方案要按长期方案设计不能凑合。第二种是跨组织对接的隔离要求。外部合作方只允许通过他们指定的 broker 通道投递数据安全和运维边界卡得很死你既不能让他连你的也不能把你的地址给他。此时项目里就要同时维护内部 bus和外部 bus两条链路两条链路的 SLA、账号权限、消息格式都不一样。第三种是灰度迁移。老 broker 还在承载存量流量新 broker 已经开始接入增量流量Spring 应用作为消费端和发送端要同时向两端收发靠业务开关逐步切流。这种场景对两套连接互不干扰要求最高因为你要随时能关掉其中一条链路做回滚。我在实际项目里遇到的是第一种和第三种叠加存量走 A broker新渠道走 B broker未来还要把 A 的量逐步迁到 B。所以最终的配置不是简单加一个 bean而是把连接、模板、监听容器三层都做了按 broker 隔离的设计。1.2 为什么不用单 broker 多队列或网络桥接凑合有人会问能不能让两套 broker 做网络桥接network of brokers或者让一侧转发到一个公共 broker 上Spring 只连一个技术上可行但要看代价。网络桥接解决的是 broker 之间的消息转发前提是两套 broker 版本兼容、网络可达、双方运维都愿意开通道。现实中跨组织的那套 broker 往往根本不给你开双向通道的权限这条路直接堵死。而且桥接之后消息的持久化语义、死信策略、监控归属都会变得模糊出了问题定位要跨两个团队排查成本极高。至于统一到一个公共 broker 转发那等于在中间加了一跳多一跳就多一次失败可能、多一份维护成本而且把两侧的强耦合转移到了一个新的单点上。迁移动机本来就是解耦结果造出一个更脆弱的中心节点方向上就错了。真正务实的做法是在应用层做隔离两套独立的 ConnectionFactory、两套独立的 JmsTemplate、两套独立的监听容器工厂用命名空间和路由门面把边界画清楚。这种做法的好处是每一侧都能独立配置参数、独立降级、独立监控出问题时影响面是可控的。1.3 两套连接并存的三种技术路线实际落地时有三条路线可选我按推荐程度排序。第一条是全手工装配禁用自动配置。所有 ConnectionFactory、JmsTemplate、监听容器工厂都自己声明明确每个 bean 的 name 和用途。控制力最强也最适合双 broker 场景。代价是要多写几十行配置但这点代码量换来的是完全可预测的装配行为。第二条是保留自动配置另加一套手工 bean。用spring.activemq.*配置主连接手工声明第二套。看起来省事但自动配置会创建默认的 JmsTemplate 和jmsListenerContainerFactory它们需要注入一个 ConnectionFactory一旦容器里出现两个 ConnectionFactory 类型的 bean注入就变成歧义要么靠Primary压制要么就报NoUniqueBeanDefinitionException。这条路能走通但要非常清楚自动配置的边界在哪里。第三条是用 JMS 规范之外的抽象层比如自己封装一个MessageBus接口下面挂两个实现。这层封装在小项目里是过度设计但在长期维护的系统里很有价值因为它把消息发到哪里从配置问题变成了代码里的显式选择读代码的人不需要翻 XML 就知道某个业务走的是哪条链路。我最终选的是第一条路线加第三层的轻封装底层纯手工装配上层加一个按业务标签路由的发送门面。原因很直接——配置层的正确性可以靠 review 保证而发错 broker这种问题靠 review 是防不住的必须在代码层面让选择变显式。2. Spring 的 JMS 装配模型为什么默认只让你连一个2.1 自动配置那条隐形的单例链Spring Boot 的 JMS 自动配置做的事情比大多数人想象的要多。引入spring-boot-starter-activemq之后它会在满足条件的情况下创建三个关键 bean一个ConnectionFactory用spring.activemq.broker-url的值构建没配就用默认的本地地址、一个JmsTemplate绑定那个唯一的 ConnectionFactory、以及一个名为jmsListenerContainerFactory的监听容器工厂。这三个 bean 的创建条件里都有ConditionalOnMissingBean一类的判断但判断的粒度不同。ConnectionFactory的判断是容器里没有 ConnectionFactory 类型的 beanJmsTemplate的判断是没有 JmsTemplate 类型的 bean监听容器工厂的判断则是按 name 匹配jmsListenerContainerFactory。这就带来一个很隐蔽的后果如果你手工声明了两个 ConnectionFactory自动配置的 ConnectionFactory 确实不会创建了但自动配置的JmsTemplate和监听容器工厂仍然会创建而它们需要注入一个 ConnectionFactory此时容器里有两个候选注入直接失败。我在第一次搭这个项目时就是被这个卡住的配置写完了启动报NoUniqueBeanDefinitionException: expected single matching bean but found 2。当时第一反应是我明明没让它自动配置实际上是自动配置的那部分在背后还活着。稳妥的处理方式是显式排掉ActiveMQAutoConfiguration和JmsAutoConfiguration尤其在双 broker 场景下把所有装配权收回到自己手里比事后靠Primary兜底要清晰得多。2.2 ConnectionFactory、JmsTemplate、容器工厂三者的绑定关系理解这三个东西的关系双 broker 的配置就成功了一半。ConnectionFactory是物理连接的生产者它持有 broker 地址、账号、连接池参数JmsTemplate是发送端的门面构造时必须绑定一个 ConnectionFactory监听容器工厂是消费端的配置模板创建MessageListenerContainer时也必须绑定一个 ConnectionFactory。关键在于这条绑定链是单向的而且只在创建那一刻发生。JmsTemplate一旦绑定就固定了不会在运行时切换。监听容器也是一样。所以同时连两个 broker在 Spring 里的本质不是让一个 bean 同时连两个地址而是让两条独立的 bean 链各自连各自的地址。这也解释了为什么JmsListener有一个containerFactory属性。它的默认值是字符串jmsListenerContainerFactory也就是说如果你不写所有监听器都会去找那个名字的 bean自然就全跑到主 broker 上去了。要让某些监听器走第二套 broker唯一的办法就是在注解上显式指定另一个工厂 bean 的名字。2.3 我的隔离策略按 name 分层、按用途分模板配置多了以后最容易出的问题是名字乱了。两个connectionFactory、两个jmsTemplate一眼看过去分不清谁是谁。我的做法是给每套配置固定一套后缀主链路统一用Primary后缀第二套用Secondary后缀bean 名字里都带上这个后缀。除了后缀还会按用途拆模板。同一个 broker 上普通业务发送和事务型发送、同步请求应答对 TTL、持久化、超时的要求差别很大。如果所有业务共用一个 JmsTemplate必然要在每次发送时用send()的 lambda 版本来临时设置参数代码会变得很啰嗦。我的习惯是每个 broker 配一个基础模板再按业务类型配一到两个专用模板都指向同一个 ConnectionFactory。这样发送端写起来就是一行orderTemplate.convertAndSend(queue, payload)参数已经沉淀在配置里了。这里有个细节值得单独说多个 JmsTemplate 共用一个 ConnectionFactory 是安全的因为 JmsTemplate 本身无状态真正的并发控制由 ConnectionFactory 内部的连接和 session 池承担。但反过来说如果你在 ConnectionFactory 外面又套了一层缓存那这个缓存是共享的session 缓存大小要按所有模板的总并发来估不能只按单个模板算。3. 从零落地XML 与 Java Config 两套完整配置3.1 依赖与版本基线先把版本对齐这步做错后面全是玄学问题。Spring 5.3.x 系列配 ActiveMQ 5.16/5.17 是最稳的组合ActiveMQ 5.18 起基线要求 JDK 11如果你的项目还在 JDK 8 上不要碰 5.18。Spring Boot 2.x 的依赖管理已经帮你把 activemq-client 的版本锁好了一般不需要手工指定版本号除非你有意升级。依赖方面除了 starter如果打算用 ActiveMQ 自带的连接池而不是 Spring 的 CachingConnectionFactory还需要额外引入连接池模块dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-activemq/artifactId /dependency dependency groupIdorg.apache.activemq/groupId artifactIdactivemq-pool/artifactId /dependency这两个连接池方案不要混用。Spring 的CachingConnectionFactory缓存的是 session 和 producer/consumerActiveMQ 的PooledConnectionFactory池化的是物理连接和 session。两个套在一起会出现连接数翻倍、session 泄漏、关闭时挂住不退出这类问题。选一个就好我更倾向CachingConnectionFactory因为它和 Spring 的 JMS 抽象贴合更紧异常转换和 session 复用行为更可预测。3.2 第一套连接手工管理 ConnectionFactory先写 XML 版本很多老项目还在用。第一套连接对应的 bean 全部带Primary后缀!-- 物理连接工厂 -- bean idamqConnectionFactoryPrimary classorg.apache.activemq.ActiveMQConnectionFactory property namebrokerURL valuefailover:(tcp://10.0.0.11:61616,tcp://10.0.0.12:61616)?randomizefalseamp;maxReconnectAttempts-1amp;initialReconnectDelay200amp;maxReconnectDelay30000/ property nameuserName value${mq.primary.user}/ property namepassword value${mq.primary.password}/ property nameuseAsyncSend valuetrue/ property namesendTimeout value5000/ property namecloseTimeout value3000/ property namealwaysSessionAsync valuefalse/ /bean !-- Spring 缓存包装 -- bean idconnectionFactoryPrimary classorg.springframework.jms.connection.CachingConnectionFactory property nametargetConnectionFactory refamqConnectionFactoryPrimary/ property namesessionCacheSize value20/ /bean !-- 发送模板 -- bean idjmsTemplatePrimary classorg.springframework.jms.core.JmsTemplate property nameconnectionFactory refconnectionFactoryPrimary/ property nameexplicitQosEnabled valuetrue/ property namedeliveryPersistent valuetrue/ property nametimeToLive value300000/ /bean几个参数值得逐个解释。failover前缀是为了在单 broker 地址变化或短暂重启时能自动重连randomizefalse保证优先连第一个地址避免集群环境下随机连到从节点导致消息消费延迟。maxReconnectAttempts-1表示无限重试对于长期运行的中间层是合理的——断了就一直试总比直接抛异常让线程死掉好。useAsyncSendtrue让发送不阻塞等待 broker 确认吞吐能提升明显代价是极端情况下丢消息的窗口变大如果业务对可靠性要求高这条要改成 false 或者配合sendTimeout一起用。alwaysSessionAsyncfalse这个参数很多人不知道它的作用是当只有一个 session 时让发送走同步路径而不是丢到单独的异步线程池里能省一次线程切换。对高频小消息场景有实际收益。sessionCacheSize是 Spring 缓存的关键参数默认值是 1这意味着默认情况下所有发送线程抢同一个 session。并发一高就成了瓶颈表现出来是发送 RT 突然拉长。我一般按并发发送线程数 × 1.5 监听容器数来估20 是个适合中等负载的起点。3.3 第二套连接命名为王第二套配置的结构完全一样只是后缀换成Secondary地址和账号换成另一个 broker 的bean idamqConnectionFactorySecondary classorg.apache.activemq.ActiveMQConnectionFactory property namebrokerURL valuetcp://10.1.0.21:61616/ property nameuserName value${mq.secondary.user}/ property namepassword value${mq.secondary.password}/ property nameuseAsyncSend valuetrue/ property namesendTimeout value5000/ /bean bean idconnectionFactorySecondary classorg.springframework.jms.connection.CachingConnectionFactory property nametargetConnectionFactory refamqConnectionFactorySecondary/ property namesessionCacheSize value10/ /bean bean idjmsTemplateSecondary classorg.springframework.jms.core.JmsTemplate property nameconnectionFactory refconnectionFactorySecondary/ property nameexplicitQosEnabled valuetrue/ property namedeliveryPersistent valuetrue/ property nametimeToLive value600000/ /bean注意这里我没有给第二套加failover。原因不是懒而是第二套 broker 由外部团队维护他们不提供多节点地址加 failover 也没有备用地址可切反而会多一层无意义的包装。如果排除掉这种外部约束只要 broker 有主备两套都该用 failover。两套配置的sessionCacheSize我给了不同的值因为两个链路的流量本来就不对等。主链路承载存量全量业务第二套只承载新渠道的增量。参数不搞一刀切是双 broker 配置里最容易被忽略但收益最直接的一点。3.4 拆分 JmsTemplate 与统一发送门面配置写完了接下来是让业务代码能明确地发到指定 broker。直接Autowired两个 JmsTemplate 按名字注入是可以的但读代码的人容易看漏Qualifier一不小心就注入了主模板。我的做法是加一层薄门面Component public class MqPublisher { private final MapBrokerTag, JmsTemplate templates new EnumMap(BrokerTag.class); public MqPublisher(Qualifier(jmsTemplatePrimary) JmsTemplate primary, Qualifier(jmsTemplateSecondary) JmsTemplate secondary) { templates.put(BrokerTag.PRIMARY, primary); templates.put(BrokerTag.SECONDARY, secondary); } public void send(BrokerTag tag, String queue, Object payload) { JmsTemplate template templates.get(tag); if (template null) { throw new IllegalArgumentException(unknown broker tag: tag); } template.convertAndSend(queue, payload); } }BrokerTag是个枚举只有PRIMARY和SECONDARY两个值。业务代码调用时第一个参数就是链路标识任何人看代码都知道这条消息走的是哪一侧。比起在两个 JmsTemplate 字段之间来回选这种写法把路由决策提到了接口签名里出错概率低得多。门面里我还会加一个兜底逻辑如果目标链路当前处于降级状态比如运维在配置中心把这个 broker 标记为不可用发送直接抛业务异常或者落到本地待发表而不是傻等 5 秒超时。这个逻辑不复杂但能让故障时的用户体验从页面转圈变成明确报错。3.5 监听容器工厂与 JmsListener 的路由消费端才是真正容易翻车的地方。两套监听容器工厂必须都建起来名字和 broker 一一对应bean idjmsListenerContainerFactoryPrimary classorg.springframework.jms.config.DefaultJmsListenerContainerFactory property nameconnectionFactory refconnectionFactoryPrimary/ property nameconcurrency value4-12/ property namesessionTransacted valuefalse/ property nameautoStartup valuetrue/ property nameshutdownTimeout value15000/ /bean bean idjmsListenerContainerFactorySecondary classorg.springframework.jms.config.DefaultJmsListenerContainerFactory property nameconnectionFactory refconnectionFactorySecondary/ property nameconcurrency value2-6/ property namesessionTransacted valuefalse/ property nameautoStartup valuetrue/ property nameshutdownTimeout value15000/ /bean消费者的写法必须显式指定工厂否则默认全走主 brokerJmsListener(destination PRIMARY.ORDER.RECEIPT, containerFactory jmsListenerContainerFactoryPrimary, concurrency 4-12) public void onPrimaryReceipt(String payload) { // 主链路回执处理 } JmsListener(destination SECONDARY.WAYBILL.TRACK, containerFactory jmsListenerContainerFactorySecondary, concurrency 2-6) public void onSecondaryTrack(String payload) { // 外部链路轨迹处理 }注意我把队列名也加了链路前缀。这不是洁癖是防错。两套 broker 上如果都叫ORDER.RECEIPT配置改错一行、注解少写一个containerFactory消息就悄悄跑到另一侧去了而且表面上一切正常可能几天后对账才发现。加了前缀之后至少日志里一眼能看出走的是哪条链路。defaultDestination不建议在两套模板上都设。一旦模板带了默认目的地某个调用忘了传队列名消息就会静默发到默认地址这在双 broker 场景下是灾难。宁可让它在启动时就报错也不要让它悄悄发错地方。3.6 参数怎么算连接池、并发、prefetch参数不能拍脑袋得有算法。先算并发假设某条链路目标吞吐 200 条/秒单条消息平均处理耗时 50 毫秒那么单线程的理论处理能力是 20 条/秒需要 10 个线程才能扛住。考虑到峰值和抖动配8-16的并发范围比较合理。这个计算方式比看别人配多少就抄多少靠谱得多因为别人的消息处理耗时和你的完全不一样。再算 prefetch。ActiveMQ 的消费者默认会预取 1000 条消息到本地缓存这个默认值在单消费者场景下能极大提升吞吐但在多消费者、消息处理慢的场景下会造成严重的分配不均——一个消费者手里攥着 1000 条还没处理完另一个消费者闲着没事干。消息处理耗时超过 100 毫秒、消费者数量超过 3 个的场景我一般把 queue 的 prefetch 压到 10 到 50 之间。设置方式有两种全局的property nameprefetchPolicy bean classorg.apache.activemq.ActiveMQPrefetchPolicy property namequeuePrefetch value20/ property nametopicPrefetch value100/ /bean /property或者按队列粒度在目的地名里带参数。全局设置简单按队列设置灵活看你的消息类型差异有多大。session 缓存的算法在前面提过这里补一个容易漏的项监听容器本身也占用 session。每个容器实例至少占 1 个 cached session如果并发上限是 12那这部分就要留出 12 个的余量。sessionCacheSize配小了不会报错只会让发送线程排队等 session表现是偶发的 RT 尖刺非常难查。4. 排坑实录从只连上一个到消息串门4.1 几个高频故障现场启动即报 bean 冲突。这是最常见的第一个坑前面提过自动配置还活着导致的。处理方式是排除自动配置类或者在两个 ConnectionFactory 里给其中一个加Primary。我推荐排除因为Primary只是解决了注入歧义自动配置创建的jmsListenerContainerFactory仍然挂在主连接上后面会带来更难查的行为不一致。只连上了一个 broker。表现是日志里只有一条连接建立的记录另一条链路的消息发出去无响应但不报错。原因通常是两个 bean 的名字不同但类型相同某个地方用的是按类型注入随机选中了一个。排查方式很简单启动后打一条日志把两个 ConnectionFactory 的 broker 地址都打出来或者直接看 broker 端的连接列表连了几个一目了然。消息发到了对面。这类问题最阴险因为系统不报错。根因往往是某处代码用了Autowired JmsTemplate按类型注入或者监听器漏了containerFactory。我的防错手段是所有 JmsTemplate 字段的注入一律带Qualifier所有监听器一律显式写containerFactory并且在 CI 里加一个静态检查规则禁止出现不带限定符的 JmsTemplate 注入。启动被慢链路拖住。第二套 broker 在外部网络某天网络抖动应用启动卡在建立连接上主链路的服务也跟着起不来。原因是监听容器默认autoStartuptrue容器启动时会尝试建立连接连接失败会按recoveryInterval反复重试。解决办法是给外部链路配recoveryInterval比如 5 秒并把autoStartup设成 false在应用完全启动后再手动 start。这样主链路先跑起来外部链路什么时候通什么时候接上。4.2 问题速查表现象可能原因排查动作启动报NoUniqueBeanDefinitionException自动配置仍在生效容器里有两个 ConnectionFactory检查是否排除了自动配置类或补Primary只有一条连接建立日志某个 bean 被另一个同类型 bean 覆盖打印两个 ConnectionFactory 的 broker 地址对比消息发出无异常但对面收不到监听器漏写containerFactory消息在另一侧堆积查看两个 broker 控制台的队列积压情况发送偶发长 RTsessionCacheSize过小发送线程抢 session调大缓存观察 RT 分布是否收敛消息在多个消费者间分配不均prefetch 过大把 queuePrefetch 压到 10~50应用关闭时卡住不退出监听容器等待消息处理完成shutdownTimeout过长调整超时值或改造成先停容器再停应用一个 broker 挂了导致启动失败监听容器autoStartuptrue且无重试间隔设autoStartupfalse配recoveryInterval4.3 我踩过的几个细节坑第一个坑是连接池方案混用。当时为了让第二套连接性能好一点给它单独套了 ActiveMQ 的PooledConnectionFactory外面又包了一层CachingConnectionFactory。结果运行一天后连接数缓慢上涨重启才恢复。原因是两层池对归还的语义理解不一致某些异常路径下 session 没被正确释放。改成单层缓存后问题消失。这个教训是一个 ConnectionFactory 只套一层缓存不要叠。第二个坑是消息转换器的配置不一致。主链路用的是SimpleMessageConverter第二套链路用的是 JSON 转换器两边对同一个业务对象序列化出来的字节完全不同。外部系统偶尔能收到消息但解析失败日志里全是反序列化异常。解决办法是把转换器也按链路独立配置并且明确规定跨 broker 的消息体一律用 JSON 文本不用对象序列化。这样即使配置写错消息体本身也是可读的排查时用眼睛就能看出来。第三个坑是事务边界。有一段业务逻辑需要先落库、再发消息我一开始想着两个 broker 都配上sessionTransactedtrue就能保证一致性。实际测试发现sessionTransacted只在单个 ConnectionFactory 内保证本地事务跨 broker 根本没有原子性可言一个成功一个失败是常态。最终的方案是本地消息表加定时补偿这部分的必要性在下一节展开说。第四个坑是队列名大小写。ActiveMQ 的队列名是大小写敏感的但有些场景下 broker 端的命名习惯是全大写。我在配置里写的是小写broker 端建的是大写结果是产生了两个不同的队列消息发出去后在控制台看不到积压因为看到的是另一个队列。这类问题没有技术含量纯粹是命名规范不统一但它能让你查一整天。现在的做法是队列名统一由配置中心的常量管理代码里不出现字符串字面量。5. 上生产前还得补的三件事5.1 无法跨 broker 的原子性这是双 broker 架构最重要的认知必须写在方案文档的第一页两套 ConnectionFactory 之间没有分布式事务。sessionTransacted管的是单个 broker 内的发送与会话一个业务操作如果同时要往两侧发消息任意一侧失败都不会回滚另一侧。现实中的处理方式有三种。第一种是本地消息表把要发出去的消息先落库由一个独立的投递线程去发失败了重试这是最常用也最稳的方案。第二种是业务对账加补偿允许短时间的不一致靠定时任务扫描修正。第三种是业务上保证幂等接受至少一次投递下游自己去重。我选的是本地消息表加幂等消费。原因很朴素这个系统的下游本来就要求幂等既然幂等已经做了就没必要再追求跨 broker 的强一致那样只会把架构复杂度抬上一个台阶而收益有限。判断取舍的时候想清楚不一致持续几秒会不会造成实际损失比纠结用哪种分布式事务框架要实际得多。5.2 优雅停机与启动顺序双 broker 场景的停机比单 broker 复杂因为两条链路的停止节奏可能不一样。默认情况下容器停止时会等待正在处理的消息完成但如果某条消息处理特别慢整个应用就会卡在关闭过程中最后被强制 kill导致消息重复消费。我的配置是给两个容器工厂都设一个合理的shutdownTimeout取业务最长消息处理时间的两倍左右比如 15 秒。同时把应用的关闭流程改成先停监听容器container.stop()再等一段时间让在途消息处理完最后关闭连接。这套顺序写在SmartLifecycle的实现里比依赖框架的默认顺序可控得多。启动顺序上如果某条链路是可以晚点连上的就把它排在后面启动用phase值控制。主链路 phase 小一点先启动外部链路 phase 大一点后启动这样即使外部链路初始化慢也不影响主链路开始对外服务。5.3 监控与容量两套 broker 意味着两套监控指标别只盯着一侧看。我关注的核心指标有四个每条链路的连接数、发送队列的积压深度、消费速率、以及消息从入队到消费完成的延迟。前两个在 broker 端的控制台能看后两个需要在应用里埋点。积压深度是最直观的健康度指标。积压持续上涨说明消费能力不足要么加并发要么查是不是消费端卡在了某个下游调用上。延迟指标能反映更深的问题比如积压不涨但延迟变长往往是单条消息处理慢这时候加并发没用得优化处理逻辑。容量规划上有个经验值可以参考单套 broker 连接数控制在 50 以内单队列消费者数控制在 20 以内超过这个量级不是不能跑而是问题定位会变得非常困难。真到了这个量级该考虑的是拆分队列而不是继续堆消费者。最后分享一个我在这个项目里固定下来的小习惯每套 broker 配置的类注释里我都会写清楚这条链路的归属、负责人、SLA 和变更流程。听起来像流程废话但它救过我一次某次外部链路切换地址我按注释找到了对接人确认了切换窗口避免了在大促前夜改配置。双 broker 的复杂不是因为技术难而是因为牵扯的边界多人一多信息就散配置注释这种最土的办法反而最有效。真要说这套东西的核心其实就一句话把连哪一套从隐式的默认行为变成显式的代码和命名决策剩下的都是参数调优。
