ActiveMQ-Network of brokers集群模式
概述
在ActiveMQ运行过程中,如果发生某个queue只有生产者没有消费者的情况时,消息就会产生积压。Network of brokers模式通过将积压的消息转发给处于同一network的其它broker的方式很好地解决了这个问题,但这个模式也有问题。
基本配置
1 2 3 4 5 6 7 8 9 10 | vim conf /activemq .xml <broker> .... <networkConnectors> <networkConnector uri= "static:(tcp://localhost:20001,tcp://localhost:20010,tcp://172.16.1.14:20001,tcp://172.16.1.14:20002,tcp://172.16.1.14:20003,tcp://172.16.1.14:20004)" /> < /networkConnectors > <persistenceAdapter> <kahaDB directory= "${activemq.data}/kahadb" /> .... < /broker > |
注:
1、<networkConnector uri="static:(....)">,括号中的实例要包括自己。可以理解为这些实例组成了一个网络,相互可以进行消息接收,但是只有做了这项配置的broker才能够将消息转发给网络中的其它broker。
2、activemq create /path/<broker_name>,注意network中的broker_name不能相同,相同则只有一个被本地broker当作消费者。
控制台展示
注:
1、标1的是真实消费者,一般由应用程序产生,标2的是网络中的其它broker,本地broker将消息转发给它们。
2、可以看出,本地broker将network中的其它broker和APPConsumer都当做是自己的消费者,平均分发消息。
3、本人猜想,这种模式实际上会增加broker的I/O消耗,因为同一条消息被接收和发送了两次。
4、broker通常用于异步通信,消息的即时性没那么强,实际生产中即使消费者宕了,我们只需通知让租户重启消费者即可,不必急于将消息分发出去。
5、这种模式并不会起到负载均衡的作用,因为发送给其它broker也消耗网络IO,反而加重了负载。通常直接在客户端侧做负载均衡更加方便。
6、network of brokers模式默认是单向的,即开通该功能的broker不会再接收消息,这意味着只有部分broker能够开启这个功能,而且会加重剩余broker的负载。
7、当集群规模较大时,这种方式还会使得生产者和消费者关系紊乱,不利于追踪消息的走向。对于消息中间件的部署,个人以为,简单即正义。
8、总之,对于异步通信而言,我们通常允许消息积压,但不允许消息丢失,而网络又是不可靠的,所以一般不用这种模式。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 智能桌面机器人:用.NET IoT库控制舵机并多方法播放表情
· Linux glibc自带哈希表的用例及性能测试
· 深入理解 Mybatis 分库分表执行原理
· 如何打造一个高并发系统?
· .NET Core GC压缩(compact_phase)底层原理浅谈
· 手把手教你在本地部署DeepSeek R1,搭建web-ui ,建议收藏!
· 新年开篇:在本地部署DeepSeek大模型实现联网增强的AI应用
· Janus Pro:DeepSeek 开源革新,多模态 AI 的未来
· 互联网不景气了那就玩玩嵌入式吧,用纯.NET开发并制作一个智能桌面机器人(三):用.NET IoT库
· 【非技术】说说2024年我都干了些啥