本文主要面向研发同学
是一种高吞吐量的分布式发布订阅消息系统
大致流程 如 图 1-1
图 1-1
订阅者获取消息的方式有两种
如 图 1-1
中 若 S 直接推(Push)给订阅者
这可能会在订阅者接收消息不及时的情况下 丢失消息
Kafka 主要是使用的拉(Pull)方式
如 图 1-1
中 订阅者 自己从 S 中拉取消息给到自己 这样数据就不会丢了
用作 LinkedIn 的活动流
和运营数据
处理管道的基础
活动流
数据包括页面访问量、被查看内容方面的信息以及搜索情况等内容
这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件,然后周期性地对这些文件进行统计分析
运营数据
是服务器的性能数据(CPU、IO 使用率、请求时间、服务日志等等数据)
运营数据的统计方法种类繁多
首先简单介绍下系统结构中会遇到的术语
此外还会涉及一个运维组件 Zookeeper
它是用于管理和协调 Kafka 代理的---维护它们的集群状态
发送消息到 Kafka
大致流程 如 图 2-1
图 2-1
作为一个 MQ 当然也得处理下无消息丢失的问题
acks = all
retry > 0
callback
形式处理 Kafka 与 Zookeeper 的基础关系
Broker 注册、Topic 注册、Follower选举Leader等都由 Zookeeper 帮助完成
大致关系 如 图 2-2
图 2-2
消费端拉取消息
大致流程 如 图 2-3
图 2-3
在 图 2-3
中 这个业务消费端对应的 Topic 集群中只有两个 Partition
业务消费端起了两个连接去执行消息的业务消费逻辑
ConsumerGroup 里面有 3 个 Consumer
其中有一个 Consumer 就是闲置的 Consumer
Partiton、Consumer、业务消费端 Client 的关联关系 如 图 2-4
图 2-4
Q:我们可以想象一下如果 ConsumerGroup 中 Consumer 数量小于对应 Topic 的 Partition 数量会怎样
A:肯定某些 Consumer 会轮询多个 Partition 又因为 Consumer 与 业务消费端是一对一的关系 所以就算增加业务消费端数量也是无济于事
所以最好 Consumer 者数量与 Partition 数量保持一致
此外 要保证消息真的是被消费了 最好是设置成手动提交 ConsumerGroup 对应该 Partition 的 Offset
注: 每个 ConsumerGroup
最好只对应一个 Topic
不然当其中一个 Topic
产生 Rebalance
影响的时候
会影响该 ConsumerGroup
对其他 Topic
的消费
至于什么是 Rebalance
等云天河同学有空再写了
以下服务的下载及安装细节 本文不作重点
请自行
以下很重要!!!
因为不同版本之间,可能差异较大
云天河将以 2.7.0
Kafka 版本作为教学版本
读者请使用与云天河一致的 Kafka 版本
Kafka Manager
地址 https://github.com/yahoo/CMAK
用于查看集群、分区、offset等 , 如图 3-1
图 3-1
因为这个是 雅虎
很多年前做的开源了
对于 kafka
版本的支持也不那么全面
比如我用的 2.7.0
但是我下载的版本它最多支持到 0.11.0
DiDi-Kafka-Manager
推荐用这个
地址 https://github.com/didi/LogiKM
支持用于查看、设置消费者组消费位移、数据情况、网络流量等
这期我们大致了解 Kafka 是怎样一个运作方式
下期我们重点讲下 Kafka 消息为何可以持久化、Kafka 的瓶颈是啥、怎么实现的高吞吐
评论列表点此评论