是个消息中间件吗?那和市面上其他一堆堆的中间件例如ActiveMQ, RabbitMQ有什么区别?
答案只有一个:
Kafka是个集群的消息中间件+存储,一个节点可以存储几T的数据!
为啥一个中间件需要存储数据呢?
原来,对于Linkin这样的互联网企业来说,用户和网站上产生的数据有三种:
Linkin的牛逼之处,就在于他们发现了原先2,3的数据处理方式有问题,对于2而言,原来动辄一两个钟头批处理一次的方式已经不行了,用户在一次购买完之后最好马上就能看到相关的推荐。而对于3而言,传统的syslog模式等也不好用,而且很多情况下2和3用的是同一批数据,只是数据消费者不一样。
这2种数据的特点是:
于是,Linkin就自己开发了一套系统,专门用来处理这种性质的数据,这就是Kafka
那么,在整个实践过程中Linkin做了什么样的设计,解决了什么问题?
首先看下数据流动图:
多数据中心怎么管理数据:
集群本身的架构图
Kafka内部架构图,分为数据产生者(Producer),数据中间者(Broker),数据消费者(Consumer)
显然,这是一个集群的发布/订阅系统,有如下几个特点
所以,Kafka的设计基本上目前这个领域的唯一选择。我也看了很多其他实现,包括:
scribe(Facebook) | 2 | C++ | 已停止更新,不建议使用
flume(Apache, Cloudera) |1 | Java | 配置较重
chukwa(Hadoop) |12 | Java | 2012发布最后一版,不建议使用
fluentd |1 | Ruby | 比较活跃,看起来不错
logstash |12345| JRuby | 功能全,据说有不少小bug
splunk |12345| C/Python | 商业闭源,功能强大,可做参考
timetunnel(Alibaba) | 2 | Java | 基于thrift,10年左右成熟
kafka(Linkin) | 2 4 | Scala | 性能强劲,设计巧妙,可以作为基础设施
Samza(Linkin) |12345| | =Kafka+YARN+Hadoop
rabbitmq/activemq/qpid | 2 | Java | 传统消息中间件
Storm(twitter) | 3 | Clojure | 实时计算系统
Jstorm(Alibaba) | 3 | Java | storm的Java版,据说更稳定
S4(Yahoo) | 3 | Java | 2013年已停止维护
Streambase(IBM) | 3 | Java | 商业产品,作为参考
HStreaming | 3 | Java | 商业产品,作为参考
spark | 3 | Scala | 基于Hadoop
mongodb | 4 | C++ | 比较浪费硬盘
mysql | 4 | C++ | 无需多说
hdfs/hbase | 4 | Java | 无需多说=
从数据传输这块的设计理念来说,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 实时系统搭建》