@[toc]

说明

• 当前大数据开发流程，从最初的批处理到流处理再到流批一体，技术方案也从MapReduce到spark在到flink，那么如何将实时数据稳定、高效、灵活的传送到计算引擎里呢，这里必须使用到分布式消息引擎kafka。

kafka简介

什么是kafka

• kafka最初由LinkedIn使用Scala进行开发，后来使用Java重写Producer API、Consumer API，2011年初加入Apache开源项目，2012年10月从Apache Incubator毕业，成为Apache顶级项目，即Apache Kafka。
• kafka独立于hadoop之外，支持独立和分布式安装，分布式控制中心统一由zookeeper担任，所以安装时，必须安装zookeeper。
• 官网

kafka高吞吐率实现

• 为了增加存储能力，Kafka将所有的消息都写入到了低速大容量的硬盘。Kafka采用以下方式实现高吞吐率：
  • 顺序读写：Kafka将消息顺序追加到Partition中，顺序读写要快于随机读写。
  • Zero Copy：Kafka的生产者、消费者API对于Kafka消息采用零拷贝实现。Java类库通过java.nio.channels.FileChannel中的transferTo()方法(底层sendfile系统调用)在Linux和UNIX系统上支持Zero Copy，内核直接将数据从磁盘文件拷贝到Socket套接字，而无需通过应用程序。
  • 批量发送：Kafka允许批量发送模式。
  • 消息压缩：Kafka允许对消息集合进行压缩。
  • 操作系统页缓存：不直接写IO，直接写入页缓存；消费时大多命中缓存。

kafka消息传递模式

点对点模型

• 基于拉取或轮询的消息传送模型，由消费者主动拉取数据，客户端需要持续开启独立线程监控队列中是否有数据。
• 在点对点的消息系统中，消息保留在队列中， 一个或多个消费者可以同时工作，但最终只有一个消费者可以消费消息。典型实例如订单处理系统，多个订单处理器可以同时工作，但对于一个特定的订单，只有其中一个订单处理器可以拿到并进行处理。

发布/订阅模型

• 基于推送的消息传送模型，由MQ主动推送消息给所有订阅者，即使某个订阅者不可用。
• 在发布-订阅系统中，消息被保留在主题中。消费者可以订阅一个或多个主题并使用主题中的所有消息。在发布-订阅系统中，消息生产者称为发布者，消息消费者称为订阅者。

kafka优点

• 解耦：解耦业务处理过程，两端业务流程仅通过消息API通信，两端程序可独立升级。
• 冗余：消息默认进行持久化，直到消息被完全处理，规避数据丢失风险。
• 扩展性：kafka支持动态扩容，缓解集群压力。
• 可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
• 顺序保证：Kafka保证一个Partition内的消息的有序性。
• 缓冲：消息队列通过一个缓冲层来帮助任务最高效率的执行，写入队列的处理会尽可能的快速。缓冲有助于控制和优化数据流经过系统的速度。
• 异步通信：消息队列提供了异步处理机制，允许用户把消息放入队列，但并不立即处理，在需要时再处理。

kafka架构

架构图

主要构成

Record

• Record即Kafka消息，是Kafka处理的主要对象。

TOPIC

• Topic是承载Kafka消息数据的逻辑容器，用于区分具体的业务，但在物理上，不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存在一个或多个Broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存储在何处。

partition

• Topic被分割为一个或多个Partition，Partition是一个物理概念，对应一个或若干个目录。Partition内部的消息是有序的，Partition间的消息是无序的。
• Kafka Broker配置文件中的num.partitions参数用于指定Topic的Partition数量，在创建Topic时也可以通过partitions参数指定Partition数量。

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集群数据不均衡。

producer

• Producer（生产者）是消息的发布者，生产者负责选择将消息数据分配给Topic中的某个分区，即生产者生产的每一条消息，会被写入到某一个Partition。

Consumer

• Consumer（消费者）从Broker中消费消息，一个Consumer可以消费多个Topic的消息，也可以消费同一个Topic中的多个Partition中的消息，Partition允许多个Consumer同时消费，以提高Kafka Broker的吞吐量。

Consumer Group

• Consumer Group是Kafka提供的可扩展且具有容错性的消费者机制，多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。Consumer Group内可以有多个消费者，共享一个公共的ID，即Group ID，Consumer Group内的所有消费者协调在一起来消费订阅Topic的所有分区。

• Kafka保证同一个Consumer Group中只有一个Consumer会消费某条消息，Kafka保证的是稳定状态下每一个Consumer 实例只会消费某一个或多个特定的Partition，而某个Partition的数据只会被某一个特定的Consumer实例所消费。

• 如上图，两台Broker组成的Kafka群集，包含四个属于两个Consumer Group的分区（P0-P3）。Consumer Group A有两个消费者实例，Consumer Group B有四个消费者实例。

partition Replica

• Replica（分区副本）为了防止消息丢失而创建的分区备份。Kafka中同一条消息能够被拷贝到多个地方以提供数据冗余。副本分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。

Partition Leader

• 每个Partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责消息读写的Partition，所有读写操作只能发生于Leader分区上。

Partition Follower

• 用于同步Leader和Replica消息，保持消息同步。Leader与Follower的关系是主备关系，而非主从。

Zookeeper

• Apache Zookeeper是一个分布式配置和同步服务，是Kafka的一个核心依赖，它是Broker和Consumer之间的协调接口。Broker在Zookeeper中存储基本元数据，通过Zookeeper集群共享信息，例如主题、代理、消费者偏移(队列读取器)等的信息。Zookeeper负责维护和协调Broker以及Broker Controller的选举。
• Kafka 0.9版本前，offset（消息位移）由Zookeeper负责管理。

应用场景

存储系统

• Kafka是一个非常好的存储系统，写入Kafka的数据将写入磁盘并进行复制以实现容错功能。Kafka允许生产者等待确认，以便直到完全复制并确保即使写入服务器失败的情况下写入也不会完成。
• Kafka会认真对待存储并允许客户端控制其读取位置，因此可以将Kafka视为一种专用于高性能、低延迟，提供日志存储、复制和传播的专用分布式文件系统。

消息传递系统

• 消息传递具有排队和发布-订阅两种模型。
  • 排队模型中，一组使用者可以从服务器中读取内容，并且每条记录都将转到其中一个。
    • 优点：允许将数据处理划分到多个使用者实例上，扩展处理能力。
    • 缺点：队列不是多用户的。
  • 发布-订阅模型中，消息会广播给所有消费者
    • 优点：允许将数据广播到多个进程。
    • 缺点：每条消息都传递给每个订阅者，因此无法扩展处理。
• Kafka的Consumer Group融合了排队模型和发布订阅模型的优点，Consumer Group允许将处理划分为一组进程（Consumer Group的成员），Kafka允许将消息广播到多个Consumer Group。
• 传统队列将消息按顺序保留在服务器上，如果多个消费者从队列中消费，则服务器将按记录的存储顺序分发记录。尽管服务器按顺序分发消息，但消息是异步传递给消费者的，因此消息可能在不同的消费者上乱序到达，即在并行使用的情况下消息会乱序。
• Kafka在Topic内具有并行性（即Partition），通过将Topic中的Partition分配给Consumer Group中的消费者，每个分区都由Consumer Group中的一个消费者完全消费，Kafka能够在用户进程池中提供排序保证和负载均衡。Consumer Group中的消费者实例数量不能超过分区数量。

流处理

• 流处理器是指从数据源获取连续数据流，对输入进行一些处理并生成连续数据流以输出指定业务的任何东西。
• Kafka提供了完全集成的Streams API，允许构建执行非重要处理的应用程序，流处理API建立在Kafka提供的核心原语上，使用生产者和使用者API进行输入，使用Kafka进行状态存储，并使用相同的组机制来实现流处理器实例之间的容错。
• 轻量级可使用，核心重要处理不建议使用。

同类型比对

Flume

• Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力，过程依赖于hadoop，操作过程基于channel（大多基于内存），资源占用较大，巨量数据处理时，效率不高。
• 实际使用体验，兼顾采集和轻量化的数据处理，既采集数据又计算处理，个人两种场景能力都一般，建议使用功能专一组件，kafka+flink或kafka+spark。

RabbitMQ

• RabbitMQ是使用Erlang编写的一个开源的重量级企业级消息队列，本身支持很多的协议：AMQP、XMPP、SMTP、STOMP。RabbitMQ实现了Broker构架，消息在发送给客户端时先在中心队列排队，对路由、负载均衡或者数据持久化支持很好。

Redis

• Redis是一个基于Key-Value对的NoSQL数据库，但支持MQ功能，可以作为轻量级的MQ使用。入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过10K，Redis较慢；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

ZeroMQ

• ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但开发人员需要自己组合多种技术框架，技术上的复杂度是对ZeroMQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，不需要安装和运行消息服务器或中间件，应用程序会扮个服务器角色，但ZeroMQ仅提供非持久性的队列。

ActiveMQ

• ActiveMQ能够以代理人和点对点的技术实现队列，少量代码就可以高效地实现高级应用场景。

RocketMQ

• Apache RocketMQ是阿里开源的纯Java实现的分布式消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。
• 不建议使用，可能断更可参考Dubbo

总结

• 流处理是大数据未来趋势，网络发达个人数据剧增的当下，实时加载算法分析处理用户数据，如广告精确推送、影视推荐、个人画像、异常访问分析等，都有很大需要，数据的核心价值是信息，而实时计算能加强这种价值。
• 学海无涯，任重道远，加油。