Kafka
Kafka（分布式消息队列），用来缓存数据
同一个消费组下多个消费者互相协调消费工作，Kafka会将所有的分区平均地给所有的消费者实例，这样每个消费者都可以分配到数量均等的分区。Kafka的消费组管理协议会动态地维护消费组的成员列表，当一个新消费者加入消费者组，或者有消费者离开消费组，都会触发再平衡操作
Kafka的消费者消费消息时，只保证在一个分区内的消息的完全有序性，并不保证同一个主题汇中多个分区的消息顺序。而且，消费者读取一个分区消息的顺序和生产者写入到这个分区的顺序是一致的。如果业务上需要保证所有消息完全一致，只能通过设置一个分区完成，但这种做法的缺点是最多只能有一个消费者进行消费。一般来说，只需要保证每个分区的有序性，再对消息键来保证相同键的所有消息落入同一分区，就可以满足绝大多数的应用
一·、消息队列的特点
- 解耦
- 冗余
- 扩展性
- 灵活性
- 可恢复性
- 顺序保证
- 缓冲
- 异步通信（允许用户把消息放入队列，但不立即处理）
二·、安装Kafka
（1）解压kafka_2.11-2.3.0.tgz
tar -xzvf kafka_2.11-2.3.0.tgz
（2）在kafka_2.11-2.3.0文件下创建logs文件夹
mkdir logs
（3）修改conf/server.properties文件
broker.id=0
delete.topic.enable=true
（4）修改conf/server.properties文件
# 服务器之间唯一标识
broker.id=0
delete.topic.enable=true
log.dirs=/usr/local/kafka/kafka_2.11-2.3.0/logs
zookeeper.connect=hadoop1:2181,hadoop2:2181,hadoop3:2181
（5）通过ssh发送到其它服务器
scp -r kafka hadoop2:$PWD
scp -r kafka hadoop3:$PWD
（6）启动kafka集群
kafka-server-start.sh config/server.properties &
Kafka基本命令行
（1）查看服务器中所有的topic
kafka-topics.sh --zookeeper hadoop1:2181 --list
（2）创建topic
kafka-topics.sh --zookeeper hadoop1:2181 --create --replication-factor 1 --partitions 1 --topic first
（3）删除topic
kafka-topics.sh --zookeeper hadoop1:2181 --delete --topic first
（4）查看某个topic详情
kafktopics.sh --zookeeper hadoop1:2181 --describe --topic first
（5）发送消息
kafka_2.11-2.3.0]# kafka-console-producer.sh --broker-list hadoop1:9092 --topic first
（6）消费消息
kafka-console-consumer.sh --bootstrap-server hadoop1:9092 --from-beginning --topic first
（7）消费组消费消息
# 修改consumer.properties文件
group.id=freedom
kafka-console-consumer.sh --bootstrap-server hadoop1:9092 --from-beginning --topic first --consumer.config consumer.properties
三、Kafka工作流程分析
1、Kafka生产过程分析
（1）写入方式
producer采用推模式将消息发布到broker，每条消息都被追加到分区中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）
（2）分区
Kafka集群有多个消息代理服务器（broker-server）组成，发布到Kafka集群的每条消息都有一个类别，用topic来表示。通常，不同应用产生不同类型的数据，可以设置不同的topic。一个topic一般会有多个消息的订阅者，当生产者发布消息到某个topic时，订阅了这个topic的消费者都可以接收到生产者写入的新消息
Kafka集群为每个topic维护了分布式的分区日志文件，物理意义上可以把topic看作进行了分区的日志文件。topic的每个分区都是有序的
分区的原因：（1）方便在集群中扩展，每个partition可以通过调整以适应它所在的机器，而一个topic又可以有多个partition组成，因此整个集群就可以适应任意大小的数据；（2）可以提高并发，因为可以以partition为单位读写。由于消息是异步发送给消费者的，消息到达消费者的顺序可能是无序的，这就意味着在并行消费时，传统消息系统无法很好地保证消息被顺序处理。Kafka以分区作为最小的粒度，将每个分区分配给消费者组中不同的而且是唯一的消费者，并确保一个分区只属于一个消费者，即这个消费者就是这个分区的唯一读取线程。那么，只要分区的消息是有序的，消费者处理的消息顺序就有保证
（3）副本
同一个partition可能会有多个replication（对应server.properties配置中default.replication.factor=N）。 没有replication的情况下，一旦broker宕机，其上所有partition的数据都不可被消费，同时producer也不能再将数据存于其上的partition。引入replication之后，同一个partition可能会有多个replication，而这时需要在这些replication之间选出一个leader，producer和consumer只与这个leader交互，其它replication作为follower从leader中复制数据
（4）写入流程
- producer先从zookeeper的"/brokers/.../state"节点找到该partition的leader
- producer将消息发送到该leader
- leader将消息写入本地log
- followers从leader pull消息，写入本地log后向leader发送ACK
- leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK
.
2、broker保存消息
（1）存储方式
物理上把 topic 分成一个或多个 patition（对应 server.properties 中的 num.partitions=3 配置），每个 patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件）
（2）存储策略
无论消息是否被消费，kafka 都会保留所有消息
# 两种策略可以删除旧数据
# 基于时间
log.retention.hours=168
# 基于大小
log.retention.bytes=1073741824
（3）Zookeeper存储结构
1、Kafka消费过程分析
（1）消息模型
消息由生产者发布到Kafka集群后，会被消费者消费。消息的消费模型有：推送模型和拉取模型
基于推送模型的消息系统，由消息代理记录消费者的消费状态。消息代理在将消息推送到消费者后，标记这条消息为已消费，但这种方式无法很好地保证消息被处理。如果要保证消息被处理，消息代理发送完消息后，要设置状态为“已发送”，只有收到消费者的确认请求后才更新为“已消费”，这就需要消息代理中记录所有的消费状态，这种做法显然是不可取的
Kafka采用拉取模型，由消费者自己记录消费状态，每个消费者互相独立地顺序读取每个分区的消息。消费者可以按照任意的顺序消费消息
（2）高级API
优点：简单；不需要自行去管理offset，系统通过zookeeper自行管理；不需要管理分区，副本等情况，系统自动管理；消费者断线会自动根据上一次记录在zookeeper中的offset去接着获取数据；可以使用group来区分对同一个topic的不同程序访问分离开来
缺点：不能自行控制offset；不能细化控制如分区、副本、zk等
（3）低级API
优点：能够让开发者自己控制offset；自行控制连接分区，对分区自定义进行负载均衡；对zookeeper的依赖性降低
缺点：太过复杂，需要自行控制offset，连接哪个分区，找到分区leader等
（4）消费者组
消费者是以消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个partition。有一个由三个消费者组成的group，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者
在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区
（5）消费方式
consumser采用拉模式从broker中读取数据
拉模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞
扫一扫
598
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
