Kafka可靠性的思考

首先kafka的throughput 

接着主要谈一下，kafka的可靠性问题，有哪些机会可能丢数据？

从producer，broker，consumer的角度，分别看看

a. producer到broker

    把request.required.acks设为1，丢会重发，丢的概率很小

b. broker

    b.1 对于broker，落盘的数据，除非磁盘坏了，不会丢的

    b.2 对于内存中没有flush的数据，broker重启会丢 

        可以通过log.flush.interval.messages和log.flush.interval.ms来配置flush间隔，interval大丢的数据多些，小会影响性能 

        但在0.8版本，可以通过replica机制保证数据不丢，代价就是需要更多资源，尤其是磁盘资源，kafka当前支持gzip和snappy压缩，来缓解这个问题 

        是否使用replica取决于在可靠性和资源代价之间的balance

c. consumer

    和其他的平台不同的是，其实kafka真正比较复杂的是consumer，kafka有两种consumer

    c.1 high-level consumer

    这个使用比较简单，已经封装了对partition和offset的管理，默认是会定期自动commit offset，这样可能会丢数据的，因为consumer可能拿到数据没有处理完crash 

    之前我们在0.7上是使用这个接口的，为了保证不丢数据，把自动commit关掉，consumer处理完所有数据，再手动commit，这样丢数据的概率比较小

    对于storm，没法这样做，因为spout是会预读大量数据的，当然只要spout线程不crash，也是可以保证这些数据基本不会丢失（通过storm的acker机制） 

    但如果spout线程crash，就会丢数据 

    所以high-level接口的特点，就是简单，但是对kafka的控制不够灵活

    c.2 simple consumer，low-level

    这套接口比较复杂的，你必须要考虑很多事情，优点就是对kafka可以有完全的控制 

    you must keep track of the offsets in your application to know where you left off consuming. 

    you must figure out which broker is the lead broker for a topic and partition 

    you must handle broker leader changes

    在考虑如何将storm和kafka结合的时候，有一些开源的库，基于high-level和low-level接口的都有

    我比较了一下，还是kafka官方列的storm-kafka-0.8-plus比较靠谱些 

    这个库是基于simple consumer接口实现的，看着挺复杂，所以我先读了遍源码，收获挺大，除了发现我自己代码的问题，还学到些写storm应用的技巧呵呵

    这个库会自己管理spout线程和partition之间的对应关系和每个partition上的已消费的offset(定期写到zk) 

    并且只有当这个offset被storm ack后，即成功处理后，才会被更新到zk，所以基本是可以保证数据不丢的 

    即使spout线程crash，重启后还是可以从zk中读到对应的offset

so, 结论就是kafka和storm的结合可靠性还是可以的，你真心不想丢数据，还是可以做到的 

kafka只是能保证at-least once逻辑，即数据是可能重复的，这个在应用上需要可以容忍 

当然通过storm transaction也是可以保证only once逻辑的，但是代价比较大，后面如果有这样的需求可以继续深入调研一下 

对于kafka consumer，一般情况下推荐使用high-level接口，最好不要直接使用low-level，太麻烦

当前其实kafka对consumer的设计不太到位，high-level太不灵活，low-level又太难用，缺乏一个medium-level 

本文章摘自博客园，原文发布日期：2014-06-26