问题导读
1.Kafka的设计基本思想是什么？
2.Kafka消息转运过程中是如何确保消息的可靠性的？
本节主要从整体角度介绍Kafka的设计思想，其中的每个理念都可以深入研究，以后我可能会发专题文章做深入介绍，在这里只做较概括的描述以便大家更好的理解Kafka的独特之处。本节主要涉及到如下主要内容：
- Kafka设计基本思想
- Kafka中的数据压缩
- Kafka消息转运过程中的可靠性
- Kafka集群镜像复制
- Kafka 备份机制
一、kafka由来 由于对JMS日常管理的过度开支和传统JMS可扩展性方面的局限，LinkedIn(www.linkedin.com)开发了Kafka以满足他们对实时数据流的监控以及对CPU、IO利用率等指标的高要求。在Linkedin开发Kafka之初，把关注重点集中在了这几个方面：
- 为生产者和消费者提供一个通用的API
- 消息的持久化
- 高吞吐量，可以满足百万级别消息处理
- 对分布式和高扩展性的支持
二、基本思想
一个最基本的架构是生产者发布一个消息到Kafka的一个主题（topic），这个主题即是由扮演KafkaServer角色的broker提供，消费者订阅这个主题，然后从中获取消息，下面这个图可以更直观的描述这个场景：
四、消息转运过程中的可靠性
在消息系统中，保证消息在生产和消费过程中的可靠性是十分重要的，在实际消息传递过程中，可能会出现如下三中情况：
- 一个消息发送失败
- 一个消息被发送多次
- 最理想的情况：exactly-once ,一个消息发送成功且仅发送了一次
有许多系统声称它们实现了exactly-once，但是它们其实忽略了生产者或消费者在生产和消费过程中有可能失败的情况。比如虽然一个Producer成功发送一个消息，但是消息在发送途中丢失，或者成功发送到broker，也被consumer成功取走，但是这个consumer在处理取过来的消息时失败了。
从Producer端看：Kafka是这么处理的，当一个消息被发送后，Producer会等待broker成功接收到消息的反馈（可通过参数控制等待时间），如果消息在途中丢失或是其中一个broker挂掉，Producer会重新发送（我们知道Kafka有备份机制，可以通过参数控制是否等待所有备份节点都收到消息）。
从Consumer端看：前面讲到过partition，broker端记录了partition中的一个offset值，这个值指向Consumer下一个即将消费message。当Consumer收到了消息，但却在处理过程中挂掉，此时Consumer可以通过这个offset值重新找到上一个消息再进行处理。Consumer还有权限控制这个offset值，对持久化到broker端的消息做任意处理。
五、mirror一个Kafka集群
关于Kafka集群的mirror，参考下面这幅图：六、备份机制
备份机制是Kafka0.8版本的新特性，备份机制的出现大大提高了Kafka集群的可靠性、稳定性。有了备份机制后，Kafka允许集群中的节点挂掉后而不影响整个集群工作。一个备份数量为n的集群允许n-1个节点失败。在所有备份节点中，有一个节点作为lead节点，这个节点保存了其它备份节点列表，并维持各个备份间的状体同步。下面这幅图解释了Kafka的备份机制：
|
|
具体细节请参考：https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Replication
转自：http://www.aboutyun.com/thread-11116-1-1.html