首先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