测试环境:ubuntu 15.10 64位 cpu:inter core i7-4790 3.60GHZ * 8 内存:16GB 硬盘:ssd 120GB 软件环境:rabbmitmq 3.6.0   kafka0.8.1  (均为单机本机运行) PS: 测试结果均为单操作测试,即生产的时候没有消费操作 测试结果: kafka :消费速度: 37,586 /s  生产速度: 448,753 /s rabbitmq: 消费速度: 20,807 /s  生产速度  16.413 /s 出现问题: r…

转自通九大神的博客 起因 最近公司RabbitMQ的集群出了点问题,然后有些亲就说RabbitMQ慢且不好用,是一个瓶颈,不如换成Kafka.而我本人,使用RabbitMQ有一点久了,认为这个事情应当辩证的去看.所以就在没事的时候简单的看了看RabbitMQ的代码.但是我并没有看太多Kafka的代码,我只简单提下. 关于Kafka 根据Kafka官方的文档,Kafka可以被认为一个高大上的集群消息中间件,但是读了下以前一个朋友给的部署文档和Kafka的官方的文档.发现Kafka确实不错,真的可以…

============================RabbitMQ 术语============================RabbitMQ 有很多术语和Kafka不一样, 理解这些术语十分重要. 1. Broker: 一个RabbitMQ实例就是一个 Broker. 2. VHost(Virtual Host): 一个RabbitMQ实例可包含多个VHost, 每个VHost都有自己的身份验证机制. 在一个VHost中包含多个exchange和队列和binding. 每个Rabbit…

前言 这几天在写 shell 脚本,学到不少,但是没啥心得之类的,有空可以写个总结(但是大概率不会发表) 现在不算很忙,想再学一点 消息队列相关知识 目前比较出名的也就 RabbitMQ 和 Kafka 网上说 Kafka I/O更快,但是会丢数据 RabbitMQ更可靠一点 但性能我觉得还是比较重要的,可靠性可以通过别的方式来加强.性能可不是硬件多就能简单堆起来的 变更记录 # 19.4.29  起笔 正文 pass…

这是一篇分享文 转自:http://www.cnblogs.com/williamjie/p/9481780.html  尊重原作,谢谢 消息队列 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A,工作于传统软件行业(某社保局的软件外包公司),每天工作内容就是和产品聊聊需求,改改业务逻辑.再不然就是和运营聊聊天,写几个SQL,生成下报表.又或者接到客服的通知,某某功能故障了,改改数据,然后下班部署上线.每天过的都是这种生活,技术零成长. 小B,工作于某国企,虽然能接触到一些中间件技术.…

我目前的项目最后使用的是RabbitMQ,这里依然是结合网上大神们的优秀博客,对kafka和rabbitmq进行简单的比对.最后附上参考博客. 1.架构模型 rabbitmq RabbitMQ遵循AMQP协议,RabbitMQ的broker由Exchange,Binding,queue组成,其中exchange和binding组成了消息的路由键:客户端Producer通过连接channel和server进行通信,Consumer从queue获取消息进行消费(长连接,queue有消息会推送到con…

MQ框架非常之多,今天简单说一下有代表性的两个MQ(rabbitmq和kafka).经常会有人问rabbitmq和kafka到底哪个好呢?其实没有好与不好之分,只有哪个更合适,首先要根据自己项目的业务场景和需求来选择更合适的一个MQ. 在应用场景方面 rabbitmq遵循AMQP协议,由内在高并发的erlanng语言开发,用在实时的对可靠性要求比较高的消息传递上. kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上. 在架构…

最近研究消息队列,发现好几个框架,搜罗一下进行对比,说一下选型说明: 1)中小型软件公司,建议选RabbitMQ.一方面,erlang语言天生具备高并发的特性,而且他的管理界面用起来十分方便.不考虑rocketmq和kafka的原因是,一方面中小型软件公司不如互联网公司,数据量没那么大,选消息中间件,应首选功能比较完备的,所以kafka排除.RocketMQ也很不错,只是没有RabbitMQ出来的早,文档和网上的资料没有RabbitMQ多,但也是很不错,RocketMQ是阿里出品,现在阿里已经把…

RabbitMQ和Kafka都提供持久的消息保证.两者都提供至少一次和至多一次的保证,另外,Kafka在某些限定情况下可以提供精确的一次(exactly-once)保证. 让我们首先理解一下上述术语的含义: 至多一次投递:消息绝对不会被重复投递,但是消息可能丢失 至少一次投递:消息绝对不会被丢失,但是有可能重复被消费 精确的一次投递:消息系统的圣杯.所有的消息精确的被投递一次. “投递”貌似不是准确的语言描述,“处理”才是.无论怎么描述,我们关心的是,消费者能否处理消息,以及处理的次数.但是使用…

这是一篇分享文 转自:http://www.cnblogs.com/williamjie/p/9481780.html  尊重原作,谢谢 消息队列 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A,工作于传统软件行业(某社保局的软件外包公司),每天工作内容就是和产品聊聊需求,改改业务逻辑.再不然就是和运营聊聊天,写几个SQL,生成下报表.又或者接到客服的通知,某某功能故障了,改改数据,然后下班部署上线.每天过的都是这种生活,技术零成长. 小B,工作于某国企,虽然能接触到一些中间件技术.…