Activemq构建高并发、高可用的大规模消息系统

 在实时消息系统中，MQ消息中间件普遍应用于各种消息系统中，在异步消息处理架构中，MQ几乎是必备的中间件。 同时，MQ的处理性能也将直接影响整个系统的性能。若是MQ出现故障，那么整个系统将瘫痪，其后果将是灾难性的。 因此在通常状况下MQ会中HA，或是failover，可是若是要求消息处理能力在10万/秒以上时，简单的HA或failover将不能知足要求。

    1、Activemq broker部署方式

     1） 单MQ broker 时

 整个系统中只有一个Activemq Broker，在生产系统中几乎不使用。由于单个MQ存在单点故障。

    2） Master - slave　模式

采用Master-slave模式，同时在连接串中增长failover功能， 可以实现HA, 避免单点故障。可是，Master-slave方式通常须要"共享文件系统"，同时必须保证出现问题时，文件锁能正常切换。另外，slave处于stand by状态，不对外提供服务。 在Master高负荷的状况下，Slave不能提供能帮助。若是Master在高负荷状况下挂掉，那么Slave在一样的状况下也可能挂掉，只是时间问题。（ Replicate Leveldb 方案也存在上述问题）。 另外，activemq 还有network模式，但此模式的应用场景不是很明确。

    2、多个Activemq broker 同时工做

     经过上面的分析， 简单的采用Activemq官网上提供的方案基本上不能知足生产系统的性能和高可用要求。所以，必须对上述方案进行改进，实现 “高性能”，“高可用”，“可扩展”的MQ集群方案。 

     同时部署多个Activemq broker实例, 多个Activemq broker实例同时工做。单个broker实例，生产和消费消息的速度在1万条/秒，部署N个Broker, 整个消息通道就能拓宽N倍； 多个（4个以上）broker 实例同时工做，其中1到2个mq实例出现问题时，消息可通过其余broker处理，整个系统依然能够健康工做，从而实现高可用。

a、消息发送方的应用程序的采用轮循方式给多个broker发送消息

b、消息消费方的应用程序针对每一个broker启用对应的consumer来消费消息。

     按照这样的部署方案，两个或两个以上MQ能够同时工做，能够解决MQ单点问题。MQ作为消息的传输管道， 增长MQ数量就能够拓宽管道的宽度，提升消息传输性能。

   

     咱们将“多个同时工做的broker"成为 broker组，若是 broker组内的broker数量太多的话，那么再开发或部署时，broker内的队列配置将会是一件很是繁琐的事。所以，咱们将broker内的队列queue进行分组，具备相同前缀名的队列为一组，前缀名相同的队列中的消息的业务逻辑是相同的。经过队列前缀名将消息组件与业务关联上。 根据业务不一样，配置不一样的sender  和 listener 时，只要配置不一样的队列前缀名。从而简化配置与使用，同时也能够防止消息发错队列的错误。

如上图，有 ChargeQueue 和 QueryQueue连个队列组，对应不一样的业务功能。

在消息消费的应用程序中，针对ChargeQueue 和 QueryQueue 配置Consumer Listener Container， 同时能够正对不一样的队列配置不一样数量的消费则数目。

    单个ActiveMQ的接收和消费消息的速度在1万笔/秒（持久化 通常为1-2万， 非持久化 2 万以上），在生产环境中部署10个Activemq就能达到10万笔/秒以上的性能，部署越多的activemq broker 在MQ上latency也就越低，系统吞吐量也就越高。

    3、Activemq 性能优化。

    一、 producer消息发送端，须要采用 AsyncSend模式， 在 activemq 的链接串中增长jsm.useAsyncSend, 例如 tcp://127.0.0.1:61616?jms.useAsyncSend=true 

    二、consumer消息消费端，若是有多个不一样的应用程序去消费同一个队列中的消息，那么 activemq的 prefetchSize应该设置为1。

   以上两个参数对性能的影响很是大。