消息队列

一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式 a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。 b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？ 引入消息队列

常见的企业级MQ 1. RabbitMQ 是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP。 优点： 也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个代理(Broker)构架，这意味着消息在发送到客户端之前可以在中央节点上排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。 缺点： 它的可扩展性差，速度较慢，因为中央节点增加了延迟，消息封装后也比较大。 2. ZeroMQ ZeroMQ是一个非常轻量级的消息系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常可以发现它。 优点：号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列。 缺点： 与RabbitMQ相比，ZeroMQ支持许多高级消息场景，但是你必须实现ZeroMQ框架中的各个块（比如Socket或Device等）。ZeroMQ非常灵活，但是你必须学习它的80页的手册（如果你要写一个分布式系统，一定要阅读它）。 应用：Twitter的Storm中使用ZeroMQ作为数据流的传输。 3. ActiveMQ ActiveMQ居于两者之间，类似于ZemoMQ，它可以部署于代理模式和P2P模式。类似于RabbitMQ，它易于实现高级场景

面试题 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ 面试官心理分析 你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？ 所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于，举个例子，消费端每次消费之后要写 mysql，结果 mysql 挂了，消费端 hang 那儿了，不动了；或者是消费端出了个什么岔子，导致消费速度极其慢。 面试题剖析 关于这个事儿，我们一个一个来梳理吧，先假设一个场景，我们现在消费端出故障了，然后大量消息在 mq 里积压，现在出事故了，慌了。 大量消息在 mq 里积压了几个小时了还没解决 几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。 一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条

面试题 如果让你写一个消息队列，该如何进行架构设计？说一下你的思路。 面试官心理分析 其实聊到这个问题，一般面试官要考察两块： 你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个消息队列的架构原理。 看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来。 说实话，问类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。类似的问题，比如，如果让你来设计一个 Spring 框架你会怎么做？如果让你来设计一个 Dubbo 框架你会怎么做？如果让你来设计一个 MyBatis 框架你会怎么做？ 面试题剖析 其实回答这类问题，说白了，不求你看过那技术的源码，起码你要大概知道那个技术的基本原理、核心组成部分、基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好。 比如说这个消息队列系统，我们从以下几个角度来考虑一下： 首先这个 mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加

为什么会需要消息队列(MQ)？ 一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式 a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。 b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢

AMQP中的消息路由 AMQP中消息的路由过程和Java开发者熟悉的JMS存在一些差别，AMQP中增加了 Exchange和Binding 的角色。生产者把消息发布到Exchange上，消息最终到达队列并被消费者接收，而Binding决定交换器的消息应该发送到那个队列。 Exchange类型 Exchange分发消息时根据类型的不同分发策略有区别，目前共有4中类型： direct、fanout、topic、headers 。 headers匹配AMQP消息的header而不是路由键，headers交换器和direct交换器完全一致，但性能差很多，目前几乎用不到了，所以直接看另外三中类型。 Direct Exchange： 消息中的路由键（routing key）如果和Binding中的binding key一致，交换器将消息发到对应的队列中。路由键与队列名完全匹配，如果一个队列绑定到交换机要求路由键为"dog"，则只转发routing key 标记为"dog"的消息，不会转发"dog.puppy"，也不会转发"dog.guard"等等。它是完全匹配、单播的模式。 Fanout Exchange： 每个发到fanout类型交换器的消息都会分到所有绑定的队列上去。fanout交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上

介绍 ApacheKafka®是一个分布式流媒体平台。这到底是什么意思呢？ 我们认为流媒体平台具有三个关键功能： 它可以让你发布和订阅记录流。在这方面，它类似于消​​息队列或企业消息传递系统。它允许您以容错方式存储记录流。它可以让您在发生记录时处理记录流。什么是卡夫卡好？ 它被用于两大类的应用程序： 构建可在系统或应用程序之间可靠获取数据的实时流数据管道构建实时流应用程序，可以转换或响应数据流要了解卡夫卡如何做这些事情，让我们深入探索卡夫卡的能力。 首先几个概念： Kafka作为一个或多个服务器上的集群运行。Kafka集群以称为主题的类别存储记录流。每个记录由一个键，一个值和一个时间戳组成。卡夫卡有四个核心API： 该制片API允许应用程序发布的记录流至一个或多个卡夫卡的话题。该消费者API允许应用程序订阅一个或多个主题，并处理所产生的对他们记录的数据流。所述流API允许应用程序充当流处理器，从一个或多个主题消耗的输入流，并产生一个输出流至一个或多个输出的主题，有效地变换所述输入流，以输出流。该连接器API允许构建和运行卡夫卡主题连接到现有的应用程序或数据系统中重用生产者或消费者。例如，连接到关系数据库的连接器可能会捕获对表的每个更改。 在Kafka中，客户端和服务器之间的通信是通过一个简单的，高性能的，与语言无关的TCP协议完成的。这个协议是版本化的，并保持与旧版本的向后兼容性

面试题 如何保证消息队列的高可用？ 面试官心理分析 如果有人问到你 MQ 的知识， 高可用是必问的 。 上一讲 提到，MQ 会导致 系统可用性降低 。所以只要你用了 MQ，接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。 要是你傻乎乎的就干用了一个 MQ，各种问题从来没考虑过，那你就杯具了，面试官对你的感觉就是，只会简单使用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的普通小弟还凑合，要是做薪资 20k+ 的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。 面试题剖析 这个问题这么问是很好的，因为不能问你 Kafka 的高可用性怎么保证？ActiveMQ 的高可用性怎么保证？一个面试官要是这么问就显得很没水平，人家可能用的就是 RabbitMQ，没用过 Kafka，你上来问人家 Kafka 干什么？这不是摆明了刁难人么。 所以有水平的面试官，问的是 MQ 的高可用性怎么保证？这样就是你用过哪个 MQ，你就说说你对那个 MQ 的高可用性的理解。 RabbitMQ 的高可用性 RabbitMQ 是比较有代表性的，因为是 基于主从 （非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。 RabbitMQ 有三种模式：单机模式、普通集群模式

一、先扔一张图 说明: 本文涵盖了关于RabbitMQ很多方面的知识点, 如: 消息发送确认机制 消费确认机制 消息的重新投递 消费幂等性, 等等 这些都是围绕上面那张整体流程图展开的, 所以有必要先贴出来, 见图知意 二、实现思路 简略介绍163邮箱授权码的获取 编写发送邮件工具类 编写RabbitMQ配置文件 生产者发起调用 消费者发送邮件 定时任务定时拉取投递失败的消息, 重新投递 各种异常情况的测试验证 拓展: 使用动态代理实现消费端幂等性验证和消息确认(ack) 三、项目介绍 springboot版本2.1.5.RELEASE, 旧版本可能有些配置属性不能使用, 需要以代码形式进行配置 RabbitMQ版本3.7.15 MailUtil: 发送邮件工具类 RabbitConfig: rabbitmq相关配置 TestServiceImpl: 生产者, 发送消息 MailConsumer: 消费者, 消费消息, 发送邮件 ResendMsg: 定时任务, 重新投递发送失败的消息 说明: 上面是核心代码, MsgLogService mapper xml等均未贴出, 完整代码可以参考GitHub上的源码，地址在文末。 四、代码实现 1.163邮箱授权码的获取, 如图: 该授权码就是配置文件spring.mail.password需要的密码 2.pom < ! -- mq --

broker.id =0 #每一个broker在集群中的唯一表示，要求是正数。当该服务器的IP地址发生改变时，broker.id没有变化，则不会影响consumers的消息情况 log.dirs=/data/kafka-logs #kafka数据的存放地址，多个地址的话用逗号分割/data/kafka-logs-1，/data/kafka-logs-2 port =9092 #broker server服务端口 message.max.bytes =6525000 #表示消息体的最大大小，单位是字节 num.network.threads =4 #broker处理消息的最大线程数，一般情况下不需要去修改 num.io.threads =8 #broker处理磁盘IO的线程数，数值应该大于你的硬盘数 background.threads =4 #一些后台任务处理的线程数，例如过期消息文件的删除等，一般情况下不需要去做修改 queued.max.requests =500 #等待IO线程处理的请求队列最大数，若是等待IO的请求超过这个数值，那么会停止接受外部消息，应该是一种自我保护机制。 host.name #broker的主机地址，若是设置了，那么会绑定到这个地址上，若是没有，会绑定到所有的接口上，并将其中之一发送到ZK，一般不设置 socket.send.buffer.bytes