分布式队列RabbitMQ和Kafka

1.分布式队列概念

消息队列是一个常用的通讯组件，它允许消息的生产者把消息存储在队列中，消费者在适当的时候取出处理。相比一般请求-响应处理模型，消息队列的存在使得生产者和消费者的处理可以是异步的，消费者的处理速率不必跟生产者完全一致：在极端的情况下，生产者和消费者进程不必同时存在：一个进程可以发送一个消息并退出，而该消息可以在数天后才被另一个进程获得。总体而言，由于消息队列的缓存功能，使得生产者和消费者的处理可以是解耦的，这个软件结构设计带来了很大的 灵活性。

消息队列最先用于计算机内部的进程间通讯或线程间通讯。在后来的软件工程实践中，随着分布式技术的发展，消息队列逐渐变成了独立部署的软件组件。特别是在于云平台环境下，它成为不同服务之间消息消息通信和同步的关键技术：基于云平台的可靠性要求，需要队列服务提供持久化存储能力，并且能够容忍存储的单点故障，从而实现持久化存储的分布式队列服务。

2.分布式队列特点

在任务队列的场景中，我们不关心保序、一到多消息分发等特性，但是我们需要关心消息的持久性、重试、互锁等特性，针对任务队列提供了以下特性。
任务锁定

• 任务锁定：用可见性窗口解决任务锁定的问题。当一个消费者处理一个消息时，该消息在一定时间内对其他消费者不可见，避免冲突。
• 重试：任务处理失败时要能够支持重试。通过可见性窗口支持重试，正在处理的消息不会从队列中删除，只是不可见，消费者处理完成后才会删除。如果消费者故障导致处理超时，消息在队列中重新可见，可以被别的消费者处理。
• 数据可用性：因为job Queue处于系统架构的中心地位，Broker服务必须总是可用，Broker节点故障也不能导致消息丢失。
• 消息缓存时间：一般JOB粒度较大时，处理时间会比较长，所以在queue里面停留的时间也很长。
• 性能：典型如可以支持每个用户200消息/秒的处理速度，时延在2~10秒之间。在任务粒度较大、写入间隔较长时，特别需要支持PUSH模式，否则消费者可能需要花费大量的时间检查消息是否到达。

3.RabbitMQ

RabbitMQ是以AMQP协议实现的一种中间件产品，它可以支持多种操作系统，多种编程语言，几乎可以覆盖所有主流的企业级技术平台。
RabbitMQ的最大特点是遵循AMQP模型，在生产者一侧显示地支持exchange，可以实现消息的路由。RabbitMQ支持AMQP中几乎所有的路由方式

• 缺省路由：用队列名作为routing key 进行路由；
• fanout: 一份消息复制多份，发送到每个绑定到exchange上的队列中；
• Toptic路由：基于routing 和匹配模式进行路由；
• Headers路由： 基于消息头进行路由。
  在消息的一侧，RabbitMQ支持pull和push两种消息递交方式。在pull方式下，消费者通过basic.get方法主动获取消息。在push模式下，消费者通过basic.consume方法订阅消息，broker通过basic.deliver方法向消费者推送消息。
  用户可以设置RabbitMQ的消息是否持久化。但是RabbitMQ不是为持久化设计的，一般情况下消息存放在内存中，只有在缓存溢出和考虑数据可靠性时才会持久化，持久化会导致性能明显下降。

4.Kafka

Apache Kafka天生被设计成一个分布式、可扩展、缺省、支持、持久性、高吞吐量的消息系统，目前主要应用实在大数据领域，作为实时数据和离线分析的数据源使用。

在Kafka中，消息按topic分类，每个topic又分为多个partition，每个partition是一个有序的队列。生产者产生的消息发送到broker,缓存到其中一个partition中，partition中的每条消息都会被分配一个有序的id(offset)。
Kafka是典型的分布式架构，Kafka中的生产者、消费者和中间缓存消息的broker都可以是多个。Kafka通过zookeeper集群监控broker的状态，完成partition到broker的分布。用户需要自己提供一个函数计算某个消息发送到哪个partition。为了实现消息的可靠保存，通常一个partition会在多个broker上复制多份。
由于Kafka主要用于处理大量日志数据，它具备以下异于传统消息队列的特点：

• 高吞吐量：Kafka通过支持批处理和横向扩展功能通常可以获得传统队列5倍以上的吞吐量。

• 同时支持在线和离线处理：传统消息系统一旦缓存满，产生大量写盘操作，性能就会急剧下降，kafka原生支持持久化。

• 独特的pull机制，处理完的消息在broker不会立即删除（后续通过定时机制删除），只是消息偏移量增加（消费者需要自行维护已经读取的消息偏移量）。当消费者需要重新处理已经处理过的消息时，只需要回退偏移量即可。基于kafka也很容易实现消息的fanout，多个消费者只需要维护各自的偏移量，一个消息就可以被多个消费者各自处理，效果等同于一条消息复制多份。
  Kafka应用分析
  Kafka可以作为企业中的数据总线使用，需要分析的数据首先汇总缓存到Kafka，然后数据分析程序再按需取出使用。由于Kafka的存在，用户不再需要再m个数据和n个数据使用者之间建立m*n个数据管道，从而极大地简化了数据分析的架构。
  除了用做数据总线之外，Kafka还可以作为可靠的日志存储使用，支持以下设计模式。

• Event sourcing:把状态的改变用日志的形式纪录在消息队列中。可以恢复到任意时间点的状态，类似存储设备中的连续数据保护。

• Commit Log:节点把从初始状态起所有的改变以commit-log记录在消息队列中；当节点故障重新恢复时，从消息队列中取回并重放commit-log，恢复节点状态。