1、引言
对于即时通讯网来说，所有的技术文章和资料都在围绕即时通讯这个技术方向进行整理和分享，这一次也不例外。对于即时通讯系统（包括IM、讯息推送系统等）来说，MQ讯息中件间是非常常见的基础软件，但市面上种类众多、各有所长的MQ讯息中件间产品，该怎么去选择？这是个问题！对于很多经验不足的开发者来说，一个公司内部用的IM聊天系统，总使用者量也不过百十来人，动辄就是Kafka、MongoDB，美其名曰为了高效能和可扩充套件性，真是大炮打蚊子。而对于中大型的即时通讯场景来说，有的开发者确为了贪图使用简单、资料全面，反而使用臃肿不堪的ActiveMQ，这就有点失去章法了。
唧唧歪歪这么多，那什么样的场景到底该用哪种MQ讯息中件间产品合适？读完本文您或许就有了答案。
本文将从17个维度综合对比Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ这5款当前最主流的MQ讯息中介软件产品，希望能为您的下一次产品的架构设计和MQ讯息中介软件选型提供参考依据。
（本文同步释出于：http://www.52im.net/thread-2625-1-1.html）
2、相关资料
官网地址：Kafka：http://kafka.apache.org/
RabbitMQ：https://www.rabbitmq.com/
ZeroMQ：http://zeromq.org/
RocketMQ：http://rocketmq.apache.org/
ActiveMQ：http://activemq.apache.org/
相关文章：
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ讯息伫列》
《IM系统的MQ讯息中介软件选型：Kafka还是RabbitMQ？》
3、维度1：资料文件
1）Kafka：资料数量中等。有Kafka作者自己写的书，网上资料也有一些。2）RabbitMQ：资料数量多。有一些不错的书，网上资料多。
3）ZeroMQ：资料数量少。专门写ZeroMQ的书较少，网上的资料多是一些程式码的实现和简单介绍。
4）RocketMQ：资料数量少。专门写RocketMQ的书目前有了两本；网上的资料良莠不齐，官方文件很简洁，但是对技术细节没有过多的描述。
5）ActiveMQ：资料数量多。没有专门写ActiveMQ的书，网上资料多。
4、维度2：开发语言
1）Kafka：Scala2）RabbitMQ：Erlang
3）ZeroMQ：C语言
4）RocketMQ：Java
5）ActiveMQ：Java
5、维度3：支援的协议
1）Kafka：自己定义的一套…（基于TCP）2）RabbitMQ：AMQP
3）ZeroMQ：TCP、UDP
4）RocketMQ：自己定义的一套…
5）ActiveMQ：OpenWire、STOMP、REST、XMPP、AMQP
6、维度4：讯息储存
1）Kafka：内存、磁盘、数据库。支援大量堆积。
Kafka的最小储存单元是分割槽，一个topic包含多个分割槽，Kafka建立主题时，这些分割槽会被分配在多个服务器上，通常一个broker一台服务器。
分割槽首领会均匀地分布在不同的服务器上，分割槽副本也会均匀的分布在不同的服务器上，确保负载均衡和高可用性，当新的broker加入丛集的时候，部分副本会被移动到新的broker上。
根据配置档案中的目录清单，Kafka会把新的分割槽分配给目录清单里分割槽数最少的目录。
预设情况下，分割槽器使用轮询算法把讯息均衡地分布在同一个主题的不同分割槽中，对于传送时指定了key的情况，会根据key的hashcode取模后的值存到对应的分割槽中。
2）RabbitMQ：
内存、磁盘。支援少量堆积。
RabbitMQ的讯息分为持久化的讯息和非持久化讯息，不管是持久化的讯息还是非持久化的讯息都可以写入到磁盘。
持久化的讯息在到达伫列时就写入到磁盘，并且如果可以，持久化的讯息也会在内存中储存一份备份，这样可以提高一定的效能，当内存吃紧的时候会从内存中清除。
非持久化的讯息一般只存在于内存中，在内存吃紧的时候会被换入到磁盘中，以节省内存。
引入映象伫列机制，可将重要伫列“复制”到丛集中的其他broker上，保证这些伫列的讯息不会丢失。
配置映象的伫列，都包含一个主节点master和多个从节点slave,如果master失效，加入时间最长的slave会被提升为新的master，除传送讯息外的所有动作都向master传送，然后由master将命令执行结果广播给各个slave，RabbitMQ会让master均匀地分布在不同的服务器上，而同一个伫列的slave也会均匀地分布在不同的服务器上，保证负载均衡和高可用性。
3）ZeroMQ：
讯息传送端的内存或者磁盘中。不支援持久化。
4）RocketMQ：
磁盘。支援大量堆积。
commitLog档案存放实际的讯息资料，每个commitLog上限是1G，满了之后会自动新建一个commitLog档案储存资料。
ConsumeQueue伫列只存放offset、size、tagcode，非常小，分布在多个broker上。
ConsumeQueue相当于CommitLog的索引档案，消费者消费时会从consumeQueue中查询讯息在commitLog中的offset，再去commitLog中查询元资料。
ConsumeQueue储存格式的特性，保证了写过程的顺序写盘（写CommitLog档案），大量资料IO都在顺序写同一个commitLog，满1G了再写新的。
加上RocketMQ是累计4K才强制从PageCache中刷到磁盘（快取），所以高并发写效能突出。
5）ActiveMQ：
内存、磁盘、数据库。支援少量堆积。
7、维度5：讯息事务
1）Kafka：支援2）RabbitMQ：支援。客户端将通道设定为事务模式，只有当讯息被RabbitMQ接收，事务才能提交成功，否则在捕获异常后进行回滚。使用事务会使得效能有所下降
3）ZeroMQ：不支援
4）RocketMQ：支援
5）ActiveMQ：支援
8、维度6：负载均衡
8.1 Kafka支援负载均衡。
1）一个broker通常就是一台服务器节点。
对于同一个Topic的不同分割槽，Kafka会尽力将这些分割槽分布到不同的Broker服务器上，zookeeper储存了broker、主题和分割槽的元资料资讯。
分割槽首领会处理来自客户端的生产请求，Kafka分割槽首领会被分配到不同的broker服务器上，让不同的broker服务器共同分担任务。
每一个broker都快取了元资料资讯，客户端可以从任意一个broker获取元资料资讯并快取起来，根据元资料资讯知道要往哪里传送请求。
2）Kafka的消费者组订阅同一个topic，会尽可能地使得每一个消费者分配到相同数量的分割槽，分摊负载。
3）当消费者加入或者退出消费者组的时候，还会触发再均衡，为每一个消费者重新分配分割槽，分摊负载。
Kafka的负载均衡大部分是自动完成的，分割槽的建立也是Kafka完成的，隐藏了很多细节，避免了繁琐的配置和人为疏忽造成的负载问题。
4）传送端由topic和key来决定讯息发往哪个分割槽，如果key为null，那么会使用轮询算法将讯息均衡地传送到同一个topic的不同分割槽中。如果key不为null，那么会根据key的hashcode取模计算出要发往的分割槽。
8.2 RabbitMQ
对负载均衡的支援不好。
1）讯息被投递到哪个伫列是由交换器和key决定的，交换器、路由键、伫列都需要手动建立。
RabbitMQ客户端传送讯息要和broker建立连线，需要事先知道broker上有哪些交换器，有哪些伫列。
通常要宣告要传送的目标伫列，如果没有目标伫列，会在broker上建立一个伫列，如果有，就什么都不处理，接着往这个伫列传送讯息。假设大部分繁重任务的伫列都建立在同一个broker上，那么这个broker的负载就会过大。
可以在上线前预先建立伫列，无需宣告要传送的伫列，但是传送时不会尝试建立伫列，可能出现找不到伫列的问题，RabbitMQ的备份交换器会把找不到伫列的讯息储存到一个专门的伫列中，以便以后查询使用。
使用映象伫列机制建立RabbitMQ丛集可以解决这个问题，形成master-slave的架构，master节点会均匀分布在不同的服务器上，让每一台服务器分摊负载。slave节点只是负责转发，在master失效时会选择加入时间最长的slave成为master。
当新节点加入映象伫列的时候，伫列中的讯息不会同步到新的slave中，除非呼叫同步命令，但是呼叫命令后，伫列会阻塞，不能在生产环境中呼叫同步命令。
2）当RabbitMQ伫列拥有多个消费者的时候，伫列收到的讯息将以轮询的分发方式传送给消费者。每条讯息只会传送给订阅列表里的一个消费者，不会重复。
这种方式非常适合扩充套件，而且是专门为并发程式设计的。
如果某些消费者的任务比较繁重，那么可以设定basicQos限制通道上消费者能保持的最大未确认讯息的数量，在达到上限时，RabbitMQ不再向这个消费者传送任何讯息。
3）对于RabbitMQ而言，客户端与丛集建立的TCP连线不是与丛集中所有的节点建立连线，而是挑选其中一个节点建立连线。
但是RabbitMQ丛集可以借助HAProxy、LVS技术，或者在客户端使用算法实现负载均衡，引入负载均衡之后，各个客户端的连线可以分摊到丛集的各个节点之中。
客户端均衡算法：
a. 轮询法：按顺序返回下一个服务器的连线地址。
b. 加权轮询法：给配置高、负载低的机器配置更高的权重，让其处理更多的请求；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载。
c. 随机法：随机选取一个服务器的连线地址。
d. 加权随机法：按照概率随机选取连线地址。
e. 源地址杂凑法：通过杂凑函式计算得到的一个数值，用该数值对服务器列表的大小进行取模运算。
f. 最小连线数法：动态选择当前连线数最少的一台服务器的连线地址。
8.3 ZeroMQ
去中心化，不支援负载均衡。本身只是一个多执行绪网络库。
8.4 RocketMQ
支援负载均衡。
一个broker通常是一个服务器节点，broker分为master和slave，master和slave储存的资料一样，slave从master同步资料。
1）nameserver与每个丛集成员保持心跳，储存着Topic-Broker路由资讯，同一个topic的伫列会分布在不同的服务器上。
2）传送讯息通过轮询伫列的方式传送，每个伫列接收平均的讯息量。传送讯息指定topic、tags、keys，无法指定投递到哪个伫列（没有意义，丛集消费和广播消费跟讯息存放在哪个伫列没有关系）。
tags选填，类似于 Gmail 为每封邮件设定的标签，方便服务器过滤使用。目前只支 持每个讯息设定一个 tag，所以也可以类比为 Notify 的 MessageType 概念。
keys选填，代表这条讯息的业务关键词，服务器会根据 keys 建立杂凑索引，设定后， 可以在 Console 系统根据 Topic、Keys 来查询讯息，由于是杂凑索引，请尽可能 保证 key 唯一，例如订单号，商品 Id 等。
3）RocketMQ的负载均衡策略规定：
Consumer数量应该小于等于Queue数量，如果Consumer超过Queue数量，那么多余的Consumer 将不能消费讯息。
这一点和Kafka是一致的，RocketMQ会尽可能地为每一个Consumer分配相同数量的伫列，分摊负载。
8.5 ActiveMQ
支援负载均衡。可以基于zookeeper实现负载均衡。
9、维度7：丛集方式
1）Kafka：天然的‘Leader-Slave’无状态丛集，每台服务器既是Master也是Slave。
分割槽首领均匀地分布在不同的Kafka服务器上，分割槽副本也均匀地分布在不同的Kafka服务器上，所以每一台Kafka服务器既含有分割槽首领，同时又含有分割槽副本。
每一台Kafka服务器是某一台Kafka服务器的Slave，同时也是某一台Kafka服务器的leader。
Kafka的丛集依赖于zookeeper，zookeeper支援热扩充套件，所有的broker、消费者、分割槽都可以动态加入移除，而无需关闭服务，与不依靠zookeeper丛集的mq相比，这是最大的优势。
2）RabbitMQ：
支援简单丛集，'复制'模式，对高阶丛集模式支援不好。
RabbitMQ的每一个节点，不管是单一节点系统或者是丛集中的一部分，要么是内存节点，要么是磁盘节点，丛集中至少要有一个是磁盘节点。
在RabbitMQ丛集中建立伫列，丛集只会在单个节点建立伫列程序和完整的伫列资讯（元资料、状态、内容），而不是在所有节点上建立。
引入映象伫列，可以避免单点故障，确保服务的可用性，但是需要人为地为某些重要的伫列配置映象。
3）ZeroMQ：
去中心化，不支援丛集。
4）RocketMQ：
常用 多对'Master-Slave' 模式，开源版本需手动切换Slave变成Master。
Name Server是一个几乎无状态节点，可丛集部署，节点之间无任何资讯同步。
Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。
Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。
Master也可以部署多个。每个Broker与Name Server丛集中的所有节点建立长连线，定时注册Topic资讯到所有Name Server。
Producer与Name Server丛集中的其中一个节点（随机选择）建立长连线，定期从Name Server取Topic路由资讯，并向提供Topic服务的Master建立长连线，且定时向Master传送心跳。Producer完全无状态，可丛集部署。
Consumer与Name Server丛集中的其中一个节点（随机选择）建立长连线，定期从Name Server取Topic路由资讯，并向提供Topic服务的Master、Slave建立长连线，且定时向Master、Slave传送心跳。
Consumer既可以从Master订阅讯息，也可以从Slave订阅讯息，订阅规则由Broker配置决定。
客户端先找到NameServer, 然后通过NameServer再找到 Broker。
一个topic有多个伫列，这些伫列会均匀地分布在不同的broker服务器上。RocketMQ伫列的概念和Kafka的分割槽概念是基本一致的，Kafka同一个topic的分割槽尽可能地分布在不同的broker上，分割槽副本也会分布在不同的broker上。
RocketMQ丛集的slave会从master拉取资料备份，master分布在不同的broker上。
5）ActiveMQ：
支援简单丛集模式，比如'主-备'，对高阶丛集模式支援不好。
10、维度8：管理界面
1）Kafka：一般2）RabbitMQ：好
3）ZeroMQ：无
4）RocketMQ：有管理后台, 但不是专案里自带, 需要自己启动一个单独的管理后台例项
5）ActiveMQ：一般
11、维度9：可用性
1）Kafka：非常高（分散式）2）RabbitMQ：高（主从）
3）ZeroMQ：高
4）RocketMQ：非常高（分散式）
5）ActiveMQ：高（主从）
12、维度10：讯息重复
1）Kafka：支援at least once、at most once2）RabbitMQ：支援at least once、at most once
3）ZeroMQ：只有重传机制，但是没有持久化，讯息丢了重传也没有用。既不是at least once、也不是at most once、更不是exactly only once
4）RocketMQ：支援at least once
5）ActiveMQ：支援at least once
13、维度11：吞吐量TPS
1）Kafka：极大。Kafka按批次传送讯息和消费讯息。传送端将多个小讯息合并，批量发向Broker，消费端每次取出一个批次的讯息批量处理。2）RabbitMQ：比较大
3）ZeroMQ：极大
4）RocketMQ：大。RocketMQ接收端可以批量消费讯息，可以配置每次消费的讯息数，但是传送端不是批量传送。
5）ActiveMQ：比较大
14、维度12：订阅形式和讯息分发
14.1 Kafka基于topic以及按照topic进行正则匹配的释出订阅模式。
1）传送：
传送端由topic和key来决定讯息发往哪个分割槽，如果key为null，那么会使用轮询算法将讯息均衡地传送到同一个topic的不同分割槽中。如果key不为null，那么会根据key的hashcode取模计算出要发往的分割槽。
2）接收：
consumer向群组协调器broker传送心跳来维持他们和群组的从属关系以及他们对分割槽的所有权关系，所有权关系一旦被分配就不会改变除非发生再均衡(比如有一个consumer加入或者离开consumer group)，consumer只会从对应的分割槽读取讯息。
Kafka限制consumer个数要少于分割槽个数,每个讯息只会被同一个 Consumer Group的一个consumer消费（非广播）。
Kafka的 Consumer Group订阅同一个topic，会尽可能地使得每一个consumer分配到相同数量的分割槽，不同 Consumer Group订阅同一个主题相互独立，同一个讯息会被不同的 Consumer Group处理。
14.2 RabbitMQ
提供了4种：direct、topic、Headers和fanout。
1）传送：
先要宣告一个伫列，这个伫列会被建立或者已经被建立，伫列是基本储存单元。
由exchange和key决定讯息储存在哪个伫列。
direct>传送到和bindingKey完全匹配的伫列。
topic>路由key是含有"."的字串，会发送到含有“*”、“#”进行模糊匹配的bingKey对应的伫列。
fanout>与key无关，会发送到所有和exchange系结的伫列
headers>与key无关，讯息内容的headers属性（一个键值对）和系结键值对完全匹配时，会发送到此伫列。此方式效能低一般不用
2）接收：
RabbitMQ的伫列是基本储存单元，不再被分割槽或者分片，对于我们已经建立了的伫列，消费端要指定从哪一个伫列接收讯息。
当RabbitMQ伫列拥有多个消费者的时候，伫列收到的讯息将以轮询的分发方式传送给消费者。每条讯息只会传送给订阅列表里的一个消费者，不会重复。
这种方式非常适合扩充套件，而且是专门为并发程式设计的。
如果某些消费者的任务比较繁重，那么可以设定basicQos限制通道上消费者能保持的最大未确认讯息的数量，在达到上限时，RabbitMQ不再向这个消费者传送任何讯息。
14.3 ZeroMQ
点对点(p2p)。
14.4 RocketMQ
基于topic/messageTag以及按照讯息型别、属性进行正则匹配的释出订阅模式。
1）传送：
传送讯息通过轮询伫列的方式传送，每个伫列接收平均的讯息量。传送讯息指定topic、tags、keys，无法指定投递到哪个伫列（没有意义，丛集消费和广播消费跟讯息存放在哪个伫列没有关系）。
tags选填，类似于 Gmail 为每封邮件设定的标签，方便服务器过滤使用。目前只支 持每个讯息设定一个 tag，所以也可以类比为 Notify 的 MessageType 概念。
keys选填，代表这条讯息的业务关键词，服务器会根据 keys 建立杂凑索引，设定后， 可以在 Console 系统根据 Topic、Keys 来查询讯息，由于是杂凑索引，请尽可能 保证 key 唯一，例如订单号，商品 Id 等。
2）接收：
广播消费。一条讯息被多个Consumer消费，即使Consumer属于同一个ConsumerGroup，讯息也会被ConsumerGroup中的每个Consumer都消费一次。
丛集消费。一个 Consumer Group中的Consumer例项平均分摊消费讯息。例如某个Topic有 9 条讯息，其中一个Consumer Group有3个例项，那么每个例项只消费其中的 3 条讯息。即每一个伫列都把讯息轮流分发给每个consumer。
14.5 ActiveMQ
点对点(p2p)、广播（释出-订阅）。
点对点模式，每个讯息只有1个消费者；释出/订阅模式，每个讯息可以有多个消费者。
1）传送：
点对点模式：先要指定一个伫列，这个伫列会被建立或者已经被建立。
释出/订阅模式：先要指定一个topic，这个topic会被建立或者已经被建立。
2）接收：
点对点模式：对于已经建立了的伫列，消费端要指定从哪一个伫列接收讯息。
释出/订阅模式：对于已经建立了的topic，消费端要指定订阅哪一个topic的讯息。
15、维度13：顺序讯息
Kafka：支援。设定生产者的max.in.flight.requests.per.connection为1，可以保证讯息是按照发送顺序写入服务器的，即使发生了重试。
Kafka保证同一个分割槽里的讯息是有序的，但是这种有序分两种情况：
①key为null，讯息逐个被写入不同主机的分割槽中，但是对于每个分割槽依然是有序的
②key不为null , 讯息被写入到同一个分割槽，这个分割槽的讯息都是有序。
RabbitMQ：不支援
ZeroMQ：不支援
RocketMQ：支援
ActiveMQ：不支援
16、维度14：讯息确认
16.1 Kafka支援。
1）传送方确认机制：
ack=0，不管讯息是否成功写入分割槽
ack=1，讯息成功写入首领分割槽后，返回成功
ack=all，讯息成功写入所有分割槽后，返回成功。
2）接收方确认机制：
自动或者手动提交分割槽偏移量，早期版本的Kafka偏移量是提交给Zookeeper的，这样使得zookeeper的压力比较大，更新版本的Kafka的偏移量是提交给Kafka服务器的，不再依赖于zookeeper群组，丛集的效能更加稳定。
16.2 RabbitMQ
支援。
1）传送方确认机制，讯息被投递到所有匹配的伫列后，返回成功。如果讯息和伫列是可持久化的，那么在写入磁盘后，返回成功。支援批量确认和异步确认。
2）接收方确认机制，设定autoAck为false，需要显式确认，设定autoAck为true，自动确认。
当autoAck为false的时候，RabbitMQ伫列会分成两部分，一部分是等待投递给consumer的讯息，一部分是已经投递但是没收到确认的讯息。
如果一直没有收到确认讯号，并且consumer已经断开连线，RabbitMQ会安排这个讯息重新进入伫列，投递给原来的消费者或者下一个消费者。
未确认的讯息不会有过期时间，如果一直没有确认，并且没有断开连线，RabbitMQ会一直等待，RabbitMQ允许一条讯息处理的时间可以很久很久。
16.3 ZeroMQ
支援。
16.4 RocketMQ
支援。
16.5 ActiveMQ
支援。
17、维度15：讯息回溯
1）Kafka：支援指定分割槽offset位置的回溯2）RabbitMQ：不支援
3）ZeroMQ：不支援
4）RocketMQ：支援指定时间点的回溯
5）ActiveMQ：不支援
18、维度16：讯息重试
18.1 Kafka不支援，但是可以实现。
Kafka支援指定分割槽offset位置的回溯，可以实现讯息重试。
18.2 RabbitMQ
不支援，但是可以利用讯息确认机制实现。
RabbitMQ接收方确认机制，设定autoAck为false。
当autoAck为false的时候，RabbitMQ伫列会分成两部分，一部分是等待投递给consumer的讯息，一部分是已经投递但是没收到确认的讯息。
如果一直没有收到确认讯号，并且consumer已经断开连线，RabbitMQ会安排这个讯息重新进入伫列，投递给原来的消费者或者下一个消费者。
18.3 ZeroMQ
不支援。
18.4 RocketMQ
支援。
讯息消费失败的大部分场景下，立即重试99%都会失败，所以RocketMQ的策略是在消费失败时定时重试，每次时间间隔相同。
1）传送端的 send 方法本身支援内部重试，重试逻辑如下：
至多重试3次；
如果传送失败，则轮转到下一个broker；
这个方法的总耗时不超过sendMsgTimeout 设定的值，预设 10s，超过时间不在重试。
2）接收端：
Consumer 消费讯息失败后，要提供一种重试机制，令讯息再消费一次。Consumer 消费讯息失败通常可以分为以下两种情况：
由于讯息本身的原因，例如反序列化失败，讯息资料本身无法处理（例如话费充值，当前讯息的手机号被登出，无法充值）等。定时重试机制，比如过 10s 秒后再重试。
由于依赖的下游应用服务不可用，例如 db 连线不可用，外系统网络不可达等。即使跳过当前失败的讯息，消费其他讯息同样也会报错。这种情况可以 sleep 30s，再消费下一条讯息，减轻 Broker 重试讯息的压力。
18.5 ActiveMQ
不支援。
19、维度17：并发度
19.1 Kafka并发度高。
一个执行绪一个消费者，Kafka限制消费者的个数要小于等于分割槽数，如果要提高并行度，可以在消费者中再开启多执行绪，或者增加consumer例项数量。
19.2 RabbitMQ
并发度极高。本身是用Erlang语言写的，并发效能高。
可在消费者中开启多执行绪，最常用的做法是一个channel对应一个消费者，每一个执行绪把持一个channel，多个执行绪复用connection的tcp连线，减少效能开销。
当RabbitMQ伫列拥有多个消费者的时候，伫列收到的讯息将以轮询的分发方式传送给消费者。每条讯息只会传送给订阅列表里的一个消费者，不会重复。
这种方式非常适合扩充套件，而且是专门为并发程式设计的。
如果某些消费者的任务比较繁重，那么可以设定basicQos限制通道上消费者能保持的最大未确认讯息的数量，在达到上限时，RabbitMQ不再向这个消费者传送任何讯息。
19.3 ZeroMQ
并发度高。
19.4 RocketMQ
并发度高。
1）RocketMQ限制消费者的个数少于等于伫列数，但是可以在消费者中再开启多执行绪，这一点和Kafka是一致的，提高并行度的方法相同。
修改消费并行度方法：
同一个 ConsumerGroup 下，通过增加 Consumer 例项数量来提高并行度，超过订阅伫列数的 Consumer例项无效。
提高单个 Consumer 的消费并行执行绪，通过修改引数consumeThreadMin、consumeThreadMax
2）同一个网络连线connection，客户端多个执行绪可以同时传送请求，连线会被复用，减少效能开销。
19.5 ActiveMQ
并发度高。
单个ActiveMQ的接收和消费讯息的速度在1万笔/秒（持久化 一般为1-2万， 非持久化 2 万以上），在生产环境中部署10个ActiveMQ就能达到10万笔/秒以上的效能，部署越多的ActiveMQ broker 在MQ上latency也就越低，系统吞吐量也就越高。
附录：更多架构设计方面的文章
[1] 有关IM架构设计的文章：《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通讯协议和客户端》
《一套海量线上使用者的移动端IM架构设计实践分享(含详细图文)》
《一套原创分散式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿线上使用者的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量资料冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群讯息的推送如何保证效率、实时性？》
《现代IM系统中聊天讯息的同步和储存方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片档案的服务端储存架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连线中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿使用者量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ讯息中介软件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分散式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高效能HTTP服务端的负载均衡技术原理》
《子弹简讯光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高效能快取实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ讯息伫列》
《微信技术分享：微信的海量IM聊天讯息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天讯息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分散式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的储存层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分散式MQ讯息伫列，妈妈再也不担心我的技术选型了》
>> 更多同类文章 ……
[2] 更多其它架构设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分散式系统设计的方方面面》
《快速理解高效能HTTP服务端的负载均衡技术原理》
《子弹简讯光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高效能快取实践之路》
《新手入门：零基础理解大型分散式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分散式架构下的负载均衡技术：分类、原理、算法、常见方案等》
《通俗易懂：如何设计能支撑百万并发的数据库架构？》
《多维度对比5款主流分散式MQ讯息伫列，妈妈再也不担心我的技术选型了》
>> 更多同类文章 ……
（本文同步释出于：http://www.52im.net/thread-2625-1-1.html）
