摘要: Activemq 构建高并发, 高可用的大规模消息系统 在网上看了很多关于 Activemq 的帖子, 但是大部分的内容都只能算是对 activemq 官网内容的翻译. 很少有相关的案例分析, 本文将分享 "如何用 Activemq 构建超大 (10 万笔消息 / 秒以上) 规模消息系统" 在实时消息系统中, MQ 消息中间件广泛应用于各类消息系统中, 在异步消息处理架构中, MQ 几乎是必备的中间件.
在网上看了很多关于 Activemq 的帖子, 但是大部分的内容都只能算是对 activemq 官网内容的翻译. 很少有相关的案例分析, 本文将分享 "如何用 Activemq 构建超大 (10 万笔消息 / 秒以上) 规模消息系统"
在实时消息系统中, MQ 消息中间件广泛应用于各类消息系统中, 在异步消息处理架构中, MQ 几乎是必备的中间件. 同时, MQ 的处理性能也将直接影响整个系统的性能. 如果 MQ 出现故障, 那么整个系统将瘫痪, 其后果将是灾难性的. 所以在一般情况下 MQ 会中 HA, 或是 failover, 但是如果要求消息处理能力在 10 万 / 秒以上时, 简单的 HA 或 failover 将不能满足要求.
一, 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 模式, 但此模式的应用场景不是很明确.
二, 多个 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 也就越低, 系统吞吐量也就越高.
三, Activemq 性能优化.
1, producer 消息发送端, 需要采用 AsyncSend 模式, 在 activemq 的连接串中增加 jsm.useAsyncSend, 例如 tcp://127.0.0.1:61616?jms.useAsyncSend=true
2,consumer 消息消费端, 如果有多个不同的应用程序去消费同一个队列中的消息, 那么 activemq 的 prefetchSize 应该设置为 1.
以上两个参数对性能的影响非常大.
来源: http://www.jianshu.com/p/0b09544ffdf1