从未如此简单：10分钟带你逆袭Kafka！( 三 ) 【51CTO.com原创稿件】ApacheKafk

②Kafka 作为消息传递系统：Kafka 的流概念与传统的企业消息传递系统相比如何?
传统上，消息传递具有两种模型：排队和发布订阅。在队列中，一组使用者可以从服务器中读取内容，并且每条记录都将转到其中一个。
在发布-订阅记录中广播给所有消费者。这两个模型中的每一个都有优点和缺点。
排队的优势在于，它允许您将数据处理划分到多个使用者实例上，从而扩展处理量。
不幸的是，队列不是多用户的—一次进程读取了丢失的数据。发布-订阅允许您将数据广播到多个进程，但是由于每条消息都传递给每个订阅者，因此无法扩展处理。
Kafka 的消费者群体概念概括了这两个概念。与队列一样，使用者组允许您将处理划分为一组进程(使用者组的成员) 。与发布订阅一样， Kafka 允许您将消息广播到多个消费者组。
Kafka 模型的优点在于，每个主题都具有这些属性-可以扩展处理范围，并且是多订阅者，无需选择其中一个。
与传统的消息传递系统相比， Kafka 还具有更强的订购保证。传统队列将记录按顺序保留在服务器上，如果多个使用者从队列中消费，则服务器将按记录的存储顺序分发记录。
但是，尽管服务器按顺序分发记录，但是这些记录是异步传递给使用者的，因此它们可能在不同的使用者上乱序到达。
这实际上意味着在并行使用的情况下会丢失记录的顺序。消息传递系统通常通过“专有使用者”的概念来解决此问题，该概念仅允许一个进程从队列中使用，但是，这当然意味着在处理中没有并行性。
Kafka 做得更好，通过在主题内具有并行性(即分区)的概念， Kafka 能够在用户进程池中提供排序保证和负载均衡。
这是通过将主题中的分区分配给消费者组中的消费者来实现的，以便每个分区都由组中的一个消费者完全消费。
通过这样做，我们确保使用者是该分区的唯一读取器，并按顺序使用数据。由于存在许多分区，因此仍然可以平衡许多使用者实例上的负载。但是请注意，使用者组中的使用者实例不能超过分区。
③Kafka 用作流处理：仅读取，写入和存储数据流是不够的，目的是实现对流的实时处理。
在 Kafka 中，流处理器是指从输入主题中获取连续数据流，对该输入进行一些处理并生成连续数据流以输出主题的任何东西。
例如，零售应用程序可以接受销售和装运的输入流，并输出根据此数据计算出的重新订购和价格调整流。
可以直接使用生产者和消费者 API 进行简单处理。但是，对于更复杂的转换， Kafka 提供了完全集成的 Streams API 。
这允许构建执行非重要处理的应用程序，这些应用程序计算流的聚合或将流连接在一起。
该功能有助于解决此类应用程序所面临的难题：处理无序数据，在代码更改时重新处理输入，执行状态计算等。
流 API 建立在 Kafka 提供的核心原语之上：它使用生产者和使用者 API 进行输入，使用 Kafka 进行状态存储，并使用相同的组机制来实现流处理器实例之间的容错。
Kafka 中的关键术语解释
Topic：主题。在 Kafka 中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为 Topic 。 Topic 相当于消息的分类标签，是一个逻辑概念。
物理上不同 Topic 的消息分开存储，逻辑上一个 Topic 的消息虽然保存于一个或多个 Broker 上但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处。
Partition：分区。 Topic 中的消息被分割为一个或多个 Partition ，其是一个物理概念，对应到系统上就是一个或若干个目录。 Partition 内部的消息是有序的，但 Partition 间的消息是无序的。
Segment 段。将 Partition 进一步细分为了若干的 Segment ，每个 Segment 文件的大小相等。
Broker：Kafka 集群包含一个或多个服务器，每个服务器节点称为一个 Broker 。
Broker 存储 Topic 的数据。如果某 Topic 有 N 个 Partition ，集群有 N 个 Broker ，那么每个 Broker 存储该 Topic 的一个 Partition 。
如果某 Topic 有 N 个 Partition ，集群有(N+M)个 Broker ，那么其中有 N 个 Broker 存储该 Topic 的一个 Partition ，剩下的 M 个 Broker 不存储该 Topic 的 Partition 数据。
如果某 Topic 有 N 个 Partition ，集群中 Broker 数目少于 N 个，那么一个 Broker 存储该 Topic 的一个或多个 Partition 。
在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致 Kafka 集群数据不均衡。