查看“Kafka”的源代码

[[category:Kafka]]

== 关于 ==
<pre>
对于大数据，我们要考虑的问题有很多，首先海量数据如何收集（如 Flume），然后对于收集到的数据如何存储（典型的分布式文件系统 HDFS、分布式数据库 HBase、NoSQL 数据库 Redis），其次存储的数据不是存起来就没事了，要通过计算从中获取有用的信息，这就涉及到计算模型（典型的离线计算 MapReduce、流式实时计算Storm、Spark），或者要从数据中挖掘信息，还需要相应的机器学习算法。在这些之上，还有一些各种各样的查询分析数据的工具（如 Hive、Pig 等）。除此之外，要构建分布式应用还需要一些工具，比如分布式协调服务 Zookeeper 等等。
</pre>

这里，我们讲到的是消息系统，Kafka 专为分布式高吞吐量系统而设计，其他消息传递系统相比，Kafka 具有更好的'''吞吐量'''，'''内置分区'''，'''复制'''和固有的'''容错'''能力，这使得它非常适合大规模消息处理应用程序。

== 什么是消息系统？ ==
消息系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于数据，但不担心如何共享它。
* 分布式消息传递基于'''可靠消息队列'''的概念。
* 消息在客户端应用程序和消息传递系统之间'''异步排队'''。


有两种类型的消息模式可用：
# 点对点
# 发布订阅（pub-sub）消息系统。 
* 大多数消息模式遵循 pub-sub 。

=== “点对点”消息系统 ===
在点对点系统中，消息被保留在'''队列'''中：
# 一个或多个消费者可以消耗队列中的消息，但是特定消息只能由最多一个消费者消费。
# 一旦消费者读取队列中的消息，它就从该队列中消失。

: [[File:MQ：点对点消息系统.jpg|400px]]

该系统的典型示例是'''订单处理系统'''，其中每个订单将由一个订单处理器处理，但多个订单处理器也可以同时工作。

=== “发布订阅”消息系统 ===
在发布订阅系统中，消息被保留在'''主题'''中：
# 与点对点系统不同，消费者可以订阅一个或多个主题并使用该主题中的所有消息。
# 在发布订阅系统中，消息生产者称为'''发布者'''，消息使用者称为'''订阅者'''。 

: [[File:MQ：发布订阅消息系统.jpg|400px]]

一个现实生活的例子是Dish电视，它发布不同的渠道，如运动，电影，音乐等，任何人都可以订阅自己的频道集，并获得他们订阅的频道时可用。

== 什么是 Kafka？ ==
Apache Kafka是一个'''分布式'''的'''发布订阅'''消息系统和一个强大的'''队列'''【？？？】，可以处理大量的数据，并使您能够将消息从一个端点传递到另一个端点。
# Kafka 适合'''离线和在线消息消费'''。【？？？】
# Kafka 消息保留在'''磁盘'''上，并在'''群集内复制'''以防止数据丢失。
# Kafka 构建在 '''ZooKeeper''' 同步服务之上。 它与 Apache Storm 和 Spark 非常好地集成，用于实时流式数据分析。


好处：
* 可靠性：Kafka是'''分布式'''，'''分区'''，'''复制'''和'''容错'''的。
* 可扩展性：Kafka消息传递系统轻松缩放，无需停机。
* 耐用性：Kafka使用分布式提交日志，这意味着消息会尽可能快地保留在磁盘上，因此它是'''持久'''的。
* 性能：Kafka对于发布和订阅消息都具有'''高吞吐量'''。 即使存储了许多TB的消息，它也保持稳定的性能。
Kafka非常快，并保证零停机和零数据丢失。


用例：
* 指标：Kafka通常用于'''操作监控数据'''。 这涉及聚合来自分布式应用程序的统计信息，以产生操作数据的集中馈送。
* 日志聚合解决方案：Kafka可用于跨组织从多个服务'''收集日志'''，并使它们以标准格式提供给多个服务器。
* 流处理：流行的框架（如Storm和Spark Streaming）从主题中读取数据，对其进行处理，并将处理后的数据写入新主题，供用户和应用程序使用。 【？？？】
** Kafka的强耐久性在流处理的上下文中也非常有用。

=== 为什么需要 Kafka？ ===
<pre>
Kafka是一个统一的平台，用于处理所有实时数据Feed。 Kafka支持低延迟消息传递，并在出现机器故障时提供对容错的保证。 它具有处理大量不同消费者的能力。 Kafka非常快，执行2百万写/秒。 Kafka将所有数据保存到磁盘，这实质上意味着所有写入都会进入操作系统（RAM）的页面缓存。 这使得将数据从页面缓存传输到网络套接字非常有效。
</pre>

Kafka 是一个分布式消息队列，具有'''高性能、持久化、多副本备份、横向扩展能'''力。生产者往队列里写消息，消费者从队列里取消息进行业务逻辑。

一般在架构设计中起到'''解耦'''、'''削峰'''、'''异步'''处理的作用。

== Kafka 关键术语 ==
# 生产者和消费者（producer和consumer）：
#: 消息的发送者叫 Producer，消息的使用者和接受者是 Consumer，生产者将数据保存到 Kafka 集群中，消费者从中获取消息进行业务的处理。
# 代理（'''broker'''）：
#: Kafka 集群中有很多台 Server，其中每一台 Server 都可以存储消息，将'''每一台 Server 称为一个 kafka 实例，也叫做 broker'''。
# 主题（'''topic'''）：
#: 一个 topic 里保存的是同一类消息，相当于对'''消息的分类'''，每个 producer 将消息发送到 kafka 中，都需要指明要存的 topic 是哪个，也就是指明这个消息属于哪一类。
# 分区（'''partition'''）：
#: 每个 '''topic 都可以分成多个 partition'''，每个 partition 在存储层面是 '''append log''' 文件。任何发布到此 partition 的消息都会被直接追加到 log 文件的尾部。
# 偏移量（'''Offset'''）：
#: 一个分区对应一个磁盘上的文件，而'''消息在文件中的位置'''就称为 offset（偏移量），offset 为一个 long 型数字，它可以唯一标记一条消息。由于kafka 并没有提供其他额外的索引机制来存储 offset，文件只能顺序的读写，所以在kafka中几乎不允许对消息进行“随机读写”。


要点:
* Kafka 面向大数据，消息保存在主题中，而每个 topic 有分为多个分区
* kafak 的消息数据保存在磁盘，每个 partition 对应磁盘上的一个文件，消息写入就是简单的文件追加，文件可以在集群内复制备份以防丢失
* 即使消息被消费，kafka 也不会立即删除该消息，可以通过配置使得过一段时间后自动删除以释放磁盘空间【！！！】
* kafka 依赖分布式协调服务 Zookeeper，适合离线/在线信息的消费，与 storm 和 spark 等实时流式数据分析常常结合使用【？？？】

=== 为什么要进行分区呢？ ===
最根本的原因就是：kafka 基于文件进行存储，当文件内容大到一定程度时，很'''容易达到单个磁盘的上限'''，因此，采用分区的办法，一个分区对应一个文件，这样就可以将数据分别存储到不同的server上去，另外这样做也可以负载均衡，容纳更多的消费者。

== Kafka 基本原理 ==
<pre>
Kafka is a distributed,partitioned,replicated commit logservice.
</pre>
Kafka 设计初衷是建立一个统一的信息收集平台，使其可以做到对信息的实时反馈。

=== 分布式和分区（distributed、partitioned） ===






=== 副本（replicated ） ===





=== 整体数据流程 ===




=== 消息传送机制 ===