Kafka:如何高效运维之主题篇
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kafka:如何高效运维之主题篇相关的知识,希望对你有一定的参考价值。
参考技术A作为一个 Kafka 初学者,需要快速成长,承担维护公司 Kafka 的重任,对 Kafka 的学习,我按照三步走策略:
本文属于学习的第二阶段:[ 从运维实战的角度学习 Kafka ],重点学习 Kafka 的主题,通过运维命令创建、更新主题,从 Topic 的 可运维属性,了解 Topic 在 Kafka 内部的运作机制 。
Kafka 提供了 kafka-topics 脚步用来创建、修改、删除、查询 topic,位于$kafka_home/bin/kafka-topics.sh,其中 kafka_home 表示 Kafka 的安装目录。
一些不那么直观的选项进行单独介绍。
收到指定副本数量和分区信息,该参数不能和--partitions、--replication-factor 同时使用。
其格式为:每一个逗号表示一个分区的配置,每一个分区分布的 broker 用冒号隔开。
--replication-factor 0:1,1:2,0:2 表示的含义是什么呢?
分区数量为 3 个,其中分区 0(p0)分布在 broker 0 和 1 上,分区 1(p1)分布在 broker 1,2 上,分区 2(p2)分布在 broker 0 与 2 上。从而推出分区数量为 3,副本因子为 2,每一个分区的第一个 broker 为 Leader,其演示效果如下:
通过 kafka-topics 脚本在创建 topic 时可通过--config 选项来定制化 topic 的属性,接下来试图从这些属性来探究 Kafka 背后的运作机制。
数据文件清除机制,支持 Broker 全局配置,Topic 定制化制定,可选策略:delete、compact,默认值为 delete。Kafka 提供了数据段压缩的功能,按照相同 Key 只保留最新 Key 的策略,减少数据段大小,系统主题__consumer_offsets(用于存储消息进度的主题)其清除策略就是 compact。
压缩类型,Kafka 目前支持的压缩算法:gzip,snappy,lz4,zstd,还支持如下两个配置:
不开启压缩
由发送方指定压缩算法,客户端的可选值为 gzip,snappy,lz4,zstd。
数据进行压缩,能节省网络带宽与存储空间,但会增加 CPU 的性能,故 最佳实践 :Broker 服务端不配置压缩算法, 由发送方指定,在发送方进行压缩,服务端原封不动进行存储,并且在消费端解压缩 。
如果 cleanup.policy 策略为 compact 时,针对消息体为 null 的消息,Kafka 会认为对其进行压缩没有意义,立马删除也太草率,故 Kafka 引入了该参数,用来设置这些 body 为 null 的消息,在一次压缩执行后,多久后可被删除,默认值为 24h。
文件在删除时延迟时间,默认为 60s,Kafka 中可以支持按 topic 删除日志文件(数据文件),执行删除之前,首先会将该 topic 下的分区文件重名为*.deleted,等待 file.delete.delay.ms 才从文件系统中删除。
按消息条数设置刷盘频率,如果设置为 1 表示每写一条消息就触发一次刷盘,默认值为 Long.MaxValue,在大部分场景 官方不建议设置该值,直接利用操作系统的刷盘机制即可,Kafka 希望通过副本机制能保证数据的持久可靠存储 。
按时间间隔设置刷盘频率,默认为 Long.MaxValue,Kafka 希望借助操作系统的刷盘机制,数据可靠性通过副本机制来保证。( 副本机制其实无法保证同机房断电带来的数据丢失 )
索引文件的密度,Kafka 并不会为每一条消息(消息偏移量)建立索引,而是每隔一定间隔,建立一条索引。该参数就是设置其间隔,默认为 4096 个字节。
一次消息发送(Batch)允许的最大字节数量,默认为 1000000,约等于 1M。
是否开启消息格式的自动转化,如果设置为 false,Broker 不会执行消息格式转化,将不兼容老的客户端消费消息。
可以指定该主题按特定版本的 API 版本所对应的存储格式进行存储。
设置消息中存储的时间戳的获取方式,可选值:
消息在客户端的创建时间
Broker 服务端接收到的时间,默认为 CreateTime。
当 message.timestamp.type 设置为 CreateTime 时,允许 Broker 端时间与消息创建时间戳最大的差值,如果超过该参数设置的阔值,Broker 会拒绝存储该消息, 默认为:Long.MaxValue,表示不开启开机制 。
控制可压缩的脏数据比例,默认为 0.5d,如果一个文件中"脏数据"(未被压缩的数据)低于该阔值,将不继续对该文件进行压缩,该方法生效的条件为 cleanup.policy 设置为 compact 。
设置一条消息进入到 Broker 后多久之内不能被 compact,默认为 0,表示不启用该特性,该方法生效的条件为 cleanup.policy 设置为 compact 。
如果客户端在消息发送时将 ack 设置为 all,该参数指定必须至少多少个副本写入成功,才能向客户端返回成功,默认为 1,这个是一个兜底配置,all 的含义表示在 ISR 中的副本必须全部写入成功。
是否开启预热文件(提前创建文件),默认为 false。
一个日志分区保留的最大字节数,默认为-1,表示不限制。
一个日志分区允许保留的最大时长,默认保留 7d。
一个日志段的大小,默认为 1G。
一个日志段索引文件的大小,默认为 10M。
段滚动的最大随机差。
Kafka 强制滚动一个段的间隔时间,及时该段并未全部填满消息,默认值为 7d
是否允许不在 ISR 中副本在没有 ISR 副本选择之后竞争成为 Leader,这样做有可能丢数据,默认为 false。
本文从运维命令开始学习,从使用运维层面全面了解 Topic,从而窥探其 Kafka 内部一些重要特性,为后续从源码角度研究其实现打下坚实基础。
本文的最后给出一个分区数量为 3,副本因子为 3 的 topic 分区图来结束本文的讲解。
得云社 | 新时代下的高效运维之道
1、活动内容
云计算普及、Docker 兴起
新一代信息技术不断发展
业务扩张导致用户体量愈发庞大
系统管理难度指数直线上升
这带给运维的是前所未有的挑战
而高效运维从来不是一件易事
在技术革命快速发展的今天
运维该如何转身极具现实意义
此次七牛云将携手 OneAPM 新智云 (www.enncloud.cn)
共同为大家带来一场绝不能错过的技术盛宴!
2 时间&地点
时间:2017 年 5 月 13 日 13:30 - 17:00
线下:北京中关村大街11号E世界财富中心A座B2层P2联合创业办公社
线上:请先报名网络直播票,截图报名信息后,
加工作人员微信: qiniuyun,需备注:5月13日实践日
3 嘉宾介绍
Topic 1《To B 企业运维的机遇和挑战》
高磊 [七牛云高级运维总监]
个人介绍:
七牛云运维总监。曾任职于百度、五八同城、豌豆荚 和 A 站。经历过大中小型 To C 领域企业,也曾创业,目前正在探索 To B 领域企业的工作方式与优化之路。
内容简介:
从常见的互联网公司到最新的面向企业的各类公有云、专有云提供商,运维的工作内容和模式一直在转变。曾经流行的 Devops 是否依然适用?如何在云公司做运维?本次分享将带给大家一些新的视角与观点。
Topic 2《百万并发云压测平台的关键技术》
高海强 [OneAPM 研发总监]
个人简介:
高海强 OneAPM 研发总监,曾就职于埃森诺历任研发工程师、技术总监、架构师、CTO 等技术及管理岗位。在性能管理相关行业 10 年以上经验,有多年的高并发、高可用、高可扩展大中型系统架构设计经验。15 年起带领团队致力于打造中国自主知识产权的百万级并发压力测试平台。
内容简介:
随着互联网业务的快速发展,用户数急速增长,同时各类市场活动频繁,我们的业务系统是否能够经受的住高并发用户访问,有什么测试手段和方法可以做到提前验证,准确评估我们的系统在流量高峰时可以经得住考验。大容量云压测平台在此背景下推出,本次将和大家分享实现压测平台的关键技术与细节。
Topic 3《敏捷性的传承》
李玉峰 [唱吧高级运维总监]
个人简介:
李玉峰,曾任职大型互联网安全公司、国航、某国际互联网电商公司、历任安全架构师、项目总监、高级运维总监等。现就职唱吧,负责后台技术团队的管理、技术保障等工作,擅长架构设计优化、性能优化、数据库设计、PHP/PYTHON/H5 、网络安全 WEB 安全等。
内容简介:
公司日益壮大,如何继续保障开发效率、运维效率、人工效率,展现更好的敏捷性,是对一个创业公司的考验,也是对一个中小型公司的挑战,来,我亲自带你解读。
Topic 4《看着难,做着更难 —— IP 库背后的故事》
高春辉[北京天特信科技有限公司创始人]
个人简介:
从事互联网行业接近 20 年,从 To C 到 To B,积累了丰富的经验和人脉,目前在做国内最专业的 IP 数据库。我们目前专注于与 IP 相关的数据的整理与发行,致力于将基础数据变得更准确、更精确,我们的主力产品 IP 地理位置数据库主要基于 BGP/ASN 数据以及遍布全球的网络监测点进行城市级 IP 地域数据标注,准确度远高于国内国外同类产品。
内容简介:
基于三年多的 IP 数据库维护经验,给各位讲讲我们这个领域里的一些知识,也有一些可以分享的内容,可以让大家更好的理解和应用 IP 数据库。
更多请关注微信公众号:“极客脑司机”
以上是关于Kafka:如何高效运维之主题篇的主要内容,如果未能解决你的问题,请参考以下文章