文档介绍：消息队列实施方案 1 、背景异步解耦合、给前端系统提供最高效的反应 2 、常见消息队列对比 2、 1 ActiveMq ActiveMQ 是一个完全支持和 J2EE 规范的 JMS Provider 实现优点: Java 语言支持集群模式缺点: 性能在消息中间件中处于下游 2、 2 Rabbitmq R abbitmq 是基于 AMQP 使用 erlang 语言实现的消息队列系统优点: 1 、完整的消息队列系统,支持多种消息队列模式,包括竞争消费; 2 、支持集群模式,扩展集群容量和性能比较方便,集成了集群的监控和管理; 3 、支持消息的持久化; 缺点: 1 、需要学习比较复杂的接口和协议,比较耗费时间; 2 、性能不是特别理想大概在 1wqps 左右; 3 、使用 Erlang 语言, 语言基础; 2、 3 Kafka Kafka 是 LinkedIn 开发的一个高性能、分布式的消息发布订阅系统。优点: 1 、分布式集群可以透明的扩展,增加新的服务器进集群。 2 、高性能。单机写入 TPS 约在百万条/秒 3 、容错。数据都会复制到几台服务器上。缺点: 1 、复杂性。 Kafka 需要 zookeeper 集群的支持, Topic 通常需要人工来创建,部署和维护较一般消息队列成本更高定位于日志传输、存在消息丢失的肯能、消息乱序 3 、消息发送错误无重试 2、 4 RocketMQ R ockerMq 是阿里公司中间件团队参考 Kafka 思想,用 J ava 语言实现的消息传输系统优点: 1 、较高性能, 单机写入 TPS 单实例约 7 万条/秒 2 、容错,多种集群模式、可以解决容错问题 3 、消息重试发送 4、顺序消息可以严格执行缺点: 1 、消息重复、消费端需要做去重操作 2、 5选用结论从项目业务与团队技术偏向考虑, 我们应该需要一种数据安全性比较高, 保证每个消息都会被执行; 有容错机制、支持集群模式高可用; 性能不错, 可以在毫秒级处理消息; 支持顺序消息的消息中间件, R ockerMq 可以满足这些要求。 3、R ockerMq 简介 3、 1 Rock erMq 产品介绍参考阿里公司提供的《 RocketMQ 开发指南》,最新版针对 3、 2 Rock erMq 集群 3、2、1 部署方式 Rock ermq 共有四种部署方式,分别是: 1 、单个 Maste r 一旦 Broker 重启或者宕机时,会导致整个服务不可用 2 、多 Master 模式一个集群无 Slave ,全是 Master ,例如 2个 Master 戒者 3个 Master 优点: 1 、配置简单, 2 、容错,单个 Master 宕机或重启维护对应用无影响,在磁盘配置为 RAID10 时,即使机器宕机不可恢复情况下,由于 RAID10 磁盘非常可靠,在同步刷盘时消息不会丢,异步刷盘丢失少量消息, 3 、性能最高。 3 、多 Master 多 Slave 模式,异步复制每个 Master 配置一个或多个 Slave ,有多对 Master-Slave , HA (高可用集群)采用异步复制方式,主备有短暂消息延迟,毫秒级。优点: 1 、即使磁盘损坏,消息丢失的非常少,消息实时性不会被影响,因为 Master 宕机后,消费者仍然可以从 Slave 消费, 此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。缺点: 1、 Master 宕机,磁盘损坏时,因为主备有短暂消息延迟,未复制到 slave 的消息会丢失。 2 、目前 master 宕机后,备机不能自动切换为主机。只有 mas ter 可以接收消息,若所有 master 宕机,将不能接收消息 4 、多 Master 多 Slave 模式,同步双写每个 Master 配置一个或多个 Slave ,有多对 Master-Slave , HA 采用同步双写方式,主备都写成功,才返回成功。优点: 数据与服务都无单点, Master 宕机情冴下, 消费者可以从 slave 消费、消息无延迟, 服务可用性与数据可用性都非常高缺点: 1 、性能比异步复制模式略低,収送单个消息的 RT (返回时间)会略高。 2 、目前 master 宕机后,备机不能自动切换为主机。只有 mas ter 可以接收消息,若所有 master 宕机,将不能接收消息选用结论由于我们需要保证消息中间件的高可用性,消息不丢失、消息无延迟,所以我们选择“多 Master 多 Slave 模式,同步双写”模式。并且选择同步刷盘。 3、2、2多 Master 多S lav e 模式多 master 多 slave 模式网络结构图主要组件有: Name Serve r、 Bro