Kafka概念
Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发,之后成为Apache项目的一部分。Kafka是一个分布式的、可划分的、冗余备份的、持久性的日志服务。它主要用于处理活跃的流式数据。分布式系统,易于向外扩展。所有的producer、broker和consumer都会有多个,均为分布式的。无需停机即可扩展机器。
Kafka设计方案
消息持久化及其缓存
磁盘性能:在传统的磁盘写入很慢,因为它使用随机写入50k/s(6个7200转的sata硬盘组成的raid-5),但是线性写入速度有300ms/s的速度,所以Kafka利用线性写入的方式。
线性写入:将数据调用操作系统文件接口写到文件系统里面去这样就缓存到操作系统的页面缓存中,然后传统意思来说将其flush一下到磁盘中,但是Kafka并没有这样,而是保存在页面缓存中(相当于放在内存当中)并没有进行flush操作,这样他就会提供比较高的读的性能,下次读就从内核页面缓存中读数据,但是内存中存储数量不是无限大的,所以我们配置参数(每当接收到N条信息或者每过M秒),进行一个flush操作,从而可以为系统硬件崩溃时“处于危险之中”的数据在量上加个上限。
Kafka的缓存不是在内存中保存尽可能多的数据并在需要时将这些数刷新到文件系统,而是做完全相反的事情,将所有的数据立即写入文件系统中的持久化的日志中,但不进行刷新数据的调用,实际这么做意味着数据被传输到os内核的页面缓存中去了,随后在根据配置刷新到硬盘。
Kafka安装
安装优化主要修改config目录下的server.properties文件,需要修改的参数值主要有 broker.id、host.name、log.dirs。
brokerid是对Kafka集群各个节点的一个标识,比如xx.xxx.xx.1 当做节点一,则brokerid=1;xx.xxx.xx.2 当做节点二,则brokerid=2 ;host.name需要配置的是本机ip或者主机名映射。如下图:
log.dirs是配置Kafka数据日志的本地磁盘。
生产集群中,我们还需要配置Kafka进程的启动内存,通过配置kafka-server-start.sh,分配10g内存,5g初始化内存。如下图:
启动Kafka集群并检查zk路径上Kafka节点是否全部上线。
Kafka优化
以下为实际生产集群Kafka优化配置项,标红部分为权限控制配置,后续会有专门一章来描述。
下面两个参数,如果在生产集群中写死了无法批量修改配置。
broker
Kafka常用操作
启动Kafka进程:
nohup
注意
创建主题:
$
主题列表:
$KAFKA_HOME
启动消费者进程:
$KAFKA_HOME
启动生产者进程:
$KAFKA_HOME
删除主题:
$KAFKA_HOME
描述主题:
$KAFKA_HOME
Kafka权限控制
配置服务端权限控制属性server.properties:
vi
修改brokerid
zookeeper
配置服务端权限控制用户:
KafkaServer
配置客户端权限控制用户:
vi
配置生产及消费权限控制属性producer.properties:
consumer
配置服务端启动脚本:
/
配置生产消费运行脚本:
vi
赋权命令
未赋予任何权限时:
测试命令:
启动服务:
nohup
确认环境无授权信息:
kafka
赋予某个用户处理集群的权限:
kafka
创建主题:
$KAFKA_HOME
赋予topic权限:
kafka
- 指定主题指定用户 -
为主题赋予*某个*用户的*生产*权限:
kafka
为主题赋予*某个*用户在*所有*消费者组*下*消费*权限:
kafka
为主题赋予*某个*用户在*某个*消费者组*下*消费*权限:
kafka
- 指定主题全部用户 -
为主题赋予*全部*用户的*生产*权限:
kafka
为主题赋予*全部*用户在*所有*消费者组*下*消费*权限:
kafka
为主题赋予*全部*用户在*某个*消费者组*下*消费*权限:
kafka
- 所有主题指定用户 -
为所有主题赋予某个用户的生产权限:
kafka
为所有主题赋予某个用户在某个消费者组消费权限:
kafka
为所有主题赋予某个用户在全部消费者组消费权限:
kafka
- 所有主题全部用户 -
为所有主题赋予全部用户的生产权限:
kafka
为所有主题赋予全部用户在某个消费者组消费权限:
kafka
为所有主题赋予全部用户在全部消费者组消费权限:
kafka
移除权限:
bin
查看权限:
查看所有用户的所有权限:
kafka
查看某个用户所拥有的权限:
kafka
查看某个主题所拥有的权限:
kafka
生产消费测试
启动生产者:
$KAFKA_HOME
启动消费者:
kafka
Kafka权限控制的java代码示例:
put
Kafka维护存储均衡
- 评估数据量:要求研发提前评估topic一个周期全量的数据大小。
- 计算磁盘总存储:如一块盘825g,一个节点20快盘,10个节点。那么磁盘总存储就是165000g。
- 预估实际数据存储占比:topic一个周期全量数据大小占磁盘总存储的百分比,超过百分之六十,即要求研发减少存储周期。
- 计算磁盘总块数:一个节点20快盘,10个节点,总磁盘块数200个。
- 合理预分区:分区数量为磁盘总数的整数倍。如所有的topic总数据量为50000gb,磁盘个数为200,那么就可以设置总分区数为200,400,600.具体多少分区数视业务决定。若分区数为400,那么一个分区的大小约125g。例如某一个topic:cbss001的预估数据量是210g,那么通过计算可以将其分成两个分区。这样根据Kafka副本落盘策略,各个主机磁盘就能保证最大限度的存储均衡。
Kafka常见故障处理
- 坏盘会导致节点宕掉,及时更换坏盘,重启节点即可。
- unclean.leader.election.enable 该参数为true配置到topic中会引起消息重复消费。但为false时,会引起节点9092端口断开连接,导致Kafka进程假死。
- 内存溢出,其会导致节点副本不能上线isr。
- 进程,文件数限制也会造成节点报错,后续调优中会给出优化参数。
- flower副本不能及时同步leader副本,同步超时导致副本下线isr。
- 消费offset越界,这种情况首先重启节点,若还是报错,则找到该offset越界的分区,删除几条message,再次查看。知道不报错为止。
Kafka集群扩容下线节点
使用自动迁移工具
下面的示例将把foo1,foo2两个主题的所有分区都迁移到新的broker机器5,6上。最后,foo1,foo2两个主题的所有分区都厚在brokers 5,6上。
vi
工具生成了一个把主题foo1,foo2所有分区迁移到brokers 5,6上的计划。注意,分区迁移还没有开始。它只是告诉你当前分配计划和新计划的提议。为了防止万一需要回滚,新的计划应该保存起来。
新的调整计划应该保存成一个json文件(如:expand-cluster-reassignment.json),并以–execute选项的方式,如下:
bin
执行验证:–verify
bin
Kafka日志保留周期设置
log.retention.bytes (一个topic的大小限制 =分区数*log.retention.bytes)
log.retention.minutes
log.retention.bytes和log.retention.minutes任意一个达到要求,都会执行数据删除
Kafka指定topic赋参
kafka
Kafka集群监控
Python脚本监控Kafka存活节点
Python脚本监控Kafka各节点磁盘存储:
#