【消息队列MQ】【Kafka&Jafka】design-1

译自： http://incubator.apache.org/kafka/design.html

六级都没过，你懂的。将就看吧。

Why we built this

         Kafka是一个分布式消息队列系统（MQ），起初是LinkedIn为其实时事件流和队列式连续数据处理做的基础服务。现如今已被广泛地应用于很多公司的数据消息队列处理。

         事件流（Activitystream）就是站点上对各种行为的日常报告，就比如为用户展现了什么，他搜索了什么等等。这些信息一般会被日志系统所处理，然后周期性地收集并进行分析挖掘。业务数据（Operational data）是服务器程序执行过程中的产生的各种服务状态性能等

         目前，事件流和业务数据在站点中的地位越来越重要，是其基础构成的一个重要组成部分。

Use cases for activity stream and operational data

l  向好友广播行为状态资讯；

l  通过收集点击、投票、关注等用户行为为其进行关联计算，比如挖掘你的兴趣爱好；

l  安全：站点需要禁用爬虫，速率限制，屏蔽垃圾邮件等其他保护安全措施；

l  运行监控：站点在运行出错时需要能够实时地监控响应报警；

l  报表和批处理：将数据加载到数据仓库或Hadoop系统，以便进行离线分析以及产生相应的商业报表。

Characteristics of activity stream data

         高通量的事件流极不稳定，可能十倍百倍地变化，这对实时计算过程有很大的挑战。

         传统的日志收集为支持离线计算使其具有大规模和可扩展的特点，就比如报表和批量计算；但对于高性能低延迟的实时计算来说会产生更高的操作复杂性要求。另一个层面来说，实际上现有的消息队列系统基本满足了实时或伪实时系统的功能需求，但是面对大量数据造成数据积累而无法及时消费的情景下，他们的持久化功能做的相当不容乐观。就比如以Hadoop系统数据作为离线消息来源时，他们通常一个小时或一天才周期性地向消息队列注入一次，这很容易产生之前说到的那种情景。而Kafka的目标就是能够成为一个高效的队列平台，无论是处理离线的信息还是在线的信息。

Deployment

         下面给出的是Linkedin的简单拓扑视图：

         可以看出，一个Kafka集群系统可以处理来自不同数据源事件流。为离线和在线用户提供单一的数据通道。在这里，他作为不同事件模块异步处理的中间缓冲层，实现各模块的解藕。同时我们也可以使用Kafka将数据复制为多个副本，来服务于不同的离线消费。

         Kafka集群并没有打算实现跨数据中心，但是他支持混合数据源的拓扑结构。通过数据镜像同步来达到这一目的。这一实现非常简单，通过镜像集群来作为数据源的数据服务者。这也意味着他的动态扩展性。下面的例子是为了支持批量负载的多数据源拓扑结构。

可以看出，两个集群中相应节点并没有一致性保证，他们的规模可能就不同，拥有着不同数量的节点。一个单一的集群可以镜像出任意个簇。更多的使用细节请参照【here】

Major Design Elements

几个主要的设计使其区别与其他消息队列系统：

l  支持持久化；

l  高吞吐，同时权衡情况下也为此牺牲其他方面性能；

l  消费状态保存在客户端，而不是Kafka的服务端；

l  绝对的分布式，可以认为producers,brokers,  consumer都可以分布在不同的机器上

这些特征将在后面具体介绍

Basics

首先是一些基本的属性和概念

 

Messages是通信的基本单元。Message可以被producer发布到一个topic中，这意味着在物理上为它被发送到server的一个broker上。很多的consumer可以订阅同一个topic，然后这个topic上的Message就会分发给所有的订阅此topic的consumer。

 

Kafka的分布式特性：producers,consumers, and brokers可以运行在不同的机器上，并且以此构成一个逻辑上的group。这个对于producers和brokers是显然的，但对于consumers来说则需要一点额外的支持【可参照第二个图】。

         每个consumer会被划分到一个consumers组里。在每个consumers组里由统一的一个进程去给这个组里的每一个consumer分发消息（一个consumer接受了，其他的将不会再接收到）。因此，这个consumers组对于Kafka来说就如一个逻辑上的整体。consumers组的概念是非常有用的，可以在语义上支持queue和topic。

         为支持queue的概念实现，我们可以将consumers放在同一个consumersgroup中，这样，一条message只能独占地被其中一个consumer所消费。

         为支持topic的概念，可以将一个consumer作为一个consumersgroup，这样同一条Message就会被所有的consumers所消费。

【未完待续 2012-08-27】