Apache Kafka Core Concept

3/8/2017来源:ASP.NET技巧人气:2910

The PRoducer

The Producer  Load balacing

producer 直接发送数据到broker中,这个broker是分区的主服务。 为了帮助producer 可以直接发送数据到broker,kafka中的节点可以在任何时间来回答一个发送请求中哪些server是存在的,并且主题的分区的主server在哪里。这样,kafka中的每一个节点都可以直接回答该请求。

producer 控制消息发送到哪一个分区。可以通过随机分配来控制,可以实现各种随机算法来进行负载均衡。kafka暴露一个接口给用户,使用户可以指定随机算法。

The producer Asynchronous  Send 

The Comsumer

Kafka Comsumer 从主broker的分区中获取数据。consumber在每一个请求中指定offset,然后从offset 开始获取到一大批数据。

consumber  可以控制offset 的位置,是非常重要的。这样根据需要,可以重置offset 的位置,然后重新消费已经处理过的数据。

The Consumer  Push VS. Pull

一个最初的问题就是消费者应该从broker中拉取数据,还是broker应该把数据从broker从压到comsumer中。在这个处理的方便上,kafka和大部分传统的消息系统一样,

在大部分消息系统中,数据从producer中push到broker中,然后comsumer从broker中pull数据。在一个loggin-centric系统中,例如Scribe和apache Flume系统中,消息时被push到应用程序中。使用push 来推消息,这样既有有点也有缺点。

在push-based推系统中,推消息很难处理形形色色的消费者,因为broker控制着消息的传输和数量。消费者的目的是为了以最大可能的效率来消费这些数据。可惜,不幸运的是在pushed-base系统中,当消费速率处理能力低于生产者的生成速率,那么消费者将被压垮。、

在pull-based 系统中,有更好的属性,消费者仅仅简单的尽情发挥,处理他们能够处理的消息。

pull-based 系统另外一个消息的好处是系统自己本身可以获取自己处理的多条数据。push-based系统即不能及时的发送一条数据,也不能及时的发送多条数据。

因为,push-based不知道下游comsumer 是否有能力立即来处理这些消息。

Consumer  Position 

不断追踪消费的offset 是一个消息系统的关键性能点。

大部分消息系统中,在broker中经常保存着哪些消息已经被消费的原始数据metadata. 当一条消息输出到consumer中时,broker不仅仅要立刻记录,而且还要等到消费者的确认。

这样做是一个非常直观的,因为单个服务器并不知道消息的状态。所以,在很多消息系统中使用数据结构来存储,这样拓展性很差。

这样做也是一个非常使用的选择,因为broker可以知道哪一个消息被消费掉了,可以立即删除这条消息,使存储的数据尽可能小。

也许,把broker和consumer一起来确认消息是否已经被消费了是一个不严重的问题。当每一次broker把一个消息输出到网络中后就立即记录这条消息被消费了,然后,消费者处理这条消息失败了,导致这条消息丢失了。 comsumer 处理失败的原因可能是因为consumer 宕机了,或者comsumer 处理超时等等。

为了解决这个问题,很多消息系统中,增加了一个确认特性。当消息被发送到网层时,消息被标记成了sent状态,而不是comsumed状态。broker这时候等待comsumer来发送一个确认消息,已确认这条消息被消费了,然后更改这个消息的状态为comsumed.

虽然,这种解决办法解决了消息丢失的问题,但是引入的一个新的问题。

第一个,假如,cunsumer 处理这条消息的过程中,但是还未发送确认消息,此时,broker又发送了这条消息,这样,这条消息被消费了两次。

第二个问题是性能方面的问题,现在broker对于每一条消息,必须处理多个状态。