Activemq 宕机解决方案

关于消息服务的集群,大概分为Consumer集群(消费者集群)和Broker集群(消息服务器集群)两种。
ActiveMQ提供了一种叫做失效转移(也叫故障转移,FailOver)的策略。失效转移提供了在传输层上重新连接到其他任何传输器的功能。使用它很简单,只需要在uri中配置就行了
Failover:(uri1.....n)

如果某个ActiveMQ客户端发现uri1地址失效了,它会立即转向uri地址列表中其他可以连接的消息服务器进行重连,以保证继续正常工作,请注意,并不是uri1失效了就会选则uri2重连,这种选择其他地址的方式默认是随机的,以保证负载均衡

如果activemq集群全部宕机
ActiveMQ提供了消息传输监听(transportListener),可以对ActiveMQConnectionFactory添加一个Activemq的消息传输监听,该监听实现 Activemq的TransportListener接口。

当发现服务器无法连接时,就采取相应措施,如把消息存储在本地,当服务器恢复时再进行发送。

时间: 2024-10-24 02:55:02

Activemq 宕机解决方案的相关文章

tomcat重启警告:Abandoned connection cleanup thread 服务器宕机解决方案

每次出现这个报错都会导致tomcat应用服务器停机 报错信息: 1 The web application [HelloWeb] appears to have started a thread named [Abandoned connection cleanup thread] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: 2 java.lang.O

VmWare平台Windows Server 2012 无响应宕机

我们生产服务器都部署在VMware ESXi 5.5平台上,最近大半年的时间,偶尔就会出现操作系统为Windows Servre 2012的服务器出现没有任何响应(unresponsive)的情况,出现问题的时候,服务器有下面一些现象: 1: 应用程序无法访问SQL Server数据库,使用Microsoft SQL Server Management Sutdio去测试连接数据库,也会返回连接错误. 2: 网络有时候能Ping通,有时候是Ping不通的情况. 3: 远程连接无法访问服务器,从V

从谷歌宕机事件认识互联网工作原理

原文转自:http://kb.cnblogs.com/page/166210/ 英文原文:Why Google Went Offline Today and a Bit about How the Internet Works 译者注:本文中提到 CloudFlare 是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由 Project Honey Pot 项目的三位前开发人员成立于 2009 年.2011 年 10 月被华尔街日报评为最具创新精神的网络科技公司. 今天,谷歌的服务经历了

625某电商网站数据库宕机故障解决实录(上)

博客编辑器越来越用不好了,伙伴们将就看,需要排版更好的文档请加Q群246054962. 625某电商网站数据库特大故障解决实录(上) 这是一次,惊心动魄的企业级电商网站数据库在线故障解决实录,故障解决的过程遇到了很多问题,思想的碰撞,解决方案的决策,及实际操作的问题困扰,老男孩尽量原汁原味的描述恢复的全部过程及思想思维过程!老男孩教育版权所有,本内容禁止商业用途. 目录: 625某电商网站数据库特大故障解决实录... 1 1接到电商客户报警... 1 1.1与客户初步沟通... 1 1.2深入沟

日活上百万时,腾讯产品如何提前规避服务器宕机风险?

众所周知,优异的应用性能是良好用户体验的坚实基础,而服务器响应缓慢.卡顿.崩溃的产品,即便设计再精美也无法留住用户的心. 2017年2月28日,百度就和用户们开了一个不大不小的玩笑,从当天的20点54分到21点24分左右,百度搜索整整宕机了30分钟,众多网友戏言那30分钟成为了百度最有存在感的30分钟,但是从后来百度的公关文章中,可以看到其提到了"错过了大家上亿次的搜索请求",从这个体量来看,这无论如何都是一次很大的影响了. 无独有偶,今日头条也在今年的1月出现了宕机现象,系统超过30

项目笔记-数据库进程宕机

简述情景: 1. 最开始出现邮件报警,db进程内存超过5G. 2. 1小时后,db宕机 3. 检查日志,发现mysql语句执行很慢.从18:30开始出现日志警告. 写了个程序测数据库执行速度.连本机数据库执行1000条语句,时间500ms左右.连其他机器数据库执行1000条语句,时间8s左右.服务器的数据库执行线程500ms执行一次,也就是说一旦一次的执行时间超过500ms,而且sql语句持续增加,服务器的执行就开始阻塞,导致内存开始累计.最终服务器由于内存过高,发生宕机. 临时解决方案: 由跨

云平台数据库主机意外宕机问题

问题引入: 很多公司在使用自己的私有云环境时,会选择划分主机集合,像这种 很好,做得很好,但是新建主机集合的精髓在于:区分对待,每个zone内包含物理节点拥有不同的物理配置 比方说: 1.zone1用来新建cpu密集型云主机 2.zone2用来新建内存要求较高的云主机 3.zone3用来新建硬盘io要求较高云主机 如果不区分对待,那划分什么主机集合. 下列就是发生在我们公司的一个案例: 一:问题:生产环境DB主机主节点在19号中午突然宕机,导致公司某业务中断. 二:问题解决: 生产以第一时间恢复

由于master宕机等导致resource调用出现异常,直接将该resource返回到pool以便其他代码使用会导致得到不可预期的结果,导致返回数据混乱。

实现一:public String get(final String key) {              Jedis resource = null;              try {                           resource = pool.getResource();                            return resource.get(key);           } finally {                      

Linux内存使用高,触发系统宕机

摘自:http://www.cnblogs.com/itfriend/archive/2011/12/14/2287160.html 网上的解决方案:用ps查看各进程的内存,大约就占用了4G, 绝大部分内存都是被Page Cache所占用.Linux内核的策略是最大程度的利用内存cache 文件系统的数据,提高IO速度,虽然在机制上是有进程需要更大的内存时,会自动释放Page Cache,但不排除释放不及时或者释放的内存由于存在碎片不满足进程的内存需求. 所以我们需要一个方法,能够限定PageC