Java学习日报—消息队列—2021/11/23

1. 消息队列

1.1 基本概念

消息队列的本质就是发送 —存储 — 消费：

生产者先将消息投递一个叫做「队列」的容器中，然后再从这个容器中取出消息，最后再转发给消费者，仅此而已。

这是传统的队列模型，但是，如果有多个消费者都需要这个消息，但是，只有一个消费者获得消息消费掉，队列中该消息就被删除，其他消费者就无法获取。

于是，发布—订阅者模型被提出：

这里的队列就变成主题，订阅者需要提前订阅主题，然后所有订阅过的订阅者都能收到消息，另外，如果订阅者为1，那么就是传统的模型，也就是单播和广播的区别，其实大多数消息队列组件都是基于这个模型，然后做了一定的改动。

1.2 RabbitMQ

RabbitMQ的架构如下：

可以看出RabbitMQ的结构基本就是在基本结构基础上加了exchange，这个exchange称作交换机，制定消息按什么规则、路由到哪个队列，有四种类型：

• Direct：处理路由键（routing key），需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。
• Topic：将路由键和某模式进行匹配。此时队列需要绑定要一个模式上，符号“#”匹配一个或多个词，符号“*”只能匹配一个词。模糊匹配。
• Fanout：不处理路由键。你只需要简单的将队列绑定到交换机上。一个发送到该类型交换机的消息都会被广播到与该交换机绑定的所有队列上。
• header：不处理路由键，而是根据发送的消息内容中的headers属性进行匹配。在绑定Queue与Exchange时指定一组键值对；当消息发送到RabbitMQ时会取到该消息的headers与Exchange绑定时指定的键值对进行匹配；如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers属性是一个键值对，可以是Hashtable，键值对的值可以是任何类型。而fanout，direct，topic 的路由键都需要要字符串形式的。

通过交换机RabbitMQ可以实现广播，四种模式保证了灵活性。

1.3 KafKa

Kafka的架构如下：

Kafka中的常见概念如下：

• 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集群数据不均衡。
• topic： 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
• partition： topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
• leader： 每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
• follower： Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。
• zookeeper： broker、consumer信息存储，消费进度的存储、leader选举等。

1.4 两种常用的MQ的对比

• 性能：Kafka的诞生的是处理高并发日志的，吞吐量比较高，每秒请求数达到数十万量级，RabbitMQ每秒请求数则为万级别，有测试报告指出Kafka是RabbitMQ的10倍以上性能。
• 运维便捷：RabbitMQ相对比较方便，可以使用yum或者docker安装，自带Web管理UI，没有额外的依赖，除了需要做镜像队列外需要引入HAproxy。Kafka则需要依赖Zookeeper，也没有自带的管理工具，可以使用第三方的Kafka Eagle代替，Kafka Manager过于难用，另外Kafka没有yum安装，docker镜像也是社区人员自己建的。
• 有序性：RabbitMQ理论上是全局有序性的，但是由于发后既忘+自动确认机制的原因，如果在同个队列的多个消费者做相同的业务处理时，他们的各自的执行任务无法保证有序完成。如果确保100%有序可以使用非自动确认，但会影响消费性能。Kafka支持分区有序性，如果对有序性有严格要求可以设置单个Partition，可是单个Partition并发性比较低，因此在多个Partition情况下可以根据业务指定key把相关的消息路由到同一个Partition，例如相同UserId行为信息可以到Partition 1进行处理。
• 时效性：Kafka基本上无论在客户端还是服务端都是以异步批量的机制进行处理，通俗的讲就是先攒起来一堆消息，到了某个阀值再发送，也会导致一些消息可靠性与消息有时效上的问题，当然可以通过各种配置策略进行解决。
• 消息回溯：Kafka在消费完了消息后不会立即删除，只会修改offset，如果之前部分业务消费失败了可以重新设置offset进行重新消费。RabbitMQ则是[发后既忘]的机制，一但消费者确认消息则删除，但是可以通过死信进行补偿消费。此外RabbitMQ在队列消息堆积多的情况下性能表现不佳，所以尽可能的及时消费消息。
• 特色功能：RabbitMQ具有死信的功能，可以通过死信形成重复消费与延时发送。Kafka具有流处理功能，可以收集用户的行为日志进行存储与分析。

1.5 使用场景

使用场景：MQ的使用一般是用于系统解耦、异步通信和流量削峰。除此之外，还有延迟通知、最终一致性保证、顺序消息、流式处理等等。