mq

为什么使用消息中间件？ 消息队列核心使用场景<优点>： 解耦、异步、削峰 (1)解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 消息中间件缺点有哪些？ 系统可用性降低 系统引入的外部依赖越多，越容易挂掉，需要保证消息队列的高可用。 系统复杂度提高 多一个 MQ 组件，那就需要面对 消息没有重复消费，处理消息丢失的情况，保证消息传递的顺序性等等系统级别问题。 一致性问题 多个消费者消费某一个消息就可能出现个别消费失败的情况，会出现数据不一致。 ActiveMQ、RabbitMQ、RocketMQ、Kafka

一. 什么是消息中间件 利用高效可靠的消息传递机制进行平台无关的数据交流； 并给予数据通信来进行分布式系统的集成； 通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 二.消息中间件应用场景 1.跨系统数据传递 2.高并发流量的削峰， 3.数据的异步处理。 三.常用消息中间件 ActiveMQ：由Apache纯用java进行开发的消息中间件，存在的时间久远，完全遵循JMS进行开发。 RabbitMQ：支持的消息分发机制最全，使用Erlang语言进行开发的 Kafka：使用scala和java进行开发的语言，为了弥补Activemq的吞吐量低而进行开发的语言。具有高吞吐量的特点，可以和Hadoop结合。进行大数据的开发。 RocketMQ：由阿里使用java开发的一个高性能分布式，经受了双十一的考验。 四.消息中间件核心设计及各部分概述 本质：一种具有接受请求，保存数据，发送数据等功能的网络应用和一般网络应用程序的区别是它主要负责数据的接受和传递，所以性能优于普通程序。 1.协议（语法，语义，同步） ： OpenWire :ActiveMQ专属 AMQP :事务支持，持久化支持，出生于金融，可靠性高（RabbitMQ，ACTIVEMQ） MQTT :即时通讯协议，主要用去物联网，轻量级，结构简单，传输快，不支持事务，没有持久化相关设计。适用于计算能力有限低带宽

消息队列 为什么要用消息队列，都有什么优缺点？ 要问的是消息队列都有哪些场景，然后项目里具体实现的什么场景，你在这个场景里用的什么消息队列？ 期望的回答是， 你们公司有个什么业务，这个业务场景有什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ带给你什么好处？ 场景比较多，但是比较核心的是3个： 解耦、异步、削峰 解耦 ​ 需要去考虑你负责的系统中是否有类似的场景，一个系统调用了多个系统和模块，互相之间的调用很复杂，维护起来很麻烦。但是这个调用并不需要直接同步调用接口，如果用MQ给它异步化解耦，也是可以的，你就需要 考虑在你的项目中，是不是可以运用这个MQ去进行解耦。在简历中体现出来 异步化 异步化可以大幅度提升高延迟接口的性能 削锋： 未使用MQ的时候： 使用MQ以后： 系统架构中引入MQ后可能存在的缺陷： 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。 系统的复杂性更高：需要考虑的问题越多 一致性问题 问题2：kafka,activeMq,rabbitMq,rocketMq 都有什么优缺点？ 特性 ACTIVEMQ RABBITMQ ROCKETMQ KAFKA 单击吞吐量 万级吞吐量，相比RocketMq和Kafka要第一个数量级 万级，吞吐量相比RocketMq和 Kafka要低一个数量级 10万级，RocketMq也是可以支撑高吞吐的一种MQ 10万级别

定义 Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于 大数据实时处理领域。 使用消息队列的好处 1）解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 3）缓冲 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。 4）灵活性 & 峰值处理能力 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。 如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列 能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 5）异步通信 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户 把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要 的时候再去处理它们。 来源： https://www.cnblogs.com/kbian/p/12331239.html

Celery介绍和基本使用 Celery 是一个 基于python开发的分布式异步消息任务队列，通过它可以轻松的实现任务的异步处理， 如果你的业务场景中需要用到异步任务，就可以考虑使用celery， 举几个实例场景中可用的例子: 1）你想对100台机器执行一条批量命令，可能会花很长时间 ，但你不想让你的程序等着结果返回，而是给你返回 一个任务ID,你过一段时间只需要拿着这个任务id就可以拿到任务执行结果， 在任务执行ing进行时，你可以继续做其它的事情。 2）你想做一个定时任务，比如每天检测一下你们所有客户的资料，如果发现今天 是客户的生日，就给他发个短信祝福 Celery 在执行任务时需要通过一个消息中间件来接收和发送任务消息，以及存储任务结果， 一般使用rabbitMQ or Redis,后面会讲 1.1 Celery有以下优点： 简单：一单熟悉了celery的工作流程后，配置和使用还是比较简单的 高可用：当任务执行失败或执行过程中发生连接中断，celery 会自动尝试重新执行任务 快速：一个单进程的celery每分钟可处理上百万个任务 灵活： 几乎celery的各个组件都可以被扩展及自定制 Celery包含如下组件： Celery Beat：任务调度器，Beat进程会读取配置文件的内容周期性地将配置中到期需要执行的任务发送给任务队列。 Celery Worker

1 入门概述 来源： https://www.cnblogs.com/xuweiweiwoaini/p/12302060.html

线程中通信 在裸机编程中，经常会使用全局变量进行功能间的通信，如某些功能可能由于一些操作而改变全局变量的值，另一个功能对此全局变量进行读取，根据读取到的全局变量值执行相应的动作，达到通信协作的目的； 邮箱 邮箱服务是实时操作系统中一种典型的线程间通信方法。举一个简单的例子，有两个线程，线程 1 检测按键状态并发送，线程 2 读取按键状态并根据按键的状态相应地改变 LED 的亮灭。这里就可以使用邮箱的方式进行通信，线程 1 将按键的状态作为邮件发送到邮箱，线程 2 在邮箱中读取邮件获得按键状态并对 LED 执行亮灭操作。 邮箱的工作机制 RT-Thread 操作系统的邮箱用于线程间通信，特点是开销比较低，效率较高； 邮箱中的每一封邮件只能容纳固定的 4 字节内容（针对 32 位处理系统，指针的大小即为 4 个字节，所以一封邮件恰好能够容纳一个指针）。典型的邮箱也称作交换消息，如下图所示，线程或中断服务例程把一封 4 字节长度的邮件发送到邮箱中，而一个或多个线程可以从邮箱中接收这些邮件并进行处理。 非阻塞方式的邮件发送过程能够安全的应用于中断服务中，是线程、中断服务、定时器向线程发送消息的有效手段。 通常来说，邮件收取过程可能是阻塞的，这取决于邮箱中是否有邮件，以及收取邮件时设置的超时时间。当邮箱中不存在邮件且超时时间不为 0 时，邮件收取过程将变成阻塞方式。在这类情况下

mq支持局部消息顺序消费，可以确保同一个消息消费队列中的消息被顺序消费。看下针对顺序消息在整个消费过程中做的调整： 队列负载： DefaultMQPushConsumerImpl#consumeOrderly决定是否是顺序消息， org.apache.rocketmq.client.impl.consumer.RebalanceImpl#rebalanceByTopic： 在新分配到队列时，新添加消息拉取任务之前会先检查是否是顺序消息。如果是顺序消息检查上锁是否成功： 消息拉取： DefaultMQPushConsumerImpl#pullMessage: 如果是顺序消息但队列未被锁定，则延迟3s后再将pullRequest对象放入到拉取任务中，如果该处理队列是第一次拉取任务，则首先计算拉取偏移量，然后向消息服务端拉取消息。 消息消费： public class ConsumeMessageOrderlyService implements ConsumeMessageService { private static final InternalLogger log = ClientLogger.getLog(); private final static long MAX_TIME_CONSUME_CONTINUOUSLY = Long.parseLong(System

【SpringBoot MQ系列教程】RabbitMq 初体验 mq 在异步解耦削峰的优势非常突出，现在很多的项目都会用到，掌握 mq 的知识点，了解如何顺畅的使用 mq，可以说是一个必备的职业技能点了 接下来我们进入 rabbitmq 的学习过程 I. 环境准备 在测试之前，需要安装 rabbitmq，下面分别给出 mac + centos 的安装教程 1. mac 安装 安装命令 brew install rabbitmq ## 进入安装目录 cd /usr/local/Cellar/rabbitmq/3.7.5 # 启动 brew services start rabbitmq # 当前窗口启动 rabbitmq-server 启动控制台之前需要先开启插件 ./rabbitmq-plugins enable rabbitmq_management 进入控制台: http://localhost:15672/ 用户名和密码：guest,guest 2. centos 安装 安装命令 yum install erlang wget http://www.rabbitmq.com/releases/rabbitmq-server/v3.6.15/rabbitmq-server-3.6.15-1.el6.noarch.rpm yum install rabbitmq-server-3

1、什么场景下使用消息队列？ 高并发环境 2、使用消息队列的优点和缺点： 优点： 解耦、异步、削峰 a、解耦 看这下面场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 D 系统现在不需要了呢？A 系统负责人几乎崩溃......  在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果 挂了 该咋办？ 要不要重发 ， 要不要把消息存起来？ 头发都白了啊！ 如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 总结 ：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。 面试技巧 ：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的