RabbitMq、ActiveMq、ZeroMq、kafka之间的比较,资料汇总 - 博客频道 - CSDN.NET
Sam哥哥的博客
互联网技术爱好者
（100617）
MQ框架非常之多，比较流行的有RabbitMq、ActiveMq、ZeroMq、kafka。这几种MQ到底应该选择哪个？要根据自己项目的业务场景和需求。下面我列出这些MQ之间的对比数据和资料。
第一部分：RabbitMQ,ActiveMq,ZeroMq比较
1、 TPS比较 一
ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。这个结论来自于以下这篇文章。
测试环境：
&&&&&Model: Dell Studio 1749
& & &CPU: Intel Core i3 @ 2.40 GHz
& & &RAM: 4 Gb
& & &OS: Windows 7 64 bits
其中包括持久化消息和瞬时消息的测试。注意这篇文章里面提到的MQ，都是采用默认配置的，并无调优。
更多的统计图请参看我提供的文章url。
2、TPS比较二
ZeroMq 最好，RabbitMq次之，
ActiveMq最差。这个结论来自于一下这篇文章。&
显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。
3、持久化消息比较
& & &&zeroMq不支持，activeMq和rabbitMq都支持。持久化消息主要是指：MQ
down或者MQ所在的服务器down了，消息不会丢失的机制。
4、技术点：可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区
& & & RabbitMq最好，ActiveMq次之，ZeroMq最差。当然ZeroMq也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
&&&&& 所以在可靠性和可用性上，RabbitMQ是首选，虽然ActiveMQ也具备，但是它性能不及RabbitMQ。
&5、高并发
从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的erlang语言。
按照目前网络上的资料，RabbitMQ、activeM、zeroMQ三者中，综合来看，RabbitMQ是首选。下面提供一篇文章，是淘宝使用RabbitMQ的心得，可以参看一些业务场景。
第二部分：kafka和RabbitMQ的比较
关于这两种MQ的比较，网上的资料并不多，最权威的的是kafka的提交者写一篇文章。
里面提到的要点：
1、& RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka
2、& Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性
3、& Kafka的性能（吞吐量、tps）比RabbitMq要强，这篇文章的作者认为，两者在这方面没有可比性。
这里在附上两篇文章，也是关于kafka和RabbitMq之间的比较的：
1、/?p=139
2、/post/227
两者对比后，我仍然是选择RabbitMq，性能其实是很强劲的，同时具备了一个成熟的MQ应该具有的特性，我们无需重新发明轮子。
好资料推荐：
& & & & & & 1、最全最给力的kafka博客：http://blog.csdn.net/lizhitao/article/category/2194509
& & & & & &2、淘宝对rabbitmq的使用：/p-.html
linsongbin1
排名：第13038名
（39）（45）（4）（8）（4）（3）（4）（4）（5）（4）（2）（5）（1）（0）（1）
（100614）上一期我们对比了三类消息产品(Kafka、RabbitMQ、RocketMQ)单纯发送小消息的性能，受到了程序猿们的广泛关注，其中大家对这种单纯的发送场景感到并不过瘾，因为没有任何一个网站的业务只有发送消息。
上一期我们对比了三类消息产品(Kafka、RabbitMQ、RocketMQ)单纯发送小消息的性能，受到了程序猿们的广泛关注，其中大家对这种单纯的发送场景感到并不过瘾，因为没有任何一个网站的业务只有发送消息。本期，我们就来模拟一个真实的场景：
鉴于上一期Kafka和RocketMQ的指标和关注度很高，本期我们将只针对这两个产品，对比在上述场景中，究竟谁更胜一筹。在正式开始测试之前，首先要向大家明确2个概念：
Topic为何物
Topic是消息中间件里一个重要的概念，每一个Topic代表了一类消息，有了多个Topic，就可以对消息进行归类与隔离。
可以参照下图的动物园喂食模型，每一种动物都只能消费相对应的食品。
分区为何物
Kafka和RocketMQ都是磁盘消息队列的模式，对于同一个消费组，一个分区只支持一个消费线程来消费消息。过少的分区，会导致消费速度大大落后于消息的生产速度。所以在实际生产环境中，一个Topic会设置成多分区的模式，来支持多个消费者，参照下图：
在互联网企业的实际生产环境中，Topic数量和分区都会比较多，这就要求消息中间件在多Topic共存的时候，依然能够保证服务的稳定性。下面就进入测试环节，看看消息发送端，订阅端共存时，Kafka和RocketMQ对多Topic的处理能力。
对比发送端、接收端共存情况下，Topic数量对Kafka、RocketMQ的性能影响，分区数采用8个分区。这次压测我们只关注服务端的性能指标，所以压测的退出标准是:
不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。此时服务端出现性能瓶颈，获取相应的系统最佳吞吐量，整个过程中保证消息没有累积。
默认每个Topic的分区数为8，每个Topic对应一个订阅者，逐步增加Topic数量。得到如下数据：
发送端并发数
发送端RT（ms）
可以看到，不论Topic数量是多少，Kafka和RocketMQ均能保证发送端和消费端的TPS持平，就是说，保证了消息没有累积。
根据Topic数量的变化，画出二者的消息处理能力的对比曲线如下图：
从图上可以看出：
Kafka在Topic数量由64增长到256时，吞吐量下降了98.37%。
RocketMQ在Topic数量由64增长到256时，吞吐量只下降了16%。
为什么两个产品的表现如此悬殊呢？这是因为Kafka的每个Topic、每个分区都会对应一个物理文件。当Topic数量增加时，消息分散的落盘策略会导致磁盘IO竞争激烈成为瓶颈。而RocketMQ所有的消息是保存在同一个物理文件中的，Topic和分区数对RocketMQ也只是逻辑概念上的划分，所以Topic数的增加对RocketMQ的性能不会造成太大的影响。
在消息发送端，消费端共存的场景下，随着Topic数的增加Kafka吞吐量会急剧下降，而RocketMQ则表现稳定。因此Kafka适合Topic和消费端都比较少的业务场景，而RocketMQ更适合多Topic，多消费端的业务场景。
服务端为单机部署，机器配置如下：
Seagate Constellation ES (SATA 6Gb/s) 2,000,398,934,016 bytes [2.00 TB] 7202 rpm
应用版本：
消息中间件
Jmeter的java客户端
能达到服务端最大TPS的最优并发
Topic分区数量
经过上面的测试，RocketMQ几乎是完胜Kafka，其实这并不奇怪，因为RocketMQ就是针对互联网的生产要求孕育而生的，读者现在也应该明白为什么RocketMQ可以支撑阿里集团的海量消息业务了吧。
本期测试暂时告一段落了，测试中涉及到的多Topic场景，其实压测时间均只有20分钟，对于一个消息中间件产品来说，过短的执行时间是无法判断它们的稳定性的。下一期我们会继续探索多分区场景下，Kafka和RocketMQ对外服务的稳定性。敬请期待后续的比拼！
用云栖社区APP，舒服~
【云栖快讯】首届阿里巴巴中间件技术峰会，揭秘阿里10年分布式技术沉淀！阿里高可用体系核心缔造者、全链路压测创始人，DRDS与TDDL负责人等大咖出场，干货分享，不可错过！&&
一款阿里巴巴自主研发的高性能、分布式的关系型数据库，支持完整的ACID特性。它高度兼容MySQL协议与语法，让用...
消息队列（Message Queue，简称MQ）是阿里云商用的专业消息中间件，是企业级互联网架构的核心产品，基于...
阿里云移动APP解决方案，助力开发者轻松应对移动app中随时可能出现的用户数量的爆发式增长、复杂的移动安全挑战等...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
2017杭州云栖大会火热抢票
Loading...后使用快捷导航没有帐号？
Kafka是如何实现高吞吐率的
查看: 22231|
评论: 0|原作者: 杜亦舒|来自: 性能架构
摘要: Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失kafka主要使用了以下几个方式实现了超高 ...
Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失kafka主要使用了以下几个方式实现了超高的吞吐率顺序读写kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写Kafka官方给出了测试数据(Raid-5，7200rpm)：顺序 I/O: 600MB/s随机 I/O: 100KB/s零拷贝先简单了解下文件系统的操作流程，例如一个程序要把文件内容发送到网络这个程序是工作在用户空间，文件和网络socket属于硬件资源，两者之间有一个内核空间在操作系统内部，整个过程为：在 kernel2.2 之后出现了一种叫做"零拷贝(zero-copy)"系统调用机制，就是跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”系统上下文切换减少为2次，可以提升一倍的性能文件分段kafka的队列topic被分为了多个区partition，每个partition又分为多个段segment，所以一个队列中的消息实际上是保存在N多个片段文件中通过分段的方式，每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力批量发送Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去比如可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去如100条消息就发送，或者每5秒发送一次这种策略将大大减少服务端的I/O次数数据压缩Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩压缩的好处就是减少传输的数据量，减轻对网络传输的压力Producer压缩之后，在Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是CPU，所以这个成本很值得欢迎加入本站公开兴趣群软件开发技术群兴趣范围包括：，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流QQ群：源代码研究群兴趣范围包括：Hadoop源代码解读，改进，优化，场景定制，与Hadoop有关的各种开源项目，总之就是玩转HadoopQQ群：&
上一篇：下一篇：kafka中处理超大消息的一些考虑
时间： 00:38:26
&&&& 阅读：8424
&&&& 评论：
&&&& 收藏：0
标签：Kafka设计的初衷是迅速处理短小的消息，一般10K大小的消息吞吐性能最好（可参见LinkedIn的kafka性能测试）。但有时候，我们需要处理更大的消息，比如XML文档或JSON内容，一个消息差不多有10-100M，这种情况下，Kakfa应该如何处理？针对这个问题，有以下几个建议：& 最好的方法是不直接传送这些大的数据。如果有共享存储，如NAS, HDFS, S3等，可以把这些大的文件存放到共享存储，然后使用Kafka来传送文件的位置信息。& 第二个方法是，将大的消息数据切片或切块，在生产端将数据切片为10K大小，使用分区主键确保一个大消息的所有部分会被发送到同一个kafka分区（这样每一部分的拆分顺序得以保留），如此以来，当消费端使用时会将这些部分重新还原为原始的消息。& 第三，Kafka的生产端可以压缩消息，如果原始消息是XML，当通过压缩之后，消息可能会变得不那么大。在生产端的配置参数中使用compression.codec和commpressed.topics可以开启压缩功能，压缩算法可以使用GZip或Snappy。& & 不过如果上述方法都不是你需要的，而你最终还是希望传送大的消息，那么，则可以在kafka中设置下面一些参数：broker 配置:&&& message.max.bytes (默认:1000000) – broker能接收消息的最大字节数，这个值应该比消费端的fetch.message.max.bytes更小才对，否则broker就会因为消费端无法使用这个消息而挂起。&&& log.segment.bytes (默认: 1GB) – kafka数据文件的大小，确保这个数值大于一个消息的长度。一般说来使用默认值即可（一般一个消息很难大于1G，因为这是一个消息系统，而不是文件系统）。&&& replica.fetch.max.bytes (默认: 1MB) – broker可复制的消息的最大字节数。这个值应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去，从而造成数据丢失。Consumer 配置:&fetch.message.max.bytes (默认 1MB) – 消费者能读取的最大消息。这个值应该大于或等于message.max.bytes。所以，如果你一定要选择kafka来传送大的消息，还有些事项需要考虑。要传送大的消息，不是当出现问题之后再来考虑如何解决，而是在一开始设计的时候，就要考虑到大消息对集群和主题的影响。性能: 根据前面提到的性能测试，kafka在消息为10K时吞吐量达到最大，更大的消息会降低吞吐量，在设计集群的容量时，尤其要考虑这点。可用的内存和分区数：Brokers会为每个分区分配replica.fetch.max.bytes参数指定的内存空间，假设replica.fetch.max.bytes=1M，且有1000个分区，则需要差不多1G的内存，确保 分区数*最大的消息不会超过服务器的内存，否则会报OOM错误。同样地，消费端的fetch.message.max.bytes指定了最大消息需要的内存空间，同样，分区数*最大需要内存空间 不能超过服务器的内存。所以，如果你有大的消息要传送，则在内存一定的情况下，只能使用较少的分区数或者使用更大内存的服务器。垃圾回收：到现在为止，我在kafka的使用中还没发现过此问题，但这应该是一个需要考虑的潜在问题。更大的消息会让GC的时间更长（因为broker需要分配更大的块），随时关注GC的日志和服务器的日志信息。如果长时间的GC导致kafka丢失了zookeeper的会话，则需要配置zookeeper.session.timeout.ms参数为更大的超时时间。一切的一切，都需要在权衡利弊之后，再决定选用哪个最合适的方案。标签：
&&国之画&&&& &&&&chrome插件
版权所有 京ICP备号-2
迷上了代码！}