Kafka是个奇葩！——Linkin论文学习笔记
Kafka是个奇葩！——Linkin论文学习笔记
Kafka是啥？
是个消息中间件吗？那和市面上其他一堆堆的中间件例如ActiveMQ, RabbitMQ有什么区别？
答案只有一个：
Kafka是个集群的消息中间件+存储，一个节点可以存储几T的数据！
为啥一个中间件需要存储数据呢？
慢慢道来……
原来，对于Linkin这样的互联网企业来说，用户和网站上产生的数据有三种：
需要实时响应的交易数据，用户提交一个表单，输入一段内容，这种数据最后是存放在关系数据库(Oracle, MySQL)中的，有些需要事务支持。
活动流数据，准实时的，例如页面访问量、用户行为、搜索情况，这些数据可以产生啥？广播、排序、个性化推荐、运营监控等。这种数据一般是前端服务器先写文件，然后通过批量的方式把文件倒到Hadoop这种大数据分析器里面慢慢整。
各个层面程序产生的日志，例如httpd的日志、tomcat的日志、其他各种程序产生的日志。码农专用，这种数据一个是用来监控报警，还有就是用来做分析。
Linkin的牛逼之处，就在于他们发现了原先2,3的数据处理方式有问题，对于2而言，原来动辄一两个钟头批处理一次的方式已经不行了，用户在一次购买完之后最好马上就能看到相关的推荐。而对于3而言，传统的syslog模式等也不好用，而且很多情况下2和3用的是同一批数据，只是数据消费者不一样。
这2种数据的特点是：
准实时，不需要秒级响应，分钟级别即可。
数据量巨大，是交易数据的10倍以上。
数据消费者众多，例如评级、投票、排序、个性化推荐、安全、运营监控、程序监控、后期报表等
于是，Linkin就自己开发了一套系统，专门用来处理这种性质的数据，这就是Kafka
那么，在整个实践过程中Linkin做了什么样的设计，解决了什么问题？
首先看下数据流动图：
多数据中心怎么管理数据：
集群本身的架构图
Kafka内部架构图，分为数据产生者(Producer)，数据中间者(Broker)，数据消费者(Consumer)
显然，这是一个集群的发布/订阅系统，有如下几个特点
生产者是推数据(Push)，消费者是拉数据(Pull)。存在数据复用，在Linkin平均生产1条消息会被消费5.5次。
数据生产者和数据消费者的速度不对等，所以要把数据沉淀在Kafka内慢慢处理，Linkin一般在集群内放7天的数据。
性能上追求高吞吐，保证一定的延时性之内。这方面做了大量优化，包括没有全局hash，批量发送，跨数据中心压缩等等。
容错性上使用的“至少传输一次”的语义。不保证强一次，但避免最多传一次的情况。
集群中数据分区，保证单个数据消费者可以读到某话题(topic)的某子话题(例如某用户的数据)的所有数据，避免全局读数据
数据规范性，所有数据分为数百个话题，然后在数据的源头——生产者(Producer)这边就用Schema来规范数据，这种理念使得后期的数据传输、序列化、压缩、消费都有了统一的规范，同时也解决了这个领域非常麻烦的数据版本不兼容问题——生产者一改代码，消费者就抓瞎。
用于监控，这个系统的威力在于，前面所有生产系统的数据流向，通过这个系统都能关联起来，用于日常的运营也好，用于数据审计，用于运维级别的监控也好都是神器啊！
所以，Kafka的设计基本上目前这个领域的唯一选择。我也看了很多其他实现，包括：
scribe(Facebook)
| 已停止更新，不建议使用
flume(Apache, Cloudera)
| 配置较重
chukwa(Hadoop)
| 2012发布最后一版，不建议使用
| 比较活跃，看起来不错
|12345| JRuby
| 功能全，据说有不少小bug
|12345| C/Python | 商业闭源，功能强大，可做参考
timetunnel(Alibaba)
| 基于thrift，10年左右成熟
kafka(Linkin)
| 2 4 | Scala
| 性能强劲，设计巧妙，可以作为基础设施
Samza(Linkin)
| =Kafka+YARN+Hadoop
rabbitmq/activemq/qpid
| 传统消息中间件
Storm(twitter)
| 实时计算系统
Jstorm(Alibaba)
| storm的Java版，据说更稳定
| 2013年已停止维护
Streambase(IBM)
| 商业产品，作为参考
HStreaming
| 商业产品，作为参考
| 基于Hadoop
| 比较浪费硬盘
| 无需多说
hdfs/hbase
| 无需多说
数据采集组件
数据传输组件
数据实时计算/索引/搜索组件
数据存储/持久化组件
数据展示/查询/报警界面组件
从数据传输这块的设计理念来说，Kafka是最为先进的，
在目前的各种实现中，我猜测可以和Kafka一战的也就只有splunk了
后面我会分析一下这2个软件的设计和实现
欲知后事如何，且听下回分解 ~~
主要参考文章：
日志：每个软件工程师都应该知道的有关实时数据的统一概念 —— 这篇比较抽象，高屋建瓴，理论先行
Building LinkedIn’s Real-time Activity Data Pipeline —— 实践层的论文，把做事情的前因后果都写明白了
分布式发布订阅消息系统 Kafka 架构设计 —— 落地设计
次要参考文章
《Building LinkedIn’s Real-time Activity Data Pipeline》
《分布式发布订阅消息系统 Kafka 架构设计》
《StreamBase简介》
《Yahoo! s4和Twitter storm的粗略比较》
《最火爆的开源流式系统Storm vs 新星Samza》
《架构之淘宝实时数据传输平台: TimeTunnel介绍》
《Graylog2 简介》
《logstash 还是不行》
《日志收集以及分析：Splunk 》
《LogStash日志分析系统》
《LogStash，使日志管理更简单》
《logstash VS splunk》
《个性化离线实时分析系统pora》
《日志：每个软件工程师都应该知道的有关实时数据的统一概念》
《基于Flume的美团日志收集系统(二)改进和优化》
《基于Flume的美团日志收集系统(一)架构和设计》
《对互联网海量数据实时计算的理解》
《流式日志系统启示录》
《flume-ng+Kafka+Storm+HDFS 实时系统搭建》
如果您想提高自己的技术水平，认识同行朋友、开拓技术视野，请加入QQ群：
Powered by
& 2014 &&&联系本站：RabbitMQ、ActiveMQ、ZeroMQ、Kafka之间的比较汇总 - 文章 - 伯乐在线
& RabbitMQ、ActiveMQ、ZeroMQ、Kafka之间的比较汇总
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
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。
从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的erlang语言。
按照目前网络上的资料，RabbitMQ、activeM、zeroMQ三者中，综合来看，RabbitMQ是首选。下面提供一篇文章，是淘宝使用RabbitMQ的心得，可以参看一些业务场景。
第二部分：kafka和RabbitMQ的比较
关于这两种MQ的比较，网上的资料并不多，最权威的的是kafka的提交者写一篇文章。
里面提到的要点：
RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka
Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性
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
打赏支持我写出更多好文章，谢谢！
打赏支持我写出更多好文章，谢谢！
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2016 伯乐在线kafka入门：简介、使用场景、设计原理、主要配置及集群搭建(转) - 李克华 - 推酷_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
kafka入门：简介、使用场景、设计原理、主要配置及集群搭建(转) - 李克华 - 推酷
上传于||暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩9页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢目前业界有很多MQ产品，我们作如下对比：
是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。
号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。
是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、、.Net,、、
Php、 Ruby等。
Jafka/Kafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache
Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：11515次
排名：千里之外
原创：35篇
(7)(2)(1)(9)(20)