Kafka笔记

Kafka概述:
Kafka是一个基于发布、订阅的分布式消息队列,用于大数据实时处理。

为什么要用kafka?
注册信息的过程,先在网站上填写注册信息,后台会调用其他服务的接口,反馈给网页注册成功信息,最后再显示给用户,
并且将短信发送给用户,该过程为同步通信过程,需要同步等待，由于同步通信的过程比较慢效率比较低,引入了消息队列,
网页将注册信息放到消息队列中等待,然后直接回复用户注册成功,在一段时间以后用户才收到短信提示,通过消息队列将网页
和短信进行了隔离,不用让用户在注册的同时一直等待。 
同步通信干一件事等着回复,异布通信干一件事不等着回复,有回复通知即可。

消息队列的好处:
1.解耦:MQ在数据生产方和数据消费方做了一个解耦,允许你独立的扩展或修改两边的处理过程
2.可恢复:消息队列降低了进程间的耦合度,即使一个处理消息的进程故障，加入队列中的消息仍然可以在系统恢复后被处理。
3.缓冲:有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致
4.峰值处理:使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
说明:
  数据注册时写入数据库的时候考虑的高并发的请求,但发送短信的服务并没有考虑高并发,如果数据直接发到短信服务端会导致短信服务端崩溃,
  将数据发送到MQ的后,让短信服务端自己根据自己的能力去取即可。

消息队列的两种模式:
1.点对点:消费者主动拉取数据，数据被消费者消费之后消息队列中的数据会清除。
  消息生产者生产消息后发送到队列中, 然后消息消费者从消息队列中主动拉取并消费消息,消息被消费以后,队列中不在有存储,
  所以消息消费者不可能消费已经被消费过的消息,消息队列支持多个消费者,但是对一个消息而言,只可以被一个消费者消费。

2.订阅/发布:消费者消费数据之后不会清除消息
  消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，
  发布到topic的消息会被所有订阅者消费。 'topic'就是逻辑上消息队列。

Kafka基础架构:
  1).Kafka架构中涉及到 Kafka集群(多个Broker)、 生产者(生产消息) 、 消费者(消费消息) 、 zookeeper(注册消息)

  2). Kafka集群
      Kafka集群由多个broker组成，每个broker都有唯一的id.
      Kafka内部维护Topics,每个topic可以有多个分区partition,每个partition是一个有序的队列；
      为了提高可靠性,每个分区可以有多个副本replication,每个副本有各自的角色 'leader/follower',所有的读写都是由leader负责.
    
   说明:
      1.每个topic在逻辑上为一个队列,但在物理上被划分为了多个分区,每个消息队列的分区会分布在多个集群上,但集群的各个节点吞吐能力可能不同,
        此时可以根据不同节点消费的不同分区数据去处理各自区内的吞吐,从而提高吞吐量。
      2.每个topic的多个分区可以存在到一个broker；
      3.每个Topic的一个分区的多个副本必须在不同的broker；
        

  3).生产者       
      生产者的主要作用就是面向Topic生产数据.  

  4).消费者
      消费者主要是以消费者组的名义面向topic进行消息的消费。
    说明:  
      每个消费者组中的一个消费者可以同时消费一个topic中的多个分区的数据;
      但每个topic的一个分区只能被一个消费者组中的一个消费者消费;
      消费者在消费数据的过程中需要实时记录offset(消费的位置), 记录的方式为: 'group + topic + partition'
      而offiset在kafka中有一个topic用于专门维护offset,该topic比较特殊,有50个分区和1个副本。
      消费者组本质上是一个消费者,当一个消费者组中的一个消费者对应一个分区,单个消费者组正好消费完一个topic时效率最高。

  5). Zookeeper
      Kafka中topic之间的协调依赖于zookeeper运行,Zookeeper主要的作用就是让kafka去注册消息。
      例如:每个broker启动后会在zookeeper中注册,并 "选举controller" ,实际上就是抢,谁抢到谁是爹,先起的服务器有优势。
           在低版本0.9之前,消费者维护的offset存储在zk中. 
           在0.9版本之后,消费者维护的offset存储在kafka本地. 注:这与SparkStreaming消费kafka数据的API版本对应。
          
   Kafka端口号9092
   配置文件中的 'log.dirs' 不是存kafka的日志,而是存储放在kafka里面的消息,如话题,位置信息。
   消息存储在磁盘中，数据保存7天。

消费者消费数据的两种模式:
1.消息队列推送的方式:该模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。推送的方式只能按照消费者消费速率最小的为准,由于消息队列不清楚每个消费者的消费水平,不方便推送。
2.消费者主动拉取的方式:通过消费者自己主动来拉取,但消费者并不知道消息队列是否有消息,所以以长轮询的方式不停的拉取,但是
  若消息队列中始终没有消息,则会不停的去拉取,效率会很低,所以维护了一个时长参数timeout,如果当前没有数据可供消费，Consumer 会等待一段时间之后再返回，
  这段时长即为timeout。

环境变量的配置: 
   Linux中可以配置环境变量的位置:  
           /etc/profile  
           /etc/profile.d/xxx.sh  
           /home/atguigu/.bashrc 
           /etc/bashrc 
           ......
   登录式shell: 通过用户名和密码登录到shell中. 例如使用xshell工具连接某台服务器
           /etc/profile  ->  /etc/profile.d/xxx.sh 
   非登录式shell : ssh hadoop102 
           /home/atguigu/.bashrc -> /etc/bashrc -> /etc/profile.d/xxx.sh 

Kafka工作流程及文件存储
Kafka中消息