Kafka相关

1、Kafka概念

Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。

传统的消息传递方法：

排队：在队列中，一组用户能够从服务器中读取消息，每条消息都发送给其中一我的。

发布-订阅：在这个模型中，消息被广播给全部的用户

kafka的优点：

快速：单一的Kafka代理能够处理成千上万的客户端，每秒处理数兆字节的读写操做。

可伸缩：在一组机器上对数据进行分区和简化，以支持更大的数据

持久：消息是持久性的，并在集群中进行复制，以防止数据丢失。

设计：它提供了容错保证和持久性

kafka的缺陷：

没有完整的监控工具集

消息调整的问题

不支持通配符主题选择

速度问题

2、Kafka应用场景

一、日志收集：一个公司的各类应用均可以做为生产者将日志吐到kafka，再由hbase，solr，es等来消费kafka的日志做统计，查错。

二、消息系统：解耦和生产者和消费者、缓存消息等。

三、用户活动跟踪：Kafka常常被用来记录web用户或者app用户的各类活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，而后订阅者经过订阅这些topic来作实时的监控分析，或者装载到hadoop、数据仓库中作离线分析和挖掘。

四、运营指标：Kafka也常常用来记录运营监控数据。包括收集各类分布式应用的数据，生产各类操做的集中反馈，好比报警和报告

3、Kafka相关组件

主题：Kafka主题是一堆或一组消息。

生产者：在Kafka，生产者发布通讯以及向Kafka主题发布消息。

消费者：Kafka消费者订阅了一个主题，而且还从主题中读取和处理消息。

经纪人：在管理主题中的消息存储时，咱们使用Kafka Brokers。

4、Kafka消息是采用Pull模式，仍是Push模式？

Kafka采用Pull模式。

一、解决了当broker推送的速率远大于consumer消费的速率时的状况。

二、consumer能够自主决定是否批量的从broker拉取数据。避免了Push模式下为了不consumer崩溃而采用较低的推送速率，形成资源浪费。

Pull有个缺点是，若是broker没有可供消费的消息，将致使consumer不断在循环中轮询，直到新消息到达。为了不这点，Kafka有个参数可让consumer阻塞知道新消息到达。

5、Zookeeper

Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。

不可能越过Zookeeper，直接联系Kafka broker。一旦Zookeeper中止工做，它就不能服务客户端请求。

Zookeeper做用：

一、Zookeeper主要用于在集群中不一样节点之间进行通讯

二、在Kafka中，它被用于提交偏移量，所以若是节点在任何状况下都失败了，它均可以从以前提交的偏移量中获取

三、它还执行其余活动，如: leader检测、分布式同步、配置管理、识别新节点什么时候离开或链接、集群、节点实时状态等等。

6、解决kafka的数据丢失

Producer端：

宏观上看保证数据的可靠安全性，确定是依据分区数作好数据备份，设立副本数。

Broker端：

topic设置多分区，分区自适应所在机器，为了让各分区均匀分布在所在的broker中，分区数要大于broker数。分区是kafka进行并行读写的单位，是提高kafka速度的关键。

Consumer端

consumer端丢失消息的情形比较简单：若是在消息处理完成前就提交了offset，那么就有可能形成数据的丢失。因为Kafka consumer默认是自动提交位移的，因此在后台提交位移前必定要保证消息被正常处理了，所以不建议采用很重的处理逻辑，若是处理耗时很长，则建议把逻辑放到另外一个线程中去作。为了不数据丢失，现给出两点建议：

一、enable.auto.commit=false  关闭自动提交位移二、在消息被完整处理以后再手动提交位移