在我们大量使用分布式数据库、分布式计算集群的时候,是否会遇到这样的一些问题:
这些场景都有一个共同点: 数据是由上游模块产生,上游模块,使用上游模块的数据计算、统计、分析,这个时候就可以使用消息系统,尤其是分布式消息系统!
知道了我们有必要在数据处理系统中使用一个消息系统,但是我们为什么一定要选kafka呢?现在的消息系统可不只有kafka。
话说阿里中间件团队和LinkedIn团队都做了一个Kafka、RabbitMQ、RocketMQ的三者对比。这边就不献丑了,实际结果可以参考以下两篇博文:
阿里测试:http://jm.taobao.org/2016/04/01/kafka-vs-rabbitmq-vs-rocketmq-message-send-performance/
LinkedIn测试:https://blog.csdn.net/SJF0115/article/details/78480433
Kafka是Linkedin于2010年12月份创建的开源消息系统,它主要用于处理活跃的流式数据。活跃的流式数据在web网站应用中非常常见,这些活动数据包括页面访问量(Page View)、被查看内容方面的信息以及搜索情况等内容。 这些数据通常以日志的形式记录下来,然后每隔一段时间进行一次统计分析。
传统的日志分析系统是一种离线处理日志信息的方式,但若要进行实时处理,通常会有较大延迟。而现有的消息队列系统能够很好的处理实时或者近似实时的应用,但未处理的数据通常不会写到磁盘上,这对于Hadoop之类,间隔时间较长的离线应用而言,在数据安全上会出现问题。Kafka正是为了解决以上问题而设计的,它能够很好地进行离线和在线应用。
消息队列(Message Queue,简称MQ),从字面意思上看,本质是个队列,FIFO先入先出,只不过队列中存放的内容是message而已。其主要用途:不同进程Process/线程Thread之间通信。
对于kafka而言,kafka服务就像是一个大的水池。不断的生产、存储、消费着各种类别的消息。那么kafka由何组成呢?
Broker
: Kafka消息服务器,消息中心。一个Broker可以容纳多个Topic。Producer
:消息生产者,就是向Kafka broker发消息的客户端。Consumer
:消息消费者,向Kafka broker取消息的客户端。Zookeeper
:管理Producer,Broker,Consumer的动态加入与离开。Topic
:可以为各种消息划分为多个不同的主题,Topic就是主题名称。Producer可以针对某个主题进行生产,Consumer可以针对某个主题进行订阅。Consumer Group
: Kafka采用广播的方式进行消息分发,而Consumer集群在消费某Topic时, Zookeeper会为该集群建立Offset消费偏移量,最新Consumer加入并消费该主题时,可以从最新的Offset点开始消费。Partition
:Kafka采用对数据文件切片(Partition)的方式可以将一个Topic可以分布存储到多个Broker上,一个Topic可以分为多个Partition。在多个Consumer并发访问一个partition会有同步锁控制。有的时候,不光是灯红酒绿的世界可以让人沉迷,技术的世界也同样如此。而且有的时候,技术的世界比前者更加可怕,它不但能让你悄无声息的陷入进去,还能让你产生一种你很上进,你很努力的假象,以至于等到你恍然大悟那天,已经悔之晚矣。
目前该中间件只完成了初级阶段功能,很多功能都不完善不深入,随着应用业务的拓展及Kafka未来版本功能支持。以Kafka消息中间件为中心的大数据处理平台还有很多任务去实现。
一般在互联网中所流动的数据由以下几种类型: