为了选择最适合我们业务需求的消息队列系统架构，我们评估了以下候选架构：

• 备选架构 1：开源方案
• 备选架构 2：自研集群 + 存储
• 备选架构 3：自研集群 + 自研存储
• 备选架构 4：直接使用阿里 MetaQ

---

备选架构 1：开源方案

评估 人力成本 测试代表：偏向于引入 Kafka，因为 Kafka 比较成熟，测试投入较少。 部分中间件团队研发人员也支持使用 Kafka，因为它可以节省大量的开发投入。 可维护性 Kafka 是用 Scala 语言编写的，而运维团队没有维护 Scala 语言开发系统的经验，出问题后很难快速处理。 使用 Kafka 无法融入运维团队现有的运维体系，需要单独投入运维人力。 业务场景 部分人员认为 Kafka 可能并不适合我们的业务场景，因为 Kafka 是大容量的日志消息传输，而我们的消息队列是为了业务数据的可靠传输。 学习成本 业务主管倾向于采用 Kafka 方案，因为 Kafka 已经比较成熟，各个业务团队或多或少都了解过 Kafka。

---

备选架构 2：自研集群 + 存储

评估 成本 中间件团队的研发人员认为这个方案比较简单，实现成本低。 测试代表认为这个方案的测试人力投入较大。 运维团队认为这个方案的硬件成本比较高，一个数据分组就需要 4 台机器（2 台服务器 + 2 台数据库）。 可维护性 该方案可以融入到现有的运维体系中。 使用 MySQL 存储数据，可靠性有保证，运维团队也有丰富的 MySQL 运维经验。 业务场景 可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。 性能 部分研发人员对于这个方案的性能持怀疑态度，因为使用 MySQL 来存储消息数据，性能肯定不如使用文件系统。 其他 是否会影响中间件团队的技术声誉，毕竟用 MySQL 来做消息队列，看起来比较土、比较另类。

---

备选架构 3：自研集群 + 自研存储

评估 成本 要做到稳定可靠的存储系统，需要较长时间迭代，投入成本大。 自研存储系统的测试难度高，投入也很大。 可维护性 可以融入到现有的运维体系中，但自研存储系统需要较长时间才能成熟，增大了运维风险和投入。 业务场景 可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。 性能 性能上相比 MySQL 要高，但初步评估并不能高太多。 可用性 从历史经验来看，新系统上线肯定有 bug，而存储系统出 bug 是最严重的，一旦出 bug 导致大量消息丢失，影响会很严重。 团队技术实力 方案复杂度太高，按照目前的团队人力和技术实力，要做到稳定可靠的存储系统，有较大风险。 运维团队并不相信目前的中间件团队的技术实力足以支撑自己研发一个存储系统。

---

备选架构 4：直接使用阿里 MetaQ

评估 成本 低，接入即可。 可维护性 UC 机房和阿里机房隔离，打通困难，如果在 UC 机房部署阿里的系统，部署、维护、升级的人力成本太高。 UC 机房 3 年内估计不会切换阿里机房。 业务场景 可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。 性能 性能上和 Kafka 基本持平。 可用性 已经上线运行，支撑阿里业务，久经考验。

---

结论

经过评估，我们认为以下两个方案最适合我们的业务需求： 备选架构 2：自研集群 + 存储：可维护性好，可以定制开发业务场景所需特性，但是硬件成本较高。 备选架构 4：直接使用阿里 MetaQ：成本低，可用性好，但是可维护性差。 我们建议进一步评估这两个方案的细节，并根据我们的具体业务需求和资源限制做出最终决定。

---

RabbitMQ架构

RabbitMQ是一个分布式系统 一、使用rabbitmq时的系统架构图通过路由键将交换机和队列进行绑定，从而实现消息的发送和接收。 二、rabbitmq基本概念 rabbitmq是AMQP协议的一个开源实现，所以其内部实际上也是AMQP中的基本概念，如下图所示： 1、Message（消息） 消息是不具名的，它由消息头和消息体组成。 消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（传输模式，指出该消息可能需要持久化存储）等。 2、Publisher 消息生产者，也是一个向交换器发布消息的客户端应用程序，就是投递消息的程序。 3、Exchange 交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 消息交换机，它指定消息按什么规则，路由到哪个队列。 4、Routing Key 路由关键字，exchange根据这个关键字进行消息投递。 5、Binding（绑定） 用于消息队列和交换器之间的关联。 一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。 它的作用就是把exchange和queue按照路由规则绑定起来。 绑定其实就是关联了exchange和queue，或者这么说：queue对exchange的内容感兴趣，exchange要把它的Message deliver到queue。 6、Queue（消息队列） 消息的载体，每个消息都会被投到一个或多个队列，等待消费者连接到这个队列将其取走。 它是消息的容器，也是消息的终点。 7、Connection 网络连接，例如一个TCP连接。 8、Channel（信道，通道） 消息通道，在客户端的每个连接里，可建立多个channel。 多路复用连接中的一条独立双向数据流通道。 信道是建立在真实的TCP连接内的虚拟连接，AMQP命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。 因为对于操作系统来说建立和销毁TCP都是非常昂贵的开销，所以引入了信道的概念以达到复用一条TCP连接的目的。 9、Consumer 消息消费者，表示一个从消息队列中取得消息的客户端应用程序，就是接受消息的程序。 10、Virtual Host 虚拟主机，表示一批交换器、消息队列和相关对象。 一个broker里可以有多个vhost，用作不同用户的权限分离。 虚拟主机是共享相同的身份认证和加密环境的独立服务器域。 每个vhost本质上就是一个mini版的rabbitmq服务器，拥有自己的队列、交换器、绑定和权限机制。 vhost是AMQP概念的基础，必须在连接时指定，rabbitmq默认的vhost是 / 。 11、Broker 表示消息队列服务器实体。 它提供一种传输服务，它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输。 三、AMQP中的消息路由 生产者把消息发布到Exchange上，消息最终到达队列并被消费者接收，而Binding决定交换器的消息应该发送到那个队列。 如下图所示： 四、Exchange类型 Exchange分发消息时根据类型的不同分发策略有区别，目前共有四种类型：direct、fanout、topic、headers。 headers匹配AMQP消息的header而不是路由键，此外headers交换器和direct交换器完全一致，但性能差很多，目前几乎用不到。 且看direct、fanout、topic这三种类型。 1、direct类型 消息中的路由键routing key如果和Binding中的binding key一致，交换器就将消息发到对应的队列中去。 路由键与队列名完全匹配，如果一个队列绑定到交换器要求路由键为“dog”，则只转发routing key标记为“dog”的消息，不会转发“”等等。 它是完全匹配、单传播的模式。 Driect exchange的路由算法非常简单：通过bindingkey的完全匹配，可以用下图来说明： Exchange和两个队列绑定在一起，Q1的bindingkey是orange，Q2的binding key是black和green。 当Producer publish key是orange时，exchange会把它放到Q1上，如果是black或green就会到Q2上，其余的Message被丢弃。 2、fanout类型 每个发到fanout类型交换器的消息都会分到所有绑定的队列上去。 fanout交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。 类似于子网广播，每台子网内的主机都获得了一份复制的消息。 fanout类型转发消息是最快的。 如下图所示： 3、topic类型 topic交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。 它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。 它同样也会识别两个通配符：#和*，#匹配0个或多个单词，*只能匹配一个单词。 对于Message的routing_key是有限制的，不能是任意的。 格式是以点号“.”分割的字符表。 比如：””，“”， “”。 你可以放任意的key在routing_key中，当然最长不能超过255 bytes。 对于routing_key，有两个特殊字符#和*，#匹配0个或多个单词，*只能匹配一个单词。 如下图所示： Producer发送消息时需要设置routing_key，routing_key包含三个单词和两个点号，第一个key描述了celerity(灵巧)，第二个是color(色彩)，第三个是物种。 在这里我们创建了两个绑定： Q1 的binding key 是”.“； Q2 是 “” 和 “lazy.#”：Q1感兴趣所有orange颜色的动物；Q2感兴趣所有rabbits和所有的lazy的。 例如：rounting_key 为 “”将会发送到Q1和Q2中。 rounting_key 为””会被投递到Q2中，#匹配0个或多个单词。 五、ConnectionFactory、Connection、Channel ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。 1、Connection Connection是Rabbitmq的socket连接，它封装了socket协议相关部分逻辑。 2、ConnectionFactory ConnectionFactory是connection的制造工厂。 3、Channel Channel是我们与rabbitmq打交道的最重要的一个接口，大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。 六、任务分发机制 1、Round-robin dispathching 循环分发 RabbbitMQ的分发机制非常适合扩展,而且它是专门为并发程序设计的,如果现在load加重,那么只需要创建更多的Consumer来进行任务处理。 2、Message acknowledgment 消息确认 为了保证数据不被丢失，RabbitMQ支持消息确认机制，为了保证数据能被正确处理而不仅仅是被Consumer收到，这就需要在处理完数据之后发送一个确认ack。 在处理完数据之后发送ack，就是告诉RabbitMQ数据已经被接收并且处理完成，RabbitMQ可以将消息从队列中移除了。 如果Consumer退出了但是没有发送ack，那么RabbitMQ就会把这个Message发送到下一个Consumer，这样就保证在Consumer异常退出情况下数据也不会丢失。 RabbitMQ没有用到超时机制，它仅仅通过Consumer的连接中断来确认该Message并没有被正确处理，一个消费者处理消息的时间再长也不会导致该消息被发送给其他消费者，即RabbitMQ给了Consumer足够长的时间来做数据处理。 如果忘记ack，那么当Consumer退出时，Mesage会被重新分发，从而导致队列中的累积的消息越来越多，然后RabbitMQ会占用越来越多的内存。 3、Message durability 消息持久化 如果我们希望即使在rabbitmq服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都设置成可持久化的（durable），这样就可以保证绝大部分情况下我们的rabbitmq消息不会丢失。 但依然解决不了小概率丢失事件的发生（例如rabbitmq服务器已经接收到了生产者的消息，但还没来得及持久化该消息时rabbitmq服务器就断电了）。 如果也要将这种小概率事件管理起来就需要使用到事务了。 要持久化队列需要在声明时指定durable=True；这里要注意,队列的名字一定要是Broker中不存在的，不然不能改变此队列的任何属性。 队列和交换机有一个创建时候指定的标志durable，durable的唯一含义就是让具有这个标志的队列和交换机会在重启之后重新建立。 消息持久化包括3部分 （1）exchange持久化，在声明时指定durable => true (ExchangeName,direct, durable:true, autoDelete:false, arguments:null);//声明消息队列，且为可持久的 （2）queue持久化，在声明时指定durable => true (QueueName, durable:true, exclusive:false, autoDelete:false, arguments:null);//声明消息队列，且为可持久的 （3）消息持久化，在投递时指定delivery_mode => 2(1是非持久化)。 (, queueName, _TEXT_PLAIN, ());如果exchange和queue都是持久化的，那么它们之间的binding也是持久化的；如果exchange和queue两者之间有一个持久化，一个非持久化,则不允许建立绑定。 注意：一旦创建了队列和交换机，就不能修改其标志了。 例如创建了一个non-durable的队列，然后想把它改变成durable的，唯一的办法就是删除这个队列然后重新创建。 4、Fair dispath 公平分发 你可能也注意到了，分发机制不是那么优雅，默认状态下，RabbitMQ将第n个Message分发给第n个Consumer。 n是取余后的，它不管Consumer是否还有unacked Message，只是按照这个默认的机制进行分发。 那么如果有个Consumer工作比较重，那么就会导致有的Consumer基本没事可做，有的Consumer却毫无休息的机会，那么Rabbit是如何处理这种问题呢? 通过方法设置prefetch_count=1，如下设置 _qos(prefetch_count=1) 这样RabbitMQ就会使得每个Consumer在同一个时间点最多处理一个Message，换句话说，在接收到该Consumer的ack前，它不会将新的Message分发给它。 但是这种方法可能会导致queue满。 当然，这种情况下你可能需要添加更多的Consumer，或者创建更多的virtualHost来细化你的设计。 5、分发到多个Consumer Direct Exchange：直接匹配，通过Exchange名称+RountingKey来发送与接收消息。 Fanout Exchange：广播订阅，向所有的消费者发布消息，但是只有消费者将队列绑定到该路由器才能收到消息，忽略Routing Key。 Topic Exchange：主题匹配订阅，这里的主题指的是RoutingKey，RoutingKey可以采用通配符，如：*或#，RoutingKey命名采用英文句点来分隔多个词，只有消息将队列绑定到该路由器且指定RoutingKey符合匹配规则时才能收到消息。 Headers Exchange：消息头订阅，消息发布前为消息定义一个或多个键值对的消息头，然后消费者接收消息，同时需要定义类似的键值对请求头（如 x-mactch=all或者x_match=any），只有请求头与消息头匹配，才能接收消息,忽略RoutingKey。 默认的exchange：如果用空字符串去声明一个exchange，那么系统就会使用””这个exchange。 我们创建一个queue时，默认的都会有一个和新建queue同名的routingKey绑定到这个默认的exchange上去。 如下： (,TaskQueue, properties, bytes); 因为在第一个参数选择了默认的exchange，而我们声明的队列叫TaskQueue，所以默认的，它要新建一个也叫TaskQueue的routingKey，并绑定在默认的exchange上，导致了我们可以在第二个参数routingKey中写TaskQueue，这样它就会找到定义的同名的queue并把消息放进去。 如果有两个接收程序都是用了同一个的queue和相同的routingKey去绑定direct exchange的话，分发的行为是负载均衡的，也就是说第一个是程序1收到，第二个是程序2收到，以此类推。 如果有两个接收程序用了各自的queue，但使用相同的routingKey去绑定direct exchange的话，分发的行为是复制的，即每个程序都会收到这个消息的副本。 行为相当于fanout类型的exchange。 多个queue绑定同一个key也是可以的，对于下图的例子，Q1和Q2都绑定了black，对于routing key是black的Message，会被deliver到Q1和Q2，其余的Message都会被丢弃。 七、RPC远程过程调用 MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。 但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。 这相当于RPC（Remote Procedure Call，远程过程调用）。 在RabbitMQ中也支持RPC。 RabbitMQ中实现RPC的机制如下图所示： 客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14种properties，这些属性会随着消息一起发送）中设置两个值replyTo（一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和correlationId（此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行或执行失败）。 服务器端收到消息并处理，服务器端处理完消息后，将生成一条应答消息到replyTo指定的Queue中 ，同时带上correlationId属性，客户端之前已订阅replyTo指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId属性分析哪条请求被执行了，然后根据执行结果进行后续业务处理。 转发：

大型的PHP应用，通常使用什么应用做消息队列？

一、消息队列概述\x0d\x0a消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。 实现高性能，高可用，可伸缩和最终一致性架构。 是大型分布式系统不可缺少的中间件。 \x0d\x0a目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。 \x0d\x0a二、消息队列应用场景\x0d\x0a以下介绍消息队列在实际应用中常用的使用场景。 异步处理，应用解耦，流量削锋和消息通讯四个场景。 \x0d\x0a2.1异步处理\x0d\x0a场景说明：用户注册后，需要发注册邮件和注册短信。 传统的做法有两种1.串行的方式；2.并行方式。 \x0d\x0a（1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。 以上三个任务全部完成后，返回给客户端。 （架构KK，欢迎加入）\x0d\x0a（2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。 以上三个任务完成后，返回给客户端。 与串行的差别是，并行的方式可以提高处理的时间。 \x0d\x0a假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 \x0d\x0a因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。 则串行方式1秒内CPU可处理的请求量是7次（1000/150）。 并行方式处理的请求量是10次（1000/100）。 \x0d\x0a小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。 如何解决这个问题呢？\x0d\x0a引入消息队列，将不是必须的业务逻辑，异步处理。 改造后的架构如下：\x0d\x0a按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。 注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。 因此架构改变后，系统的吞吐量提高到每秒20 QPS。 比串行提高了3倍，比并行提高了两倍。 \x0d\x0a2.2应用解耦\x0d\x0a场景说明：用户下单后，订单系统需要通知库存系统。 传统的做法是，订单系统调用库存系统的接口。 如下图：\x0d\x0a传统模式的缺点：\x0d\x0a1）假如库存系统无法访问，则订单减库存将失败，从而导致订单失败；\x0d\x0a2）订单系统与库存系统耦合；\x0d\x0a如何解决以上问题呢？引入应用消息队列后的方案，如下图：\x0d\x0a订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。 \x0d\x0a库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。 \x0d\x0a假如：在下单时库存系统不能正常使用。 也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。 实现订单系统与库存系统的应用解耦。 \x0d\x0a2.3流量削锋\x0d\x0a流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。 \x0d\x0a应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。 为解决这个问题，一般需要在应用前端加入消息队列。 \x0d\x0a可以控制活动的人数；\x0d\x0a可以缓解短时间内高流量压垮应用；\x0d\x0a用户的请求，服务器接收后，首先写入消息队列。 假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面；\x0d\x0a秒杀业务根据消息队列中的请求信息，再做后续处理。 \x0d\x0a2.4日志处理\x0d\x0a日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。 架构简化如下：\x0d\x0a日志采集客户端，负责日志数据采集，定时写受写入Kafka队列；\x0d\x0aKafka消息队列，负责日志数据的接收，存储和转发；\x0d\x0a日志处理应用：订阅并消费kafka队列中的日志数据；\x0d\x0a以下是新浪kafka日志处理应用案例：\x0d\x0a(1)Kafka：接收用户日志的消息队列。 \x0d\x0a(2)Logstash：做日志解析，统一成JSON输出给Elasticsearch。 \x0d\x0a(3)Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。 \x0d\x0a(4)Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因。 \x0d\x0a2.5消息通讯\x0d\x0a消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。 比如实现点对点消息队列，或者聊天室等。 \x0d\x0a点对点通讯：\x0d\x0a客户端A和客户端B使用同一队列，进行消息通讯。 \x0d\x0a聊天室通讯：\x0d\x0a客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。 实现类似聊天室效果。 \x0d\x0a以上实际是消息队列的两种消息模式，点对点或发布订阅模式。 模型为示意图，供参考。 \x0d\x0a三、消息中间件示例\x0d\x0a3.1电商系统\x0d\x0a消息队列采用高可用，可持久化的消息中间件。 比如Active MQ，Rabbit MQ，Rocket Mq。 （1）应用将主干逻辑处理完成后，写入消息队列。 消息发送是否成功可以开启消息的确认模式。 （消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）\x0d\x0a（2）扩展流程（发短信，配送处理）订阅队列消息。 采用推或拉的方式获取消息并处理。 \x0d\x0a（3）消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。 比如主数据写入数据库，扩展应用根据消息队列，并结合数据库方式实现基于消息队列的后续处理。 \x0d\x0a3.2日志收集系统\x0d\x0a分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群（OtherApp）四部分组成。 \x0d\x0aZookeeper注册中心，提出负载均衡和地址查找服务；\x0d\x0a日志收集客户端，用于采集应用系统的日志，并将数据推送到kafka队列；\x0d\x0a四、JMS消息服务\x0d\x0a讲消息队列就不得不提JMS 。 JMS（Java Message Service,Java消息服务）API是一个消息服务的标准/规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。 它使分布式通信耦合度更低，消息服务更加可靠以及异步性。 \x0d\x0a在EJB架构中，有消息bean可以无缝的与JM消息服务集成。 在J2EE架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。 \x0d\x0a4.1消息模型\x0d\x0a在JMS标准中，有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。 \x0d\x0a4.1.1 P2P模式\x0d\x0aP2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。 每个消息都被发送到一个特定的队列，接收者从队列中获取消息。 队列保留着消息，直到他们被消费或超时。 \x0d\x0aP2P的特点\x0d\x0a每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)\x0d\x0a发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列\x0d\x0a接收者在成功接收消息之后需向队列应答成功\x0d\x0a如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。 （架构KK，欢迎加入）\x0d\x0a4.1.2 Pub/sub模式\x0d\x0a包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber） 。 多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。 \x0d\x0aPub/Sub的特点\x0d\x0a每个消息可以有多个消费者\x0d\x0a发布者和订阅者之间有时间上的依赖性。 针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。 \x0d\x0a为了消费消息，订阅者必须保持运行的状态。 \x0d\x0a为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。 这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。 \x0d\x0a如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。 \x0d\x0a4.2消息消费\x0d\x0a在JMS中，消息的产生和消费都是异步的。 对于消费来说，JMS的消息者可以通过两种方式来消费消息。 \x0d\x0a（1）同步\x0d\x0a订阅者或接收者通过receive方法来接收消息，receive方法在接收到消息之前（或超时之前）将一直阻塞；\x0d\x0a（2）异步\x0d\x0a订阅者或接收者可以注册为一个消息监听器。 当消息到达之后，系统自动调用监听器的onMessage方法。 \x0d\x0aJNDI：Java命名和目录接口,是一种标准的Java命名系统接口。 可以在网络上查找和访问服务。 通过指定一个资源名称，该名称对应于数据库或命名服务中的一个记录，同时返回资源连接建立所必须的信息。 \x0d\x0aJNDI在JMS中起到查找和访问发送目标或消息来源的作用。 （架构KK，欢迎加入）\x0d\x0a4.3JMS编程模型\x0d\x0a(1) ConnectionFactory\x0d\x0a创建Connection对象的工厂，针对两种不同的jms消息模型，分别有QueueConnectionFactory和TopicConnectionFactory两种。 可以通过JNDI来查找ConnectionFactory对象。 \x0d\x0a(2) Destination\x0d\x0aDestination的意思是消息生产者的消息发送目标或者说消息消费者的消息来源。 对于消息生产者来说，它的Destination是某个队列（Queue）或某个主题（Topic）;对于消息消费者来说，它的Destination也是某个队列或主题（即消息来源）。 \x0d\x0a所以，Destination实际上就是两种类型的对象：Queue、Topic可以通过JNDI来查找Destination。 \x0d\x0a(3) Connection\x0d\x0aConnection表示在客户端和JMS系统之间建立的链接（对TCP/IP socket的包装）。 Connection可以产生一个或多个Session。 跟ConnectionFactory一样，Connection也有两种类型：QueueConnection和TopicConnection。 \x0d\x0a(4) Session\x0d\x0aSession是操作消息的接口。 可以通过session创建生产者、消费者、消息等。 Session提供了事务的功能。 当需要使用session发送/接收多个消息时，可以将这些发送/接收动作放到一个事务中。 同样，也分QueueSession和TopicSession。 \x0d\x0a(5) 消息的生产者\x0d\x0a消息生产者由Session创建，并用于将消息发送到Destination。 同样，消息生产者分两种类型：QueueSender和TopicPublisher。 可以调用消息生产者的方法（send或publish方法）发送消息。 \x0d\x0a(6) 消息消费者\x0d\x0a消息消费者由Session创建，用于接收被发送到Destination的消息。 两种类型：QueueReceiver和TopicSubscriber。 可分别通过session的createReceiver(Queue)或createSubscriber(Topic)来创建。 当然，也可以session的creatDurableSubscriber方法来创建持久化的订阅者。 \x0d\x0a(7) MessageListener\x0d\x0a消息监听器。 如果注册了消息监听器，一旦消息到达，将自动调用监听器的onMessage方法。 EJB中的MDB（Message-Driven Bean）就是一种MessageListener。 \x0d\x0a深入学习JMS对掌握JAVA架构，EJB架构有很好的帮助，消息中间件也是大型分布式系统必须的组件。 本次分享主要做全局性介绍，具体的深入需要大家学习，实践，总结，领会。 \x0d\x0a五、常用消息队列\x0d\x0a一般商用的容器，比如WebLogic，JBoss，都支持JMS标准，开发上很方便。 但免费的比如Tomcat，Jetty等则需要使用第三方的消息中间件。 本部分内容介绍常用的消息中间件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他们的特点。 \x0d\x0a5.1 ActiveMQ\x0d\x0aActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。 ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。 \x0d\x0aActiveMQ特性如下：\x0d\x0a⒈ 多种语言和协议编写客户端。 语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。 应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP\x0d\x0a⒉ 完全支持JMS1.1和J2EE 1.4规范 （持久化，XA消息，事务)\x0d\x0a⒊ 对spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统里面去，而且也支持Spring2.0的特性\x0d\x0a⒋ 通过了常见J2EE服务器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，其中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上\x0d\x0a⒌ 支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA\x0d\x0a⒍ 支持通过JDBC和journal提供高速的消息持久化\x0d\x0a⒎ 从设计上保证了高性能的集群，客户端-服务器，点对点\x0d\x0a⒏ 支持Ajax\x0d\x0a⒐ 支持与Axis的整合\x0d\x0a⒑ 可以很容易得调用内嵌JMS provider，进行测试\x0d\x0a5.2 RabbitMQ\x0d\x0aRabbitMQ是流行的开源消息队列系统，用erlang语言开发。 RabbitMQ是AMQP（高级消息队列协议）的标准实现。 支持多种客户端，如：Python、Ruby、、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。 用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 \x0d\x0a几个重要概念：\x0d\x0aBroker：简单来说就是消息队列服务器实体。 \x0d\x0aExchange：消息交换机，它指定消息按什么规则，路由到哪个队列。 \x0d\x0aQueue：消息队列载体，每个消息都会被投入到一个或多个队列。 \x0d\x0aBinding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。 \x0d\x0aRouting Key：路由关键字，exchange根据这个关键字进行消息投递。 \x0d\x0avhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。 \x0d\x0aproducer：消息生产者，就是投递消息的程序。 \x0d\x0aconsumer：消息消费者，就是接受消息的程序。 \x0d\x0achannel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。 \x0d\x0a消息队列的使用过程，如下：\x0d\x0a（1）客户端连接到消息队列服务器，打开一个channel。 \x0d\x0a（2）客户端声明一个exchange，并设置相关属性。 \x0d\x0a（3）客户端声明一个queue，并设置相关属性。 \x0d\x0a（4）客户端使用routing key，在exchange和queue之间建立好绑定关系。 \x0d\x0a（5）客户端投递消息到exchange。 \x0d\x0aexchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。 \x0d\x0a5.3 ZeroMQ\x0d\x0a号称史上最快的消息队列，它实际类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。 ZMQ用于node与node间的通信，node可以是主机或者是进程。 \x0d\x0a引用官方的说法： “ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。 是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。 ZMQ的明确目标是“成为标准网络协议栈的一部分，之后进入Linux内核”。 现在还未看到它们的成功。 但是，它无疑是极具前景的、并且是人们更加需要的“传统”BSD套接字之上的一 层封装。 ZMQ让编写高性能网络应用程序极为简单和有趣。 ”\x0d\x0a特点是：\x0d\x0a高性能，非持久化；\x0d\x0a跨平台：支持Linux、Windows、OS X等。 \x0d\x0a多语言支持； C、C++、Java、、Python等30多种开发语言。 \x0d\x0a可单独部署或集成到应用中使用；\x0d\x0a可作为Socket通信库使用。 \x0d\x0a与RabbitMQ相比，ZMQ并不像是一个传统意义上的消息队列服务器，事实上，它也根本不是一个服务器，更像一个底层的网络通讯库，在Socket API之上做了一层封装，将网络通讯、进程通讯和线程通讯抽象为统一的API接口。 支持“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三种基本模型和扩展模型。 \x0d\x0aZeroMQ高性能设计要点：\x0d\x0a1、无锁的队列模型\x0d\x0a对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。 \x0d\x0a2、批量处理的算法\x0d\x0a对于传统的消息处理，每个消息在发送和接收的时候，都需要系统的调用，这样对于大量的消息，系统的开销比较大，zeroMQ对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。 \x0d\x0a3、多核下的线程绑定，无须CPU切换\x0d\x0a区别于传统的多线程并发模式，信号量或者临界区， zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。 \x0d\x0a5.4 Kafka\x0d\x0aKafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。 Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。 \x0d\x0aKafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：\x0d\x0a通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。 （文件追加的方式写入数据，过期的数据定期删除）\x0d\x0a高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。 \x0d\x0a支持通过Kafka服务器和消费机集群来分区消息。 \x0d\x0a支持Hadoop并行数据加载。 \x0d\x0aKafka相关概念\x0d\x0aBroker\x0d\x0aKafka集群包含一个或多个服务器，这种服务器被称为broker[5]\x0d\x0aTopic\x0d\x0a每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。 （物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）\x0d\x0aPartition\x0d\x0aParition是物理上的概念，每个Topic包含一个或多个Partition.\x0d\x0aProducer\x0d\x0a负责发布消息到Kafka broker\x0d\x0aConsumer\x0d\x0a消息消费者，向Kafka broker读取消息的客户端。 \x0d\x0aConsumer Group\x0d\x0a每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。 \x0d\x0a一般应用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢数据）要求稍低的场景使用。