Kafka可靠性的思考

转自：http://www.cnblogs.com/fxjwind/p/3810740.html?utm_source=tuicool&utm_medium=referral

 附kafka consumer防止数据丢失：http://www.fwqtg.net/kafka-consumer%E9%98%B2%E6%AD%A2%E6%95%B0%E6%8D%AE%E4%B8%A2%E5%A4%B1-%E5%8D%9A%E5%AE%A2%E5%88%86%E7%B1%BB%EF%BC%9A-kafka-kafkaoffset-commit.html

首先kafka的throughput 
很牛逼，参考：http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines

 

接着主要谈一下，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 
所以在0.9中consumer会被重新design，https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Client+Re-Design