activemq

1、下载安装ActiveMQ 　　ActiveMQ官网下载地址： http://activemq.apache.org/download.html 　　ActiveMQ 提供了Windows 和Linux、Unix 等几个版本，楼主这里选择了Linux 版本下进行开发。 　　下载完安装包，解压之后的目录： 　 　　从它的目录来说，还是很简单的： bin存放的是脚本文件 conf存放的是基本配置文件 data存放的是日志文件 docs存放的是说明文档 examples存放的是简单的实例 lib存放的是activemq所需jar包 webapps用于存放项目的目录 2、启动ActiveMQ　 　　进入到ActiveMQ 安装目录的Bin 目录，linux 下输入 ./activemq start 启动activeMQ 服务。 　　 输入命令之后，会提示我们创建了一个进程IP 号，这时候说明服务已经成功启动了。 　　 　　ActiveMQ默认启动时，启动了内置的jetty服务器，提供一个用于监控ActiveMQ的admin应用。 　　admin： http://127.0.0.1:8161/admin/ 　　我们在浏览器打开链接之后输入账号密码（这里和tomcat 服务器类似） 　　默认账号：admin 　　密码：admin 　　 　　　到这里为止，ActiveMQ 服务端就启动完毕了。

使用消息队列是提高系统性能的第二黄金法则。 1、消息队列使用场景 一般稍微大点的系统都会用到消息队列，之前项目中用过的主要有ActiveMQ和kafka。使用消息队列的最终目的是通讯，本质是解耦生产者消费者依赖，一般用在异步处理、解耦、错峰、流量控制等场景。 Java消息队列 2、消息队列模型push vs pull push模型最大问题是慢消费，即消费者速度如果比生产者速度慢很多，会导致消息在broker的堆积，如果这些消息是有用无法丢弃的就会一直在broker端保存，并且broker会不断的给消费者推送消息，消费者reject或error后可能会来回推送。而pull模式，消费者可以按需消费，不用担心自己处理不了的信息来骚扰自己，broker堆积消息也会相对简单，无需记录每一个要发送消息的状态，只需要维护所有消息的队列和偏移量就可以了。由于主动权在消费方，消费方无法准确地决定何时去拉取最新的消息。如果一次pull取到消息了还可以继续去pull，如果没有pull取到则需要等待一段时间重新pull。 pull模式最大的问题是消息延迟和忙等。业界较成熟的做法是从短时间开始（不会对broker有太大负担），然后指数级增长等待。比如开始等5ms，然后10ms，然后20ms，然后40ms……直到有消息到来，然后再回到5ms。 3、如何保证消息不丢失（可靠投递，最终一致性），不重复或有序性？

最近频繁地在跟实习生候选人打交道，每次新接触一个候选人，都要花上一定的时间去介绍我们团队，候选人问的最多的一个问题就是「中间件部门一般是干嘛的？」，恰好我之前也接触过一些想从事中间件开发的小伙伴，问过我「现在转行做中间件开发还来得及吗？」诸如此类的问题，索性就写一篇文章，聊聊我个人这些年做中间件开发的感受吧。 什么是中间件开发？ 我大四实习时，在一个 20 多人的软件开发团队第一次接触了中间件，当时项目的架构师引入了微博开源的 RPC 框架 Motan，借助于这个框架，我们迅速构建起了一个基于微服务架构的内部电商系统。接着在项目中，由于业务需求，我们又引入了 ActiveMQ...在这个阶段，我已经在使用中间件了，但似乎没有接触到中间件开发，更多的是使用层面上的接触。 我毕业后的第一份工作，公司有几百号研发，当时的 leader 看我对中间件比较感兴趣，有意把我分配在了基础架构团队，我第一次真正意义上成为了一名”中间件研发“，平时主要的工作，是基于开源的 Kong 和 Dubbo，进行一些内部的改造，以提供给业务团队更好地使用。这个阶段，做的事还是比较杂的，业务团队对某些中间件有定制化的需求，都需要去了解这个中间件，熟悉源码。这段时间，也是我成长最快的一个时期，我是在这个期间学会了 Docker、Neo4j、Kong 等以前从来没接触过的技术，并且更加深入地了解 Dubbo 这类

一、说明 　　实际的应用中，一般为了应用的高可用性，都会搭建集群环境去处理。部署多台应用，这样，即使一台有问题，其他热备应用可以立马顶上，继续提供服务。 　　ActiveMQ的集群部署，基于zookeeper的应用程序协调服务和levelDB的持久化方案。 　　本文中，基于一个系统环境，搭建伪集群模式，通过不同端口的配置，达到集群安装的效果。 　　基本环境：jdk-7u80-linux-x64.tar.gz、Centos 6.9、zookeeper-3.4.12.tar.gz、apache-activemq-5.9.1-bin.tar.gz、Xshell。 　　应用部署：zookeeper启动3个应用实例，ActiveMQ部署3套应用实例，构成最小单元的集群部署 　　其中zookeeper的集群搭建，参见之前文章： https://www.cnblogs.com/eric-fang/p/9283904.html 二、ActiveMQ的集群配置 　　ActiveMQ的主从模型，是一种高可用的解决方案，在zookeeper中注册若干的ActiveMQ Broker，其中只有一台作为主机master对外提供服务，其他作为备份slave保持待机。当master出现问题导致宕机不能正常提供服务的时候，zookeeper通过内部选举，在众多slave中推举出一台作为master继续对外提供服务

前不久，朋友的公司，出现了比较大的故障。故障引起的原因也比较好解释，因为使用了ActiveMQ的高可用级别(M-S架构，双写完成ACK），结果在高峰期间，造成了生产端消息拥堵，诸多请求无法落地，数据错乱。 背景 据他说，他们的应用，级别比电信应用还要高（牛皮一定要吹），所以消息系统要求一条消息都不能丢。他做到了，但是服务不能用了。 这个Case有何而来呢？据说是来自一次高管会议上，某位领导对其中的一个小问题情绪激动：他测试环境测试的某条数据，直接不见了，生产环境并未复现。矛头最终指向了消息系统，直接上升到断电后怎么办云云。 领导发威，事情要特事特办。架构组扯蛋似的熬夜讨论了改进的方案，从Kafka到RocketMQ，从落盘DB到升级到StoreHA方案，不亦乐乎。最终的讨论结果，就是采用极高可用的方式。领导的条件满足了，消息系统也是高可用的，但整个业务不是。最终的MQ吞吐量，连个DB都不如。 典型的枪杆子需求引起的优化故障。一定不少见。 思考 高可用是个伪命题，虽然有CAP等耳熟能详的理论支持，还是有很多人陷入了这个误区，包括技术决策人。架构作为全局把控人，能出现这样的错误，纯属低级。下面，是我自己对高可用的一点思考。 高可用不是组件高可用，是业务高可用 拿消息队列来说，并不是说保证消息队列的存活和消息的可靠，就完成了工作。还需要考虑生产端和消费端的拓扑和高可用。比如