Kafka 简介

*kafka的业务应用场景：

  数据实时存在，但是在某点上会出现高峰，这些活跃数据无法确定大小，

比如随着商家促销，节假日打折，造成数据忽高忽低，

这些数据对系统有利，因此需要记录。

而对于活跃数据分析中：

a) 传统日志分析方式都是需要离线，而且操作起来比较复杂，根本无法满足实时的分析

b)  现有的消息队列系统,因为无法消费大量的持久化在队列系统上的信息 所以只能达到近似实时的分析

 

Kafka的目标就是能够成为一个高效的队列平台，无论是处理离线的信息还是在线的信息

从而结合了 a b的处理，以符合业务的需求。

 

 

 

 问题： 我用这个kafka在高吞吐下 对数据如何处理  怎么处理， 弄个应用场景 理解下？？？

双十一下 淘宝消费动态的消费数据在大屏幕下的汇总

 

1 体系结构

 

 

集群结构：

kafka集群在zookeeper上注册，告诉zookeeper，我们都是kafka的broker,

消息生产者向zookeeper问询，得到一个kakfa的节点，然后在向kafka的这个节点push message

消费者各式各样，消费数据时，向zookeeper问询，得到一个kakfa的节点，

然后在向kafka的这个节点pukk message

 

生产者和kafka  消费者和kafka 以及kafka各自节点之间 通过zookeeper来解耦

结构图如下：

 

 

 

核心概念:

 

topic: 相同性质的message会放在一个topic中

         网址访问PV

        电商交易数据 就应该放在两个topic中

 

partition: 分区，类似于elasticsearch，把数据分成好几份，每一份存储在不同节点上，

              比如双十二电商交易数据过多，存放在同一个topic上容易造成硬盘盛满，

              那么可以把这个topic分成三个(3个仅仅是举例而已)partiton,

              每一个partition存放在一个节点上，

              partition的存在好处是：a) 扩容，让每个节点可以存放更多topic b)负载均衡 访问的时候可以同时向

              这三个节点来得到电商交易数据

 

每个partition就是一个log quene, 保证了时间有序，

日志的生命周期不由是否消费了日志决定，而由系统设置的broker中暂存日志生命周期时间来确定。

因此日志数据会暂存一段时间，多消费者消费时仅仅过了读取存储的数据即可。

 

 

offset: 消息存储偏移量，消息进来的时候长度可大可小，因此用偏移量来定位每个消息的位置

 

consume group:  一个消息(电影)能被消费者(观众)共享

                            一个车票 对应一个人  非共享

                           同一consume group中的消费者只能有一个消费同一条消息 

                          不同consume group之间的消费者可以共享同一条消息。