Kafka消息队列

Kafka 是分布式发布-订阅消息系统,它最初由 LinkedIn 公司开发, 现在是Apache旗下的一个子项目， 并且已经成为开源领域应用最广泛的消息系统之一。

Kafka官网

基本介绍

Apache Kafka 是一个 分布式消息发布订阅 系统。它最初由 LinkedIn 公司基于独特的设计实现为一个 分布式的日志提交系统 (a distributed commit log)，之后成为 Apache 项目的一部分。Kafka 性能高效、可扩展良好 并且 可持久化。它的 分区特性，可复制 和 可容错 都是其不错的特性。

Kafka 使用 由 Scala 和 Java 语言编写。 在Kafka集群中，没有“中心主节点”的概念，集群中所有的服务器都是对等的，因此，可以在不做任何配置的更改的情况下实现服务器的的添加与删除，同样的消息的生产者和消费者也能够做到 随意重启 和机器的上下线。

可能讲了这么多，都已经看晕了，网上有一个介绍 kafka 的小故事，我认为不错，给大家推荐一下。

举个例子:

生产者消费者，生产者生产鸡蛋，消费者消费鸡蛋，生产者生产一个鸡蛋，消费者就消费一个鸡蛋，假设消费者消费鸡蛋的时候噎住了（系统宕机了），生产者还在生产鸡蛋，那新生产的鸡蛋就丢失了。再比如生产者很强劲（大交易量的情况），生产者1秒钟生产100个鸡蛋，消费者1秒钟只能吃50个鸡蛋，那要不了一会，消费者就吃不消了（消息堵塞，最终导致系统超时），消费者拒绝再吃了，”鸡蛋“又丢失了，这个时候我们放个篮子在它们中间，生产出来的鸡蛋都放到篮子里，消费者去篮子里拿鸡蛋，这样鸡蛋就不会丢失了，都在篮子里，而这个篮子就是”kafka“。鸡蛋其实就是“数据流”，系统之间的交互都是通过“数据流”来传输的（就是tcp、http什么的），也称为报文，也叫“消息”。消息队列满了，其实就是篮子满了，”鸡蛋“ 放不下了，那赶紧多放几个篮子，其实就是kafka的扩容。各位现在知道kafka是干什么的了吧，它就是那个"篮子"

主要特性

• 快速持久化：可以在系统开销下进行 消息持久化；
• 高吞吐：在一台普通的服务器上既可以达到 10W/s 的 吞吐速率；
• 完全的分布式系统：Broker、Producer 和 Consumer 都原生自动支持 分布式，自动实现 负载均衡；
• 支持 同步 和 异步 复制两种 高可用机制；
• 支持 数据批量发送 和 拉取；
• 零拷贝技术(zero-copy)：减少 IO 操作步骤，提高 系统吞吐量；
• 数据迁移、扩容 对用户透明；
• 无需停机 即可扩展机器；
• 其他特性：丰富的 消息拉取模型、高效 订阅者水平扩展、实时的 消息订阅、亿级的 消息堆积能力、定期删除机制；

术语介绍

• 消息生产者：即：Producer，是消息的产生的源头，负责生成消息并发送到 Kafka 服务器上。
• 消息消费者：即：Consumer，是消息的使用方，负责消费Kafka服务器上的消息。
• 主题：即：Topic，由用户定义并配置在Kafka服务器，用于建立生产者和消息者之间的订阅关系：生产者发送消息到指定的Topic下，消息者从这个Topic下消费消息。
• 消息分区：即：Partition，一个Topic下面会分为很多分区，例如：“kafka-test”这个Topic下可以分为6个分区，分别由两台服务器提供，那么通常可以配置为让每台服务器提供3个分区，假如服务器ID分别为0、1，则所有的分区为0-0、0-1、0-2和1-0、1-1、1-2。Topic物理上的分组，一个 topic可以分为多个 partition，每个 partition 是一个有序的队列。partition中的每条消息都会被分配一个有序的 id（offset）。
• Broker：即Kafka的服务器，用户存储消息，Kafa集群中的一台或多台服务器统称为 broker。
• 消费者分组(ConsumerGroup)：Group，用于归组同类消费者，在Kafka中，多个消费者可以共同消息一个Topic下的消息，每个消费者消费其中的部分消息，这些消费者就组成了一个分组，拥有同一个分组名称，通常也被称为消费者集群
• Offset：消息存储在Kafka的Broker上，消费者拉取消息数据的过程中需要知道消息在文件中的偏移量，这个偏移量就是所谓的Offset。

部署环境

Kafka 支持 windows 和 linux，或类 Unix 系统。

部署 Kafka 需要：

• Java JDK
• Kafka 安装包

优点

• 客户端语言丰富：支持 Java、.Net、PHP、Ruby、Python、Go 等多种语言；
• 高性能：单机写入 TPS 约在 100 万条/秒，消息大小 10 个字节；
• 提供 完全分布式架构，并有 replica 机制，拥有较高的 可用性 和 可靠性，理论上支持 消息无限堆积；
• 支持批量操作；
• 消费者 采用 Pull 方式获取消息。消息有序，通过控制 能够保证所有消息被消费且仅被消费 一次；
• 有优秀的第三方 Kafka Web 管理界面 Kafka-Manager；
• 在 日志领域 比较成熟，被多家公司和多个开源项目使用。

缺点

• Kafka 单机超过 64 个 队列/分区 时，Load 时会发生明显的飙高现象。队列 越多，负载 越高，发送消息 响应时间变长；
• 使用 短轮询方式，实时性 取决于 轮询间隔时间；
• 消费失败 不支持重试；
• 支持 消息顺序，但是 一台代理宕机 后，就会产生 消息乱序；
• 社区更新较慢