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