KafKa简介

litadi
131 阅读8分钟

消息队列

特点

  1. 解耦
  2. 异步
  3. 削峰

主流消息队列

RabbitMQ

RabbitMQ是一个由Erlang语言开发的基于AMQP标准的开源框架。 RabbitMQ最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。其具体特点包括：

  1. 可靠性,灵活的路由,支持消息集群 高可用性
  2. 支持多种协议(除支持AMQP协议之外，还通过插件的方式支持其他消息队列协议，如STOMP、MQTT)
  3. 支持多语言客户端,提供跟踪机制,提供管理界面
  4. 提供插件机制（RabbitMQ提供了许多插件，也可以编写自己的插件）

提供了比较灵活的消息路由策略、高可用性、可靠性以及丰富的插件、多种平台支持和完善的文档。不过，由于AMQP协议本身导致它的实现比较重量，从而使得与其他MQ (比如Kafka) 对比其吞吐量处于下风。

ActiveMQ

ActiveMQ是由Apache出品的一款开源消息中间件，旨在为应用程序提供高效、可扩展、稳定、安全的企业级消息通信。ActiveMQ实现了JMS 1.1 并提供了很多附加的特性，比如JMX管理、主从管理、消息组通信、消息优先级、延迟接收消息、虚拟接收者、消息持久化、消息队列监控等。主要特性如下：

  1. 支持Java、C、C++、C#、Ruby、Perl、Python、PHP等多种语言的客户端和协议，如OpenWire、STOMP、AMQP、MQTT协议。

  2. 提供了像消息组通信、消息优先级、延迟接收消息、虚拟接收者、消息持久化之类的高级特性。

  3. 完全支持JMS 1.1 和 J2EE 1.4 规范 (包括持久化、分布式事务消息、事务)

  4. 支持Spring框架，ActiveMQ 可以通过Spring 的配置文件方式很容易嵌入Spring应用中。

  5. 通过了常见的J2EE服务器测试，比如TomEE、Geronimo、JBoss、GlassFish、WebLogic。

  6. 连接方式多样化，ActiveMQ 提供了多种连接方式，例如 in-VM、TCP、SSL、NIO、UDP、多播、JGroups、JXTA。

  7. 支持通过使用JDBC 和 Journal 实现消息的快速持久化。

  8. 为高性能集群、客户端-服务器、点对点通信等场景而设计。

  9. 提供了技术和语言中立的REST API 接口。

  10. 支持以AJAX 方式调用 ActiveMQ。

  11. 可以作为内存中的JMS 提供者，非常适合 JMS 单元测试。

Kafka

Kafka 最早是由LinkedIn 公司开发的一种分布式的基于 发布/订阅 的消息系统，后来成为 Apache 的顶级项目。其主要特点如下：

  1. 同时为发布和订阅提供高吞吐量(Kafka 的设计目标是以时间复杂度为 O(1) 的方式提供消息持久化能力的，即使对TB级别以上数据也能保证常数时间的访问性能，即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条消息的传输)

  2. 消息持久化(将消息持久化到磁盘，因此可用于批量消费，例如 ETL 以及实时应用程序。通过将数据持久化到硬盘以及复制可以防止数据丢失。)

  3. 分布式(支持服务器间的消息分区及分布式消费，同时保证每个Partition 内的消息顺序传输。其内部的Producer、Broker 和 Consumer 都是分布式架构，这更易于向外扩展。)

  4. 消费消息采用 Pull 模式。(消息被处理的状态是在 Consumer 端维护的，而不是由服务器端维护，Broker 无状态，Consumer 自己保存offet。)

  5. 支持Online 和 Offline 场景，同时支持离线数据处理和实时数据处理。

RocketMQ

RocketMQ是阿里巴巴于2012年开源的分布式消息中间件，后来捐赠给 Apache软件基金会，并于2017年9月25日成为Apache的顶级项目。作为经历过多次阿里巴巴“双11” 这种“超级工程”的洗礼并有稳定出色表现的国产中间件，以其高性能、低延迟和高可靠等特性近年来被越来越多的国内企业所使用。其主要特点如下：

  1. 具有 灵活的可扩展性。 (RocketMQ 天然支持集群，其核心四大组件(NameServer、Broker、Producer、Consumer)的每一个都可以在没有单点故障的情况下进行水平扩展。)

  2. 具有 海量消息堆积能力。 (RocketMQ 采用零拷贝原理实现了超大量消息的堆积能力，据说单机已经可以支持亿级消息堆积，而且在堆积了这么多消息后依然保持写入低延迟)

  3. 支 持顺序消息。 (RocketMQ 可以保证消息消费者按照消息发送的顺序对消息进行消费。顺序消息分为全局有序消息和局部有序消息，一般推荐使用局部有序消息，即生产者通过将某一类消息按顺序发送至同一个队列中来实现。)

  4. 支持多种消息过滤方式。 (消息过滤分为在服务器端过滤和在消费端过滤。在服务器端过滤时可以按照消息消费者的要求进行过滤，优点是减少了不必要的消息传输，缺点是增加了消息服务器的负担，实现相对复杂。消费端过滤则完全由具体应用自定义实现，这种方式更加灵活，缺点是很多无用的消息会被传输给消息消费者。)

  5. 支持事务消息。 (RocketMQ 除支持普通消息、顺序消息之外，还支持事务消息，这个特性对于分布式事务来说提供了另一种解决思路。）

  6. 支持回溯消费。 (回溯消费是指对于消费者已经消费成功的消息，由于业务需求需要重新消费。RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。)

KafKa基础架构

基础术语

Producer：Producer即生产者，消息的产生者，是消息的入口。
kafka cluster：
Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……
Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。
Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！
Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
Message：每一条发送的消息主体。
Consumer：消费者，即消息的消费方，是消息的出口。
Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！
Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。

工作流程

发送数据

ACK应答机制:

  1. producer往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。
  2. producer往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。
  3. producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。
保存数据+查找

Partition结构

在服务器上的表现形式就是一个一个的文件夹，每个partition的文件夹下面会有多组segment文件，每组segment文件又包含.index文件、.log文件、.timeindex文件三个文件,

log文件就实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息。

Message结构
  1. offset：offset是一个占8byte的有序id号，它可以唯一确定每条消息在parition内的位置！
  2. 消息大小：消息大小占用4byte，用于描述消息的大小。
  3. 消息体：消息体存放的是实际的消息数据（被压缩过），占用的空间根据具体的消息而不一样。
存储策略
  1. 基于时间，默认配置是168小时（7天）。
  2. 基于大小，默认配置是1073741824。
数据查找

segment+有序offset+稀疏索引+二分查找+顺序查找

avatar
文章
阅读
粉丝