51CTO：也就这么回事，Kafka架构原理( 四 ) 【51CTO.com原创稿件】本文主要讲解Kaf

消费者
消费方式
Consumer采用Pull(拉取)模式从Broker中读取数据。
Consumer采用Push(推送)模式， Broker给Consumer推送消息的速率是由Broker决定的，很难适应消费速率不同的消费者。
它的目标是尽可能以最快速度传递消息，但是这样很容易造成Consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。
而Pull模式则可以根据Consumer的消费能力以适当的速率消费消息。 Pull模式不足之处是，如果Kafka没有数据，消费者可能会陷入循环中，一直返回空数据。
因为消费者从Broker主动拉取数据，需要维护一个长轮询，针对这一点， Kafka的消费者在消费数据时会传入一个时长参数timeout 。
如果当前没有数据可供消费， Consumer会等待一段时间之后再返回，这段时长即为timeout 。
分区分配策略
一个ConsumerGroup中有多个Consumer ，一个Topic有多个Partition ，所以必然会涉及到Partition的分配问题，即确定哪个Partition由哪个Consumer来消费。
Kafka有两种分配策略，一个是RoundRobin ，一个是Range ，默认为Range ，当消费者组内消费者发生变化时，会触发分区分配策略(方法重新分配) 。
①RoundRobin

文章图片
RoundRobin轮询方式将分区所有作为一个整体进行Hash排序，消费者组内分配分区个数最大差别为1 ，是按照组来分的，可以解决多个消费者消费数据不均衡的问题。
但是，当消费者组内订阅不同主题时，可能造成消费混乱，如下图所示， Consumer0订阅主题A ， Consumer1订阅主题B 。

文章图片
将A、B主题的分区排序后分配给消费者组， TopicB分区中的数据可能分配到Consumer0中。
②Range

文章图片
Range方式是按照主题来分的，不会产生轮询方式的消费混乱问题。
但是，如下图所示， Consumer0、Consumer1同时订阅了主题A和B ，可能造成消息分配不对等问题，当消费者组内订阅的主题越多，分区分配可能越不均衡。

文章图片
Offset的维护
由于Consumer在消费过程中可能会出现断电宕机等故障， Consumer恢复后，需要从故障前的位置继续消费。
所以Consumer需要实时记录自己消费到了哪个Offset ，以便故障恢复后继续消费。
Kafka0.9版本之前， Consumer默认将Offset保存在Zookeeper中，从0.9版本开始， Consumer默认将Offset保存在Kafka一个内置的Topic中，该Topic为__consumer_offsets 。
总结
上面和大家一起深入探讨了Kafka的架构，比较偏重理论和基础，这是掌握Kafka的必要内容，接下来我会以代码和实例的方式，更新Kafka有关API以及事务、拦截器、监控等高级篇，让大家彻底理解并且会用Kafka 。
作者：臧远慧
简介：就职于中科星图股份有限公司(北京) ，研发部后端技术组。个人擅长Python/Java开发，了解前端基础;熟练掌握MySQL ， MongoDB ，了解Redis;熟悉Linux开发环境，掌握Shell编程，有良好的Git源码管理习惯;精通Nginx ， Flask、Swagger开发框架;有Docker+Kubernetes云服务开发经验。对人工智能、云原生技术有较大的兴趣。

文章图片
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】