kafka延迟队列（kafka延迟队列使用）

本篇文章给大家谈谈kafka延迟队列，以及kafka延迟队列使用对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、延时队列常用实现详解
• 2、网易传媒技术团队：消息中间件实现延迟队列的应用与实践
• 3、Kafka-概述
• 4、消息队列原理及选型

延时队列常用实现详解

队列是一种线性表，内部的元素是有序的，具有先进先出的特性。

延时队列，顾名思义，它是一个队列，但更重要的是具有延时的特性，与普通队列的先进先出不同，延时队列可以指定队列中的消息在某个时间点被消费。

DelayQueue是无界的延时阻塞队列，内部是使用优先级队列PriorityQueue实现的,其是按时间来定优先级的延时阻塞队列，只有在延迟期满时才能从队列中提取元素，先过期的元素会在队首，每次从队列里取出来都是最先要过期的元素， 当执行队列take操腔侍作元素未过期时会阻塞当前线程到元素过期为止 ；PriorityQueue是通过二叉小顶堆实现， 其任意一个非叶子节点的权值，都不大于其左右子节点的权值。

示例

队列中的元素必须实现Delayed接口

redis key的过期事件是通过redis 2.8.0之后版本提供的订阅发布功能（pub/sub）下发的，当key过期后系统自动Pub，应用程序只需订阅(sub)该事件即可。

实现步骤

示例

存在的问题

key的失效通知无法保证时效性。redis过期策略有一下三种：

默认情况下，Redis 使用的是 惰性删除 + 定期删除 的策略；每隔一段时间(可通过hz参数设置每秒执行的次数)，Redis 会分别从各个库随机选取部分测试设置了过期时誉知间的 Key，判断它们是否过期，过期则删除；如果 key 已过期，但没有被定期删除，由于惰性删除策略，在下次请求获取该数据时会将该数据删除。

可通过如下方式提高时效性

redis zset 结构是一个有序集合，每个元素都会关联一个 double 类型的分数，通过分数来为集合中的成员进行从小到大的排序；有序集合的成员是唯一的,但分数(score)却可以重复。

实现思路

将任务id作为member,到期时间作为score存入到zset中，然后不断轮询获取第一个元素，判断其是否过期，过期后删除并执行任务即可。

也可以通过lua脚本将 zrangebyscore 和 zrem 操作变成原子操作，避免了多线程时同一个me mber多次zrem。

存在的问题

RabbitMQ本身没有直接支持延迟队列功能，但是可以通过ttl及dlx(Dead Letter Exchanges)特性模拟出延迟队列的功能。

绑定在死信交换机上的队列。RabbitMQ的Queue（队列）可以配置两个参数x-dead-letter-exchange（死信交换机）和x-dead-letter-routing-key（指定routing-key发送，可选），当消息在一个队列中变成死信 (dead message) 之后，按照这两个参数可以将消息重新路由到另一个DLX Exchange（死信交换机），让消息重新被消费。

队列出现Dead Letter的情况有：

RabbitMQ可以对消息和队列设置TTL，为队列设置时，队列中所有消息都有相同的过期时间；对消息进行单独设置，每条消息过期时间可以不同；如果同时设置了队列的ttl和消息的ttl以两者之间TTL较小的那个数值为准。消息超过设置的ttl值未被消费，将会变为死信，消费者将无法再收到该消息。

ttl消息按照入发送顺序排列在队列中，且rabbitMQ只会判断队列头消息是否失效，失效后才会加入到死信队列中，如果发送多个过期时间不一致的消息，有可能后面的消息已经过期了，但队列头消息没有过期，导致其他消息不能及时加入到死信队列被消费。

针对上述的问题，可以使用 rabbitmq_delayed_message_exchang 插件来解决。

安装该插庆圆消件后会生成新的Exchange类型 x-delayed-message ，该类型消息支持延迟投递机制,接收到消息后并未立即将消息投递至目标队列中，而是存储在 mnesia (一个分布式数据系统)表中，检测消息延迟时间（通过消息头的x-delay指定），如达到可投递时间时并将其通过 x-delayed-type 类型标记的交换机类型投递至目标队列。

插件的安装

使用示例

插件的局限

时间轮的应用广泛，包括linux内核的调度、zookeeper、netty、kafka、xxl-job、quartz等均有使用时间轮。

图中的圆盘可以看作是钟表的刻度。比如一圈round长度为24秒，刻度数为8，那么每一个刻度表示3秒。那么时间精度就是3秒。每个刻度为一个bucket(实际上就是TimerTaskList)，TimerTaskList是环形双向链表，在其中链表项TimeTaskEntry封装了真正的定时任务TimerTask。TimerTaskList使用expiration字段记录了整个TimerTaskList的超时时间。TimeTaskEntry中的expirationMs字段记录了超时时间戳，timerTask字段指向了对应的TimerTask任务；根据每个TimerTaskEntry的过期时间和当前时间轮的时间，选择一个合适的bucket,把这个TimerTaskEntry对象放进去；对于延迟超过时间轮所能表示的范围有两种处理方式，一是通过增加一个字段-轮数，Netty 就是这样实现的；二是多层时间轮，Kakfa 是这样实现的。

下面介绍下kafka的多层时间轮，层数越高时间跨度越大。

每个使用到的TimerTaskList都会加入到DelayQueue中，DelayQueue会根据TimerTaskList对应的超时时间expiration来排序，最短expiration的TimerTaskList会被排在DelayQueue的队头，通过一个线程获取到DelayQueue中的超时的任务列表TimerTaskList之后，既可以根据TimerTaskList的expiration来推进时间轮的时间，也可以就获取到的TimerTaskList执行相应的操作，TimerTaskEntry该执行过期操作的就执行过期操作，该降级时间轮的就降级时间轮。

假设现在有一个任务在445ms后执行，默认情况下，各个层级的时间轮的时间格个数为20，第一层时间轮每一个时间格跨度为1ms,整个时间轮跨度为20ms,跨度不够。第二层时间轮每一个时间格跨度为20ms,整个时间轮跨度为400ms,跨度依然不够，第三层时间轮每一个时间格跨度为400ms,整个时间轮跨度为8000ms，现在跨度够了，此任务就放在第三层时间轮的第一个时间格对应的TimerTaskList，等待被执行，此TimerTaskList到期时间是400ms,随着时间的流逝，当此TimerTaskList到期时，距离该任务到期时间还有45ms，不能执行该任务，将重新提交到时间轮，此时第一层时间轮跨度依然不够，不能执行任务，第二层时间轮时间格跨度为20，整个世间轮跨度为400，跨度足够，放在第三个时间格等待执行，如此往复几次，高层时间轮最终会慢慢移动到低层时间轮上，最终任务到期执行。

网易传媒技术团队：消息中间件实现延迟队列的应用与实践

早期需要延迟处理的业务场景，更多的是通过定时任务扫表，然后执行满足条件的记录，具有频率高、命中低、资源消耗大的缺点。随着消息中间件的普及，延迟消息可以很好的处理这种场景，本文主要介绍延迟消息的使用场景以及基于常见的消息中间件如何实现延迟队列，最后给出了一个在网易公开课使用延迟队列的实践。

1、有效期：限时活动、拼团。。。

2、超时处理：取消超时未支付订单、差陆空超时自动确认收货。。。

4、重试：网络异常重试、打车派单、依赖条件未满足重试。。。

5、悉猜定时任务：智能设备定时启动。。。

1、RabbitMQ

1）简介：基于AMQP协议，使用Erlang编写，实现了一个Broker框架

a、Broker：接收和分发消息的代理服务器

b、Virtual Host：虚拟主机之间相互隔离，可理解为一个虚拟主机对应一个消息服务

c、Exchange：交换机，消息发送到指定虚拟机的交换机上

d、Binding：交换机与队列绑定，并通过路由策略和routingKey将消息投递到一个或多个队列中

e、Queue：存放消息的队列，FIFO，可持久化

f、Channel：信道，消费者通过信道消费消息，一个TCP连接上可同时创建成百上千个信道，作为消息隔离

2）延迟队列实现：RabbitMQ的延迟队列基于消息的存活时间TTL（Time To Live）和死信交换机DLE（Dead Letter Exchanges）实现

a、TTL：RabbitMQ支持对队列和消息各自设置存活时间，取二者中较小的值，即队列无消费者连接或消息在队列中一直未被消费的过期时间

b、DLE：过期的消息通过绑定的死信交换机，路由到指定的死信队列，消费者实际上消费的是死信队列上的消息

3）缺点：

a、配置麻烦，额外增加一个死信交换机和一个死信队列的配置

b、脆弱性，配置错误或者生产者消费者连接的队虚瞎列错误都有可能造成延迟失效

2、RocketMQ

1）简介：来源于阿里，目前为Apache顶级开源项目，使用Java编写，基于长轮询的拉取方式，支持事务消息，并解决了顺序消息和海量堆积的问题

a、Broker：存放Topic并根据读取Producer的提交日志，将逻辑上的一个Topic分多个Queue存储，每个Queue上存储消息在提交日志上的位置

b、Name Server：无状态的节点，维护Topic与Broker的对应关系以及Broker的主从关系

2）延迟队列实现：RocketMQ发送延时消息时先把消息按照延迟时间段发送到指定的队列中(rocketmq把每种延迟时间段的消息都存放到同一个队列中)，然后通过一个定时器进行轮训这些队列，查看消息是否到期，如果到期就把这个消息发送到指定topic的队列中

3）缺点：延迟时间粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）

3、Kafka

1）简介：来源于Linkedin，目前为Apache顶级开源项目，使用Scala和Java编写，基于zookeeper协调的分布式、流处理的日志系统，升级版为Jafka

2）延迟队列实现：Kafka支持延时生产、延时拉取、延时删除等，其基于时间轮和JDK的DelayQueue实现

a、时间轮(TimingWheel)：是一个存储定时任务的环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表

b、定时任务列表(TimerTaskList)：是一个环形的双向链表，链表中的每一项表示的都是定时任务项

c、定时任务项(TimerTaskEntry)：封装了真正的定时任务TimerTask

d、层级时间轮：当任务的到期时间超过了当前时间轮所表示的时间范围时，就会尝试添加到上层时间轮中，类似于钟表就是一个三级时间轮

e、JDK DelayQueue：存储TimerTaskList，并根据其expiration来推进时间轮的时间，每推进一次除执行相应任务列表外，层级时间轮也会进行相应调整

3）缺点：

a、延迟精度取决于时间格设置

b、延迟任务除由超时触发还可能被外部事件触发而执行

4、ActiveMQ

1）简介：基于JMS协议，Java编写的Apache顶级开源项目，支持点对点和发布订阅两种模式。

a、点对点（point-to-point）：消息发送到指定的队列，每条消息只有一个消费者能够消费，基于拉模型

b、发布订阅（publish/subscribe）：消息发送到主题Topic上，每条消息会被订阅该Topic的所有消费者各自消费，基于推模型

2）延迟队列实现：需要延迟的消息会先存储在JobStore中，通过异步线程任务JobScheduler将到达投递时间的消息投递到相应队列上

a、Broker Filter：Broker中定义了一系列BrokerFilter的子类构成拦截器链，按顺序对消息进行相应处理

b、ScheduleBroker：当消息中指定了延迟相关属性，并且jobId为空时，会生成调度任务存储到JobStore中，此时消息不会进入到队列

c、JobStore：基于BTree存储，key为任务执行的时间戳，value为该时间戳下需要执行的任务列表

d、JobScheduler：取JobStore中最小的key执行（调度时间最早的），执行时间=当前时间，将该任务列表依次投递到所属的队列，对于需要重复投递和投递失败的会再次存入JobStore中。

注： 此处JobScheduler的执行时间间隔可动态变化，默认0.5s，有新任务时会立即执行（Object-notifyAll()）并设置时间间隔为0.1s，没有新任务后，下次执行时间为最近任务的调度执行时间。

3）缺点：投递到队列失败，将消息重新存入JobStore，消息调度执行时间=系统当前时间+延迟时间，会导致消息被真实投递的时间可能为设置的延迟时间的整数倍

5、Redis

1）简介：基于Key-Value的NoSQL数据库，由于其极高的性能常被当作缓存来使用，其数据结构支持：字符串、哈希、列表、集合、有序集合

2）延迟队列实现：Redis的延迟队列基于有序集合，score为执行时间戳，value为任务实体或任务实体引用

3）缺点：

a、实现复杂，本身不支持

b、完全基于内存，延迟时间长浪费内存资源

6、消息队列对比

1、公开课延迟队列技术选型

1）业务场景：关闭超时未支付订单、限时优惠活动、拼团

2）性能要求：订单、活动、拼团 数据量可控，上述MQ均能满足要求

3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作为延迟队列更普遍

4）可用性：ActiveMQ、RocketMQ自身支持延迟队列功能，且目前公开课业务中使用的中间件为ActiveMQ和Kafka

5）延迟时间灵活：活动的开始和结束时间比较灵活，而RocketMQ时间粒度较粗，Kafka会依赖时间格有精度缺失

结论： 最终选择ActiveMQ来作为延迟队列

2、业务场景：关闭未支付订单

1）关闭微信未支付订单

2）关闭IOS未支付订单

3、ActiveMQ使用方式

1）activemq.xml中支持调度任务

2）发送消息时，设置message的延迟属性

其中：

a、延迟处理

AMQ_SCHEDULED_DELAY：设置多长时间后，投递给消费者（毫秒）

b、重复投递

AMQ_SCHEDULED_PERIOD：重复投递时间间隔（毫秒）

AMQ_SCHEDULED_REPEAT：重复投递次数

c、指定调度计划

AMQ_SCHEDULED_CRON：corn正则表达式

4、公开课使用中进行的优化

1）可靠性：针对实际投递时间可能翻倍的问题，结合ActiveMQ的重复投递，在消费者逻辑中做幂等处理来保证延迟时间的准确性

2）可追溯性：延迟消息及消费情况做数据库冗余存储

3）易用性：业务上定义好延迟枚举类型，直接使用JmsDelayTemplate发送，无需关心数据备份和参数等细节

1、无论是基于死信队列还是基于数据先存储后投递，本质上都是将延迟待发送的消息数据与正常订阅的队列分开存储，从而降低耦合度

2、无论是检查队头消息TTL还是调度存储的延迟数据，本质上都是通过定时任务来完成的，但是定时任务的触发策略以及延迟数据的存储方式决定了不同中间件之间的性能优劣

张浩，2018年加入网易传媒，高级Java开发工程师，目前在网易公开课主要做支付财务体系、版本迭代相关的工作。

Kafka-概述

    Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的(partition)、多副本的(replica)，基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶首盯级开源 项目。

JMS(Java Message Service)是Java提供的一套技术规范

    用来异帆李构系统 集成通信，缓解系统瓶颈，提高系统的伸缩性增强系统用户体验，使得系统模块化和组件化变得可行并更加灵活

(1) 点对点模式(一对一，消费者主动拉取数据，消息收到后消息清除)

    点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

(2) 发布/订阅模式(一对多，数据生产后，推送给所有订阅者)

    发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。

    kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。

kafka集群支持热扩展

消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

支持数千个客户端同时读写

    一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

    解耦和生产者和消费者、缓存消息等。

    Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

    Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

    比如spark streaming和storm

    Kafka每个主题的多个分区日志分布式地存储在Kafka集群上，同时为了故障容错，每个分区都会以副本的方式复制到多个消息代理节点上。其中一个节点会作为主副本(Leader)，其他节点作为备份副本(Follower，也叫作从副本)。主副本会负责所有的客户端读写操作，备份副本仅仅从主副本同步数据。当主副本出现故障时，备份副本中的一个副本会被选择为新的主副本。因为每个分区的副本中只有主副本接受读写，所以每个服务器端都会作为某些分区的主副本，以及另外一些分区的备份副本，这样Kafka集群的所有服务端整体上对客户端是负载均衡的。

    Kafka的生产者和消费者相对于服务器端而言都是客户端。

    Kafka生产者客户端发布消息到服务端的指定主题，会指定消息所属的分区。生产者发布消息时根据消息是否有键，采用不同的分区策略。消息没有键时，通过轮询方式进行客户端负载均衡；消息有键时，根据分区语义（例如hash）确保相同键的消息总是发送到同一分区。

    Kafka的消费者通过订阅主题来消费消息，并且每个消费者都会设置一个消费组名称。因为生产者发布到主题的每一条消息都只会发送给消费者组的一个消费者。所以，如果要实现传统消息系统的“队列”模型，可以让每个消费者都拥有相同的消费组名称，这样消息就会负责均衡到所有的消费者；如果要实现“发布-订阅”模型，则每个消费者的消费者组名称都不相同，这样每条消息就会广播给所有的消费者。

    分区是消费者现场模型的最小并行单态芹迟位。如下图（图1）所示，生产者发布消息到一台服务器的3个分区时，只有一个消费者消费所有的3个分区。在下图（图2）中，3个分区分布在3台服务器上，同时有3个消费者分别消费不同的分区。假设每个服务器的吞吐量时300MB，在下图（图1）中分摊到每个分区只有100MB，而在下图（图2）中，集群整体的吞吐量有900MB。可以看到，增加服务器节点会提升集群的性能，增加消费者数量会提升处理性能。

    同一个消费组下多个消费者互相协调消费工作，Kafka会将所有的分区平均地分配给所有的消费者实例，这样每个消费者都可以分配到数量均等的分区。Kafka的消费组管理协议会动态地维护消费组的成员列表，当一个新消费者加入消费者组，或者有消费者离开消费组，都会触发再平衡操作。

    Kafka的消费者消费消息时，只保证在一个分区内的消息的完全有序性，并不保证同一个主题汇中多个分区的消息顺序。而且，消费者读取一个分区消息的顺序和生产者写入到这个分区的顺序是一致的。比如，生产者写入“hello”和“Kafka”两条消息到分区P1，则消费者读取到的顺序也一定是“hello”和“Kafka”。如果业务上需要保证所有消息完全一致，只能通过设置一个分区完成，但这种做法的缺点是最多只能有一个消费者进行消费。一般来说，只需要保证每个分区的有序性，再对消息假设键来保证相同键的所有消息落入同一分区，就可以满足绝大多数的应用。

[img]

消息队列原理及选型

消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。

Broker（消息服务器）

Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。

Producer（生产者）

业务的发起方，负责生产消息传输给broker

Consumer（消费者）

业务的处理方，负责从broker获取消息并进行业务逻辑处理

Topic（主题）

发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅 者，实现消息的广播

Queue（队列）

PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。

Message（消息体）

根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

点对点模型用于消息生产者和消息消费者之间点到点的通信。

点对点模式包含三个角色：

每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在内存 中也可以持久化，直到他们被消费或超时。

特点：

发布订阅模型包含三个角色：

多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

特点：

AMQP即Advanced Message Queuing Protocol，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无源蠢乎需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、档猛队列、路由（包括点对点和发布/订阅）、可靠性、安全。

优点：可靠、通用

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点：命令模式（非topic\queue模式）

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现雹悉场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。

RabbitMQ 是一个开源的 AMQP 实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

Channel（通道）

道是两个管理器之间的一种单向点对点的的通信连接，如果需要双向交流，可以建立一对通道。

Exchange（消息交换机）

Exchange类似于数据通信网络中的交换机，提供消息路由策略。

RabbitMq中，producer不是通过信道直接将消息发送给queue，而是先发送给Exchange。一个Exchange可以和多个Queue进行绑定，producer在传递消息的时候，会传递一个ROUTING_KEY，Exchange会根据这个ROUTING_KEY按照特定的路由算法，将消息路由给指定的queue。和Queue一样，Exchange也可设置为持久化，临时或者自动删除。

Exchange有4种类型：direct(默认)，fanout， topic， 和headers。

不同类型的Exchange转发消息的策略有所区别：

Binding（绑定）

所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来。Exchange 和Queue的绑定可以是多对多的关系。

Routing Key（路由关键字）

exchange根据这个关键字进行消息投递。

vhost（虚拟主机）

在RabbitMq server上可以创建多个虚拟的message broker，又叫做virtual hosts (vhosts)。每一个vhost本质上是一个mini-rabbitmq server，分别管理各自的exchange，和bindings。vhost相当于物理的server，可以为不同app提供边界隔离，使得应用安全的运行在不同的vhost实例上，相互之间不会干扰。producer和consumer连接rabbit server需要指定一个vhost。

假设P1和C1注册了相同的Broker，Exchange和Queue。P1发送的消息最终会被C1消费。

基本的通信流程大概如下所示：

Consumer收到消息时需要显式的向rabbit broker发送basic。ack消息或者consumer订阅消息时设置auto_ack参数为true。

在通信过程中，队列对ACK的处理有以下几种情况：

即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。

消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这应该处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。

消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。

fanout 模式

模式特点：

direct 模式

任何发送到Direct Exchange的消息都会被转发到routing_key中指定的Queue。

如果一个exchange 声明为direct，并且bind中指定了routing_key，那么发送消息时需要同时指明该exchange和routing_key。

简而言之就是：生产者生成消息发送给Exchange， Exchange根据Exchange类型和basic_publish中的routing_key进行消息发送 消费者：订阅Exchange并根据Exchange类型和binding key(bindings 中的routing key) ，如果生产者和订阅者的routing_key相同，Exchange就会路由到那个队列。

topic 模式

前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。

topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同。

它约定：

以上图中的配置为例，routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

RabbitMQ，部署分三种模式：单机模式，普通集群模式，镜像集群模式。

普通集群模式

多台机器部署，每个机器放一个rabbitmq实例，但是创建的queue只会放在一个rabbitmq实例上，每个实例同步queue的元数据。

如果消费时连的是其他实例，那个实例会从queue所在实例拉取数据。这就会导致拉取数据的开销，如果那个放queue的实例宕机了，那么其他实例就无法从那个实例拉取，即便开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，但得等这个实例恢复了，然后才可以继续从这个queue拉取数据， 这就没什么高可用可言，主要是提供吞吐量 ，让集群中多个节点来服务某个queue的读写操作。

镜像集群模式

queue的元数据和消息都会存放在多个实例，每次写消息就自动同步到多个queue实例里。这样任何一个机器宕机，其他机器都可以顶上，但是性能开销太大，消息同步导致网络带宽压力和消耗很重，另外，没有扩展性可言，如果queue负载很重，加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。此时，需要开启镜像集群模式，在rabbitmq管理控制台新增一个策略，将数据同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

Kafka 是 Apache 的子项目，是一个高性能跨语言的分布式发布/订阅消息队列系统（没有严格实现 JMS 规范的点对点模型，但可以实现其效果），在企业开发中有广泛的应用。高性能是其最大优势，劣势是消息的可靠性（丢失或重复），这个劣势是为了换取高性能，开发者可以以稍降低性能，来换取消息的可靠性。

一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)，每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。

Kafka和JMS（Java Message Service）实现(activeMQ)不同的是:即使消息被消费，消息仍然不会被立即删除。日志文件将会根据broker中的配置要求，保留一定的时间之后删除；比如log文件保留2天，那么两天后，文件会被清除，无论其中的消息是否被消费。kafka通过这种简单的手段，来释放磁盘空间，以及减少消息消费之后对文件内容改动的磁盘IO开支。

对于consumer而言，它需要保存消费消息的offset，对于offset的保存和使用，有consumer来控制；当consumer正常消费消息时，offset将会"线性"的向前驱动，即消息将依次顺序被消费。事实上consumer可以使用任意顺序消费消息，它只需要将offset重置为任意值。(offset将会保存在zookeeper中，参见下文)

kafka集群几乎不需要维护任何consumer和producer状态信息，这些信息有zookeeper保存；因此producer和consumer的客户端实现非常轻量级，它们可以随意离开，而不会对集群造成额外的影响。

partitions的设计目的有多个。最根本原因是kafka基于文件存储。通过分区，可以将日志内容分散到多个server上，来避免文件尺寸达到单机磁盘的上限，每个partiton都会被当前server(kafka实例)保存；可以将一个topic切分多任意多个partitions，来消息保存/消费的效率。此外越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力。(具体原理参见下文)。

一个Topic的多个partitions，被分布在kafka集群中的多个server上；每个server(kafka实例)负责partitions中消息的读写操作；此外kafka还可以配置partitions需要备份的个数(replicas)，每个partition将会被备份到多台机器上，以提高可用性。

基于replicated方案，那么就意味着需要对多个备份进行调度；每个partition都有一个server为"leader"；leader负责所有的读写操作，如果leader失效，那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进，同步消息即可。由此可见作为leader的server承载了全部的请求压力，因此从集群的整体考虑，有多少个partitions就意味着有多少个"leader"，kafka会将"leader"均衡的分散在每个实例上，来确保整体的性能稳定。

Producers

Producer将消息发布到指定的Topic中，同时Producer也能决定将此消息归属于哪个partition；比如基于"round-robin"方式或者通过其他的一些算法等。

Consumers

本质上kafka只支持Topic。每个consumer属于一个consumer group；反过来说，每个group中可以有多个consumer。发送到Topic的消息，只会被订阅此Topic的每个group中的一个consumer消费。

如果所有的consumer都具有相同的group，这种情况和queue模式很像；消息将会在consumers之间负载均衡。

如果所有的consumer都具有不同的group，那这就是"发布-订阅"；消息将会广播给所有的消费者。

在kafka中，一个partition中的消息只会被group中的一个consumer消费；每个group中consumer消息消费互相独立；我们可以认为一个group是一个"订阅"者，一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以消费多个partitions中的消息。kafka只能保证一个partition中的消息被某个consumer消费时，消息是顺序的。事实上，从Topic角度来说，消息仍不是有序的。

Kafka的设计原理决定，对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。

Guarantees

Kafka就比较适合高吞吐量并且允许少量数据丢失的场景，如果非要保证“消息可靠传输”，可以使用JMS。

Kafka Producer 消息发送有两种方式(配置参数 producer.type)：

对于同步方式(producer.type=sync)？Kafka Producer 消息发送有三种确认方式(配置参数 acks)：

kafka的设计初衷是希望作为一个统一的信息收集平台，能够实时的收集反馈信息，并需要能够支撑较大的数据量，且具备良好的容错能力。

持久性

kafka使用文件存储消息，这就直接决定kafka在性能上严重依赖文件系统的本身特性。且无论任何OS下，对文件系统本身的优化几乎没有可能。文件缓存/直接内存映射等是常用的手段。因为kafka是对日志文件进行append操作，因此磁盘检索的开支是较小的；同时为了减少磁盘写入的次数，broker会将消息暂时buffer起来，当消息的个数(或尺寸)达到一定阀值时，再flush到磁盘，这样减少了磁盘IO调用的次数。

性能

需要考虑的影响性能点很多，除磁盘IO之外，我们还需要考虑网络IO，这直接关系到kafka的吞吐量问题。kafka并没有提供太多高超的技巧；对于producer端，可以将消息buffer起来，当消息的条数达到一定阀值时，批量发送给broker；对于consumer端也是一样，批量fetch多条消息。不过消息量的大小可以通过配置文件来指定。对于kafka broker端，似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中，socket直接读取相应的内存区域即可，而无需进程再次copy和交换。 其实对于producer/consumer/broker三者而言，CPU的开支应该都不大，因此启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源，不过对于kafka而言，网络IO更应该需要考虑。可以将任何在网络上传输的消息都经过压缩。kafka支持gzip/snappy等多种压缩方式。

生产者

负载均衡: producer将会和Topic下所有partition leader保持socket连接；消息由producer直接通过socket发送到broker，中间不会经过任何“路由层“。事实上，消息被路由到哪个partition上，有producer客户端决定。比如可以采用“random““key-hash““轮询“等，如果一个topic中有多个partitions，那么在producer端实现“消息均衡分发“是必要的。

其中partition leader的位置(host:port)注册在zookeeper中，producer作为zookeeper client，已经注册了watch用来监听partition leader的变更事件。

异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。

消费者

consumer端向broker发送“fetch”请求，并告知其获取消息的offset；此后consumer将会获得一定条数的消息；consumer端也可以重置offset来重新消费消息。

在JMS实现中，Topic模型基于push方式，即broker将消息推送给consumer端。不过在kafka中，采用了pull方式，即consumer在和broker建立连接之后，主动去pull(或者说fetch)消息；这中模式有些优点，首先consumer端可以根据自己的消费能力适时的去fetch消息并处理，且可以控制消息消费的进度(offset)；此外，消费者可以良好的控制消息消费的数量，batch fetch。

其他JMS实现，消息消费的位置是有prodiver保留，以便避免重复发送消息或者将没有消费成功的消息重发等，同时还要控制消息的状态。这就要求JMS broker需要太多额外的工作。在kafka中，partition中的消息只有一个consumer在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见kafka broker端是相当轻量级的。当消息被consumer接收之后，consumer可以在本地保存最后消息的offset，并间歇性的向zookeeper注册offset。由此可见，consumer客户端也很轻量级。

对于JMS实现，消息传输担保非常直接:有且只有一次(exactly once)。

在kafka中稍有不同:

at most once: 消费者fetch消息，然后保存offset，然后处理消息；当client保存offset之后，但是在消息处理过程中出现了异常，导致部分消息未能继续处理。那么此后"未处理"的消息将不能被fetch到，这就是"at most once"。

at least once: 消费者fetch消息，然后处理消息，然后保存offset。如果消息处理成功之后，但是在保存offset阶段zookeeper异常导致保存操作未能执行成功，这就导致接下来再次fetch时可能获得上次已经处理过的消息，这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态。

exactly once: kafka中并没有严格的去实现(基于2阶段提交，事务)，我们认为这种策略在kafka中是没有必要的。

通常情况下“at-least-once”是我们首选。(相比at most once而言，重复接收数据总比丢失数据要好)。

kafka高可用由多个broker组成，每个broker是一个节点；

创建一个topic，这个topic会划分为多个partition，每个partition存在于不同的broker上，每个partition就放一部分数据。

kafka是一个分布式消息队列，就是说一个topic的数据，是分散放在不同的机器上，每个机器就放一部分数据。

在0.8版本以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。

0.8版本以后，才提供了HA机制，也就是就是replica副本机制。每个partition的数据都会同步到其他的机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。

写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。

kafka会均匀的将一个partition的所有replica分布在不同的机器上，从而提高容错性。

如果某个broker宕机了也没事，它上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。

写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。

消息丢失会出现在三个环节，分别是生产者、mq中间件、消费者：

RabbitMQ

Kafka

大体和RabbitMQ相同。

Rabbitmq

需要保证顺序的消息投递到同一个queue中，这个queue只能有一个consumer，如果需要提升性能，可以用内存队列做排队，然后分发给底层不同的worker来处理。

Kafka

写入一个partition中的数据一定是有序的。生产者在写的时候 ，可以指定一个key，比如指定订单id作为key，这个订单相关数据一定会被分发到一个partition中去。消费者从partition中取出数据的时候也一定是有序的，把每个数据放入对应的一个内存队列，一个partition中有几条相关数据就用几个内存队列，消费者开启多个线程，每个线程处理一个内存队列。

关于kafka延迟队列和kafka延迟队列使用的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。