KAFKA设计之CONSUMER

KAFKA CONSUMER

说明

摘自官方文档，自己按照大概意思翻译的
http://kafka.apache.org/documentation/#theconsumer

正文

“推数据”还是“拉数据”

推数据的话，推什么数据和推的频率都要由broker控制，最终我们要达到的目的其实是在最短的时间内消费最多的数据，当推数据的频率很大时，很容易压垮consumer，例如收到攻击的时候。
拉数据的话还可以更积极地处理更多的数据，如果是推数据的话，需要了解下游consumer的状态，同步这些状态信息会造成浪费。
拉数据的缺点如果broker都没有数据了，可是consumer还是需要频繁地去查看broker是否有数据。为了避免这个，可以用参数控制允许consumer请求的频率减小，知道有数据到了broker（或者到broker的数据达到一定量时才处理）
producer会本地存一份，broker再去拉取，就类似是一个“store-and-forward”的角色。当有成千上万个producer时，这种模式推展性就很好，运维起来也不会很难。

消费者的位置

大多数的消息系统都是给了消费者信息后，本地保存一份，然后等到消费者有通知了，更新信息的元数据。这样做很实用，broker一知道消费者的处理状态后马上删除，保持了信息队列的大小。当消息发送出去后，标识为send，收到消费者的处理状态后，标识为consumed。这样解决了消息丢失的问题，但是引入了一个新问题。首先，如果consumer在处理消息完之前就把状态传回去，这样就会导致消息处理了两次。第二个问题是现在broker需要为了消息的多个状态（首先要锁住不传给消费者两次，然后要更新消息状态，再从队列删掉），复杂点的情况是，消息发出去了，然后就再也没有得到消息更新的状态了。
kafka的处理方式是，topic分成了排序好的完整的partitions集合，每一份都可能被订阅了同个消费组的consumer消费，这就意味着每个消费者的位置在每个partitions里面是一个数字，下一个需要消费的消息的偏移量。这样使得“什么被消费了”的这种状态信息量非常小，只是每个partition的一个数字。这个状态可以作为周期性的检查点，消息的确认通知非常小信息量。
还有另一个好处，消费者可以故意回滚到某一个旧的偏移量从新消费消息。例如，消费程序有个bug，可以在修复完bug之后，从新消费整个分配的队列。

离线数据加载

灵活的持久性特性使得消费者可以周期性地批量读取数据，存储到Hadoop或者关系型数据库里面。
对于Hadoop来说，通过map任务并行地加载数据，一个对应一个node/topic/partition联合体，支持全部一起并行地加载。Hadoop还提供任务管理工具，失败的任务可以轻松地从原来的位置继续执行，避免了有产生副本数据的危险。