![](https://img-blog.csdnimg.cn/20201014180756927.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
Kafka核心技术与实战
文章平均质量分 92
飘然渡沧海
这个作者很懒,什么都没留下…
展开
-
揭开神秘的“位移主题”面纱 no.16
用户不能修改,也就是说你不能随意地向这个主题写消息,因为一旦你写入的消息不满足Kafka规定的格式,那么Kafka内部无法成功解析,就会造成Broker的崩溃。事实上,Kafka Consumer有API帮你提交位移,也就是向位移主题写消息。你千万不要自己写个Producer随意向该主题发送消息。你可能会好奇,这个主题存的到底是什么格式的消息呢?所谓的消息格式,你可以简单地理解为是一个KV对。Key和Value分别表示消息的键值和消息体,在Kafka中它们就是字节数组而已。原创 2024-05-29 14:57:31 · 600 阅读 · 0 评论 -
消费者组到底是什么?no.15
Kafka的消费者组。消费者组,即Consumer Group,应该算是Kafka比较有亮点的设计了。那么何谓Consumer Group呢?。既然是一个组,那么组内必然可以有多个消费者或消费者实例(Consumer Instance),它们共享一个公共的ID,这个ID被称为Group ID。组内的所有消费者协调在一起来消费订阅主题(Subscribed Topics)的所有分区(Partition)。当然,每个分区只能由同一个消费者组内的一个Consumer实例来消费。原创 2024-05-29 14:55:39 · 863 阅读 · 0 评论 -
幂等生产者和事务生产者是一回事吗?no.14
幂等”这个词原是数学领域中的概念,指的是某些操作或函数能够被执行多次,但每次得到的结果都是不变的。我来举几个简单的例子说明一下。比如在乘法运算中,让数字乘以1就是一个幂等操作,因为不管你执行多少次这样的运算,结果都是相同的。再比如,取整函数(floor和ceiling)是幂等函数,那么运行1次floor(3.4)和100次floor(3.4),结果是一样的,都是3。相反地,让一个数加1这个操作就不是幂等的,因为执行一次和执行多次的结果必然不同。原创 2024-05-29 14:53:18 · 964 阅读 · 0 评论 -
Java生产者是如何管理TCP连接的?no.13
试想一下,在一个有着1000台Broker的集群中,你的Producer可能只会与其中的3~5台Broker长期通信,但是Producer启动后依次创建与这1000台Broker的TCP连接。值得注意的是,在第二种方式中,TCP连接是在Broker端被关闭的,但其实这个TCP连接的发起方是客户端,因此在TCP看来,这属于被动关闭的场景,即passive close。更严谨地说,作为一个基于报文的协议,TCP能够被用于多路复用连接场景的前提是,上层的应用协议(比如HTTP)允许发送多条消息。原创 2024-05-29 11:22:42 · 599 阅读 · 0 评论 -
客户端都有哪些不常见但是很高级的功能?no.12
而Flume中的拦截器也是同理,它们插入的逻辑可以是修改待发送的消息,也可以是创建新的消息,甚至是丢弃消息。在上面的消费者拦截器中,我们在真正消费一批消息前首先更新了它们的总延时,方法就是用当前的时钟时间减去封装在消息中的创建时间,然后累计得到这批消息总的端到端处理延时并更新到Redis中。从技术上来说,我们可以在客户端程序中增加这样的统计逻辑,但是对于那些将Kafka作为企业级基础架构的公司来说,在应用代码中编写统一的监控逻辑其实是很难的,毕竟这东西非常灵活,不太可能提前确定好所有的计算逻辑。原创 2024-05-29 11:17:18 · 507 阅读 · 0 评论 -
无消息丢失配置怎么实现?no.11
我们先从什么是消息丢失开始说起,明确了Kafka持久化保证的责任边界,随后以这个规则为标尺衡量了一些常见的数据丢失场景,最后通过分析这些场景,我给出了Kafka无消息丢失的“最佳实践”。在这里我要提醒你一下,单个Consumer程序使用多线程来消费消息说起来容易,写成代码却异常困难,因为你很难正确地处理位移的更新,也就是说避免无消费消息丢失很简单,但极易出现消息被消费了多次的情况。什么是已提交的消息?总结一下,Kafka是能做到不丢失消息的,只不过这些消息必须是已提交的消息,而且还要满足一定的条件。原创 2024-05-29 11:16:02 · 471 阅读 · 0 评论 -
生产者压缩算法面面观no.10
说起压缩(compression),我相信你一定不会感到陌生。它秉承了用时间去换空间的经典trade-off思想,具体来说就是用CPU时间去换磁盘空间或网络I/O传输量,希望以较小的CPU开销带来更少的磁盘占用或更少的网络I/O传输。在Kafka中,压缩也是用来做这件事的。今天我就来跟你分享一下Kafka中压缩的那些事儿。原创 2024-05-28 09:30:43 · 986 阅读 · 0 评论 -
生产者消息分区机制原理剖析no.9
我们在使用Apache Kafka生产和消费消息的时候,肯定是希望能够将数据均匀地分配到所有服务器上。比如很多公司使用Kafka收集应用服务器的日志数据,这种数据都是很多的,特别是对于那种大批量机器组成的集群环境,每分钟产生的日志量都能以GB数,因此如何将这么大的数据量均匀地分配到Kafka的各个Broker上,就成为一个非常重要的问题。今天我就来和你说说Kafka生产者如何实现这个需求,我会以Java API为例进行分析,但实际上其他语言的实现逻辑也是类似的。原创 2024-05-28 09:25:12 · 826 阅读 · 0 评论 -
最最最重要的集群参数配置(下)no.8
今天我们继续来聊那些重要的Kafka集群配置,下半部分主要是Topic级别参数、JVM参数以及操作系统参数的设置。在上一期中,我们讨论了Broker端参数设置的一些法则,但其实Kafka也支持为不同的Topic设置不同的参数值。当前最新的2.2版本总共提供了大约25个Topic级别的参数,当然我们也不必全部了解它们的作用,这里我挑出了一些最关键的参数,你一定要把它们掌握清楚。除了Topic级别的参数,我今天还会给出一些重要的JVM参数和操作系统参数,正确设置这些参数是搭建高性能Kafka集群的关键因素。原创 2024-05-28 09:23:20 · 851 阅读 · 0 评论 -
最最最重要的集群参数配置(上)no.7
我希望通过两期内容把这些重要的配置讲清楚。严格来说这些配置并不单单指Kafka服务器端的配置,其中既有Broker端参数,也有主题(后面我用我们更熟悉的Topic表示)级别的参数、JVM端参数和操作系统级别的参数。需要你注意的是,这里所说的Broker端参数也被称为静态参数(Static Configs)。我会在专栏后面介绍与静态参数相对应的动态参数。所谓静态参数,是指你必须在Kafka的配置文件server.properties中进行设置的参数,不管你是新增、修改还是删除。原创 2024-05-27 14:38:23 · 838 阅读 · 0 评论 -
Kafka线上集群部署方案怎么做?no.6
最后是社区的支持度。这一点虽然不是什么明显的差别,但如果不了解的话可能比前两个因素对你的影响更大。简单来说就是,社区目前对Windows平台上发现的Kafka Bug不做任何承诺。虽然口头上依然保证尽力去解决,但根据我的经验,Windows上的Bug一般是不会修复的。原创 2024-05-27 14:37:10 · 873 阅读 · 0 评论 -
我应该选择哪种Kafka?no.4
Kafka不再是一个单纯的消息引擎系统,而是能够实现精确一次(Exactly-once)处理语义的实时流处理平台。你可能听说过Apache Storm、Apache Spark Streaming抑或是Apache Flink,它们在大规模流处理领域可都是响当当的名字。令人高兴的是,Kafka经过这么长时间的不断迭代,现在已经能够稍稍比肩这些框架了。我在这里使用了“稍稍”这个字眼,一方面想表达Kafka社区对于这些框架心存敬意;原创 2024-05-27 14:35:42 · 877 阅读 · 0 评论 -
Kafka只是消息引擎系统吗?no.3
因为当这些框架与外部消息引擎系统结合使用时,它们无法影响到外部系统的处理语义,所以如果你搭建了一套环境使得Spark或Flink从Kafka读取消息之后进行有状态的数据计算,最后再写回Kafka,那么你只能保证在Spark或Flink内部,这条消息对于状态的影响只有一次。但我们也欣喜地看到,随着在Kafka峰会上各路大神们的鼎力宣传,如今利用Kafka构建流处理平台的案例层出不穷,而了解并有意愿使用Kafka Streams的厂商也是越来越多,因此我个人对于Kafka流处理平台的前景也是非常乐观的。原创 2024-05-27 09:23:44 · 299 阅读 · 0 评论 -
一篇文章带你快速搞定Kafka术语no.2
在Kafka的世界中有很多概念和术语是需要你提前理解并熟练掌握的,这对于后面你深入学习Kafka各种功能和特性将大有裨益。下面我来盘点一下Kafka的各种术语。在专栏的第一期我说过Kafka属于分布式的消息引擎系统,它的主要功能是提供一套完备的消息发布与订阅解决方案。在Kafka中,发布订阅的对象是主题(Topic),你可以为每个业务、每个应用甚至是每类数据都创建专属的主题。原创 2024-05-27 09:22:21 · 933 阅读 · 0 评论 -
消息引擎系统ABC.no.01
这个简单的流程中就可能包含多个子服务,比如点击订阅按钮会调用订单系统生成对应的订单,而处理该订单会依次调用下游的多个子系统服务 ,比如调用支付宝和微信支付的接口、查询你的登录信息、验证课程信息等。但是,一旦有了消息引擎,它能够有效地对抗上游的流量冲击,真正做到将上游的“峰”填满到“谷”中,避免了流量的震荡。这些都是很酷的办法。我个人认为并不是很恰当,因为它片面强调了消息主体的作用,而忽视了这类系统引以为豪的消息传递属性,就像引擎一样,具备某种能量转换传输的能力,所以我觉得翻译成消息引擎反倒更加贴切。原创 2024-05-27 09:20:49 · 410 阅读 · 0 评论