介绍：

       Kafka是一个高吞吐量的分布是消息系统 ，原本开发自LinkedIn，用作LinkedIn的活动流（activity stream）和运营数据处理管道（pipeline）的基础。现在它已为多家不同类型的公司作为多种类型的数据管道（data pipeline）和消息系统使用。

       现在Kafak作为apache的项目，被apache托管。

企业应用的背景：

       企业集成的基本特点是把企业中现存的本不相干的各种应用进行集成。例如：一个企业可能想把财务系统和仓管系统进行集成，减少部门间结算和流通的成本和时 间，并能更好的支持上层决策。但这两个系统是由不同的厂家做的，不能修改。另外企业集成是一个持续渐进的过程，需求变化非常频繁。这对MQ系统的要求是要 非常灵活，可定制性要求高。所以常见的MQ系统通常都可以通过复杂的xml配置或插件开发进行定制以适应不同企业的业务流程的需要。他们大多数都能通过配 置不同程度的支持EIP中定义一些模式。但设计目标并没有很重视扩展性和性能，因为通常企业级应用的数据流和规模都不会非常大。即使有的比较大，使用高配 置的服务器或做一个简单几个节点的集群就可以满足了。

        大规模的service是指面向公众的向非死book，google，linkedin和taobao这样级别或有可能成长到这个级别的应用。相对企 业集成来讲，这些应用的业务流程相对比较稳定。子系统间集成的业务复杂度也相对较低，因为子系统通常也是经过精心选择和设计的并能做一定的调整。所以对 MQ系统的可定制性及定制的复杂性要求并不高。但由于数据量会非常巨大，不是几台Server能满足的，可能需要几十甚至几百台，且对性能要求较高以降低 成本，所以MQ系统需要有很好的扩展性。

         kafka正是一个满足SaaS要求的MQ系统，它通过降低MQ系统的复杂度来提高性能和扩展性。

使用场景：

• 消息处理。Kafka可以用来替代传统的消息系统。与传统的消息系统相比，Kafka有更好的吞吐量，分隔，复制，负载均衡和容错能力。
• 网页动态跟踪。最初的Kafak就是以管道的方式使用发布订阅的，构建一个用户的活动跟踪系统的管道。
• 运营数据监控。用来作为监控系统运营的数据管道。
• 日志聚合。将不同系统，不同平台的日志聚合到一起做集中处理，很多场景用来做为一个日志聚合的解决方案。
• 流处理。通过对原始数据的聚合，富有化，转化，包装成新的数据，再次发布成消息供以后使用。

可靠性（一致性)

       MQ要实现从producer到consumer之间的可靠的消息传送和分发。传统的MQ系统通常都是通过broker和consumer间的确认 （ack）机制实现的，并在broker保存消息分发的状态。即使这样一致性也是很难保证的（当然kafka也支持ack）。kafka的做法是由 consumer自己保存状态，也不要任何确认。这样虽然consumer负担更重，但其实更灵活了。因为不管consumer上任何原因导致需要重新处 理消息，都可以再次从broker获得。

       kafka的producer有一种异步发送的操作。这是为提高性能提供的。producer先将消息放在内存中，就返回。这样调用者（应用程序）就不 需要等网络传输结束就可以继续了。内存中的消息会在后台批量的发送到broker。由于消息会在内存呆一段时间，这段时间是有消息丢失的风险的。所以使用 该操作时需要仔细评估这一点。 

高可用性

     Kafaka可以将log文件复制到其他topic的分隔点(可以看成是server)。当一个server在集群中fails，可以允许自动的failover到其他的复制的server，所以消息可以继续存在在这种情况下。

扩展性

       kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在 zookeeper注册并保持相关的元数据（topic，partition信息等）更新。而客户端会在zookeeper上注册相关的watcher。 一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。

负载均衡

       负载均衡可以分为两个部分：producer发消息的负载均衡和consumer读消息的负载均衡。

       producer有一个到当前所有broker的连接池，当一个消息需要发送时，需要决定发到哪个broker（即partition）。这是由 partitioner实现的，partitioner是由应用程序实现的。应用程序可以实现任意的分区机制。要实现均衡的负载均衡同时考虑到消息顺序的 问题（只有一个partition/broker上的消息能保证按顺序投递），partitioner的实现并不容易。个人认为这一点还有待改进。

       consumer读取消息时，除了考虑当前的broker情况外，还要考虑其他consumer的情况，才能决定从哪个partition读取消息。具体的机制还不是很清楚，需要做更深入的研究。

性能

        性能是kafka设计重点考虑的因素。使用多种方法来保证稳定的O(1)性能。

        kafka使用磁盘文件保存收到的消息。它使用一种类似于WAL（write ahead log）的机制来实现对磁盘的顺序读写，然后再定时的将消息批量写入磁盘。消息的读取基本也是顺序的。这正符合MQ的顺序读取和追加写特性。 

       另外，kafka通过批量消息传输来减少网络传输，并使用java中的sendfile和0拷贝机制减少从读取文件到发送消息间内存数据拷贝和内核用户态切换的次数。 

       根据kafka的性能测试报告(https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing)，它的性能基本达到了O(1)的复杂度。

一些特点：

• 消息持久化及其缓存更多的依赖文件系统，而不是内存。通过巧妙的顺序读写设计，与内存读写相比，依然很强悍。
• 消息持久化操作的复杂度几乎都是O(1) 。消息系统元数据的持久化数据结构往往采用BTree，通过特别的设计实现。
• 效率最大化。通过调用linux的sendfile系统实现，将数据从文件传输到socket的数据路径从传统的4步减少到2步。
• 端到端的批量压缩。多数情况下系统的瓶颈是网络而不是CPU，支持GZIP和Snappy压缩协议。
• 客户端维护消息状态，而不是broker维护状态。一是，提高消息状态的准确性，二是，将管理成本放到客户端提高borker的性能。
• 消息传递语义。提供几种消息传递保障，满足不通业务场景。如最少发送一次，最多发送一次，只发送一次。
• 生产者和消费者自动负载均衡。Kafka支持客户端负载均衡，也可以使用一个专用的负载均衡器对TCP连接进行负载均衡调整。
• 异步发送。将消息预先存储到内存中，当达到某个阀值的时候，将消息批量发到broker，提高网络利用率。
• 语义分区。可以按照消息中某个键值进行分区，将不同的分区发给各自相应的代理(broker)。默认是随机分区。
• 对Hadoop以及其它批量数据装载的支持。能够周期性将快照数据载入进行批量处理的离线系统，如数据仓库和hadoop集群。

总结

Kafk和其它绝大多数消息系统的区别，是有下面这几个比较重要的设计决策：

1. Kafka在设计之时为就将持久化消息作为通常的使用情况进行了考虑。 
2. 主要的设计约束是吞吐量而不是功能。 
3. 有关哪些数据已经被使用了的状态信息保存为数据使用者（consumer）的一部分，而不是保存在服务器之上。 
4. Kafka是一种显式的分布式系统。它假设，数据生产者（producer）、代理（brokers）和数据使用者（consumer）分散于多台机器之上。 

     

附：Kafka在LinkedIn中的应用：

在LinkedIn中部署后的各系统形成的拓扑结构

下面的示意图所示是在LinkedIn中部署后各系统形成的拓扑结构。

要注意的是，一个单个的Kafka集群系统用于处理来自各种不同来源的所有活动数据。它同时为在线和离线的数据使用者提供了一个单个的数据管道，在线活动 和异步处理之间形成了一个缓冲区层。我们还使用kafka，把所有数据复制（replicate）到另外一个不同的数据中心去做离线处理。

我们并不想让一个单个的Kafka集群系统跨越多个数据中心，而是想让Kafka支持多数据中心的数据流拓扑结构。这是通过在集群之间进行镜像或“同步” 实现的。这个功能非常简单，镜像集群只是作为源集群的数据使用者的角色运行。这意味着，一个单个的集群就能够将来自多个数据中心的数据集中到一个位置。下 面所示是可用于支持批量装载（batch loads）的多数据中心拓扑结构的一个例子：

请注意，在图中上面部分的两个集群之间不存在通信连接，两者可能大小不同，具有不同数量的节点。下面部分中的这个单个的集群可以镜像任意数量的源集群。要了解镜像功能使用方面的更多细节。

来自：http://blog.csdn.net/shifenglov/article/details/40818711