activemq

　　 　　 2020年Java面试题库连载中 　　更多内容，点击上面蓝字查看 　　消息队列的文章也是发过蛮多的，比如： 　　今天，就讲讲解决消息队列的数据积压的三个方案。 　　 1 概述 　　最近生产环境的消息通知队列发生了大量的数据积压问题，从而影响到整个平台商户的交易无法正常进行，最后只能通过临时关闭交易量较大的商户来缓解消息队列积压的问题，经线上数据分析，我们的消息队列在面对交易突发洪峰的情况下无法快速的消费并处理队列中的数据，考虑到后续还会出现各种交易量突发状况，以下为针对消息队列（ActiveMQ）的优化过程。 　　 2 消息队列通信图 　　 　　 3 问题定位与分析 　　3.1 消息通知数据为什么会被积压？ 分析：平台中每个交易的发生可能会产生一到多条的消息通知数据，这些通知数据会通过消息队列（ActiveMQ）来中转消费并处理，那么在交易量突发洪峰的情况下会产生大量的消息通知数据，如果消息队列（ActiveMQ）的消费能力被阻塞的话会严重影响到数据的吞吐量，从而积压大量数据无法被快速处理！ 　　3.2 配置了多个ActiveMQ的消费者为什么数据积压还是无法缓解？ 分析：经过分析消息队列的数据消费处理模块的代码，消息的消费处理是通过监听器SessionAwareMessageListener异步回调onMessage方法而接收消息的

一、为什么需要消息队列(MQ) 主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。大量的请求到达访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发 too many connection错误，引发雪崩效应。我们使用消息队列，通过异步处理请求，从而缓解系统的压力。核心：异步处理、流量削峰、应用解耦 二、应用场景 异步处理，流量削峰，应用解耦，消息通讯四个场景 2.1、异步处理 场景1：用户注册后，需要发送注册邮件和注册短信。 串行方式：将注册信息写入 数据库 成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端 并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU在1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。 并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题？ 引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：

文章目录 7.1 MQ简介 7.1.1 什么是MQ 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 7.1.2.2 流量削峰 7.1.3 常见的MQ产品 7.2 RocketMQ入门 7.2.1 RocketMQ环境搭建 7.2.1.1 环境准备 7.2.1.2 安装RocketMQ 7.2.1.3 启动RocketMQ 7.2.1.4 测试RocketMQ 7.2.1.5 关闭RocketMQ 7.2.2 RocketMQ的架构及概念 7.2.3 RocketMQ控制台安装 7.3 消息发送和接收演示 7.3.1 发送消息 7.3.2 接收消息 7.4 案例 7.4.1 订单微服务发送消息 7.4.2 用户微服务订阅消息 7.5 发送不同类型的消息 7.5.1 普通消息 7.5.2 顺序消息 7.5.3 事务消息 7.6 消息消费要注意的细节 7.1 MQ简介 7.1.1 什么是MQ MQ（Message Queue）是一种跨进程的通信机制，用于传递消息。通俗点说，就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后，需要发送注册邮件和短信通知，以告知用户注册成功。传统的做法如下： 此架构下注册、邮件、短信三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。但是对于用户来说

目录 SpringBoot如何优雅的使用RocketMQ 什么是RocketMQ？ RocketMQ环境安装 SpringBoot环境中使用RocketMQ SpringBoot如何优雅的使用RocketMQ MQ，是一种跨进程的通信机制，用于上下游传递消息。在传统的互联网架构中通常使用MQ来对上下游来做解耦合。 举例：当A系统对B系统进行消息通讯，如A系统发布一条系统公告，B系统可以订阅该频道进行系统公告同步，整个过程中A系统并不关系B系统会不会同步，由订阅该频道的系统自行处理。 什么是RocketMQ？ 官方说明: 随着使用越来越多的队列和虚拟主题，ActiveMQ IO模块遇到了瓶颈。我们尽力通过节流，断路器或降级来解决此问题，但效果不佳。因此，我们那时开始关注流行的消息传递解决方案Kafka。不幸的是，Kafka不能满足我们的要求，特别是在低延迟和高可靠性方面。 看到这里可以很清楚的知道RcoketMQ 是一款低延迟、高可靠、可伸缩、易于使用的消息中间件。 具有以下特性： 支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 能够保证严格的消息顺序，在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 提供丰富的消息拉取模式，支持拉（pull）和推（push）两种消息模式 单一队列百万消息的堆积能力，亿级消息堆积能力 支持多种消息协议，如 JMS、MQTT 等

若该文为原创文章，未经允许不得转载 原博主博客地址： https://blog.csdn.net/qq21497936 原博主博客导航： https://blog.csdn.net/qq21497936/article/details/102478062 本文章博客地址： https://blog.csdn.net/qq21497936/article/details/106539703 各位读者，知识无穷而人力有穷，要么改需求，要么找专业人士，要么自己研究 红胖子(红模仿)的博文大全：开发技术集合（包含Qt实用技术、树莓派、三维、OpenCV、OpenGL、ffmpeg、OSG、单片机、软硬结合等等）持续更新中…（点击传送门） Qt开发专栏：开发技术（点击传送门） 《 Qt开发技术：mqtt介绍、QtMqtt编译和开发环境搭建 》 《 Mqtt开发笔记：Mqtt服务器搭建 》 <br> 前话   使用到mqtt服务器（中间件）。 <br> MQTT协议 简介   MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的"轻量级"通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。MQTT最大优点在于，可以以极少的代码和有限的带宽

工作多少年了，还在传统公司写if / for 等简单的代码？那你就真的要被社会淘汰了，工作多年其实你与初级工程师又有多少区别呢？那么作为一个高级Java攻城狮需要突破哪些知识点呢？ 1、Java基础技术体系、JVM内存分配、垃圾回收、类装载机制、性能优化、反射机制、多线程、网络编程、常用数据结构和相关算法。 2、对面向对象的软件开发思想有清晰的认识、熟悉掌握常用的设计模式。 3、熟练掌握目前流行开源框架(spring/springmvc/ibatis)，并且对其核心思想、实现原理有一定认知。 4、熟悉Oracle、MySQL等数据库开发与设计以及缓存系统Redis或 Memcached的设计和研发。 5、熟悉底层中间件、分布式技术（包括缓存、消息系统、热部署）、消息中间件：ActiveMQ、RabbitMQ、工作流中间件:JBPM。 6、精通shell编程，熟练应用awk、sed、grep、strace、tcudump、gdb等常用命令。 7、有大型分布式、高并发、高负载（大数据量）、高可用性系统设计开发经验。 8、对配置管理和敏捷研发模式有所了解（svn,git）。 9、熟悉常见的一些解决方案及其原理：单点登录、分布式缓存、SOA、全文检索、消息中间件，负载均衡、连接池、流计算等。 10、能大概知道市面上主流技术的特点及业务瓶颈。 好了，看完大概知道自己哪里不足

1. 简介 Kafka 是 LinkedIn 使用 Scala 编写具有高水平扩展和高吞吐量的分布式消息系统。 Kafka 对消息保存时根据 Topic 进行归类，发送消息者称为 producer，消息接收者称为 consumer，此外 Kafka 集群有多个 Kafka 实例组成，每个实例（server）称为 broker。 无论是 Kafka 集群，还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可用性，为集群保存一些 meta 信息。 2. 主流 MQ 对比 数据吞吐量：Kafka > RabbitMQ > ActiveMQ 数据准确性：RabbitMQ > ActiveMQ > Kafka ActiveMQ RabbitMQ Kafka 所属社区/公司 Apache Mozilla Public License Apache/LinkedIn 开发语言 Java Erlang Scala 支持的协议 OpenWire、STOMP、REST、XMPP、AMQP AMQP 仿 AMQP 事务 支持 不支持 0.11 开始支持 集群 支持（不擅长） 支持（不擅长） 支持 负载均衡 支持 支持 支持 动态扩容 不支持 不支持 支持（zk） 3. Kafka 主要特性 Kafka 是一个流处理平台，流平台需如下特性： 可发布和订阅流数据

什么是MQ？ 消息总线(Message Queue)，是一种跨进程、异步的通信机制，用于上下游传递消息。 由消息系统来确保消息的可靠传递。 MQ是干什么用的？ 应用解耦、异步、流量削锋、数据分发、错峰流控、日志收集等等... MQ衡量标准 服务性能、数据存储、集群架构 ActiveMQ ActiveMQ是apache出品，最流行的，能力强劲的开源消息总线，并且它一个完全支持JMS规范的消息中间件。其丰富的API、多种集群构建模式使得它成为业界老牌消息中间件，在中小型企业中应用广泛。 是其性能稍差，在面对高并发的情况下，会出现消息阻塞、堆积、延迟等问题。 默认采用了基于内存的kahaDB进行存储，如果需要保证消息的可靠性，也可以选择关系行数据库进行存储。 集群架构模式如下： Master-Slave模式：通过zookeeper对主从进行管理，正常情况下，从节点不会提供服务。当主节点出现问题后，zookeeper会高效的将主节点下掉，从节点来提供服务。 NetWork模式：两套主从Master-Slave节点。由网络联通，将其变为分布式的集群架构。 Kafka Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点就是 基于Pull的模式来处理消息消费 ， 追求高吞吐量 ，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制

一、简介 Redis 它的英文全名是 Remote Dictionary Server ，翻译成中文叫做远程字典服务。是由C语言编写的，遵守BSD协议，完全开源免费的一款NoSql数据库。 BSD是" Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。 BSD 开源协议 是一个给于使用者很大自由的协议。可以自由的使用，修改 源代码 ，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件： 1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。 2． 如果 再发布 的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。 3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发 商业软件 发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 二、redis特点 redis是一个高性能的key-value数据库 redis性能极高，一般情况下

1 概述 最近生产环境的消息通知队列发生了大量的数据积压问题，从而影响到整个平台商户的交易无法正常进行，最后只能通过临时关闭交易量较大的商户来缓解消息队列积压的问题，经线上数据分析，我们的消息队列在面对交易突发洪峰的情况下无法快速的消费并处理队列中的数据，考虑到后续还会出现各种交易量突发状况，以下为针对消息队列（ActiveMQ）的优化过程。 2 消息队列通信图 3 问题定位与分析 3.1 消息通知数据为什么会被积压？ 分析：平台中每个交易的发生可能会产生一到多条的消息通知数据，这些通知数据会通过消息队列（ActiveMQ）来中转消费并处理，那么在交易量突发洪峰的情况下会产生大量的消息通知数据，如果消息队列（ActiveMQ）的消费能力被阻塞的话会严重影响到数据的吞吐量，从而积压大量数据无法被快速处理！ 3.2 配置了多个ActiveMQ的消费者为什么数据积压还是无法缓解？ 分析：经过分析消息队列的数据消费处理模块的代码，消息的消费处理是通过监听器SessionAwareMessageListener异步回调onMessage方法而接收消息的，但是在回调的方法onMessage上加了synchronized同步锁，问题就在这里，由于整个onMessage方法被锁，导致程序只能通过串行（一次只能消费一条数据）处理数据，而无法通过多线程并发处理数据，从而影响了整个队列的数据消费能力。