mq

1、为什么要引入MQ系统，直接读写数据库不行吗？ 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。 解耦：多系统多进程的数据交换，用pub/sub 异步：把大数据量的同步处理改为异步 削峰：一般的A 系统使用 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。如果使用 MQ， 每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最 大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉，这又设计请求排队的问题。 2、消息队列有什么优缺点？ 优点：解耦、异步、削峰 缺点： 系统可用性降低 系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD

RabbitMQ 基于AMQP协议， 默认的交换机类型direct，direct 直接转发，fanout广播模式，topic带通配符匹配的广播模式 direct 这种发送消息的模式，是最简单也是rabbitmq默认的一种，直接创建队列向其发送消息，等待监听者消费 // 直接注册一个常规队列，向这个队列发送消息 @Component public class SendMessage { @Bean public Queue getQueues() { return new Queue(RabbitConstant.HELLO_QUEUE); } @Autowired private AmqpTemplate amqpTemplate; public void send() { try { User user = new User(); user.setAddress("地址"); user.setAge("1"); user.setName("mq"); amqpTemplate.convertAndSend(RabbitConstant.HELLO_QUEUE, JSON.toJSONString(user)); } catch (Exception e) { e.getStackTrace(); } } } 这种队列是点对点的发送与接收，一个消息只能被所有监听者中的一个消费 //

WaitGroup提供3个方法实现优雅退出 1、Add() ：每收到http/mq请求，会在计数器+1 2、Done()：每执行完http/mq请求，会在计数器-1 3、Wait()：计数器=0，即没有正在处理的 请求 import "sync" import "os/signal" import "fmt" func main ( ) { var wg sync . WaitGroup sig := make ( chan os . Signal , 1 ) signal . Notify ( sigs , syscall . SIGINT , syscall . SIGTERM ) httpHandle ( ) go func ( ) { sig := <- sig wg . Wait ( ) done <- true } ( ) <- done fmt . println ( "quit success" ) } func httpHandle ( ) { wg . Add ( ) defer wg . Done ( ) xxx } signal.Notify的参数代表注册要接收的信号：没有信号参数表示接收所有的信号 syscall.SIGINT:接收ctrl+c syscall.SIGTERM:程序退出 PS：若进程是通过supervisor信号停止，本质执行的是kill

目录 消息队列功能 解耦 异步 流量削峰 消息分发 不同类型的消费者 推模型DefaultMQPushConsumer 推模型实现原理 推模型流量控制 拉模型DefaultMQPullConsumer 拉模型的操作方式 不同类型的生产者 DefaultMQProducer 同步发送 异步发送 单向发送 延迟消息 分布式消息队列的协调者 NameServer 的功能 集群状态的存储结构 为何不用ZooKeeper 消息存储结构 顺序写 随机读 零拷贝 高可用 消费端的高可用 发送端的高可用 刷盘方式 异步刷盘 同步刷盘 配置方式 主从复制方式 同步复制 异步复制 配置方式 刷盘、主从复制方式小结 顺序消息 全局顺序消息 部分顺序消息 发送端 消费端 消息重复 消息优先级 创建多个Topic 创建多个MessageQueue 吞吐量优先 在Broker端进行消息过滤 通过Tag进行过滤 通过SQL表达式进行过滤 通过FilterServer进行过滤 提高Consumer处理能力 增加Consumer实例数量，增加消费线程数量 以批量方式消费 跳过非重要消息 提高Producer发送速度 通过OneWay方式发送 多个Producer同时发送 消息发送超时 消费失败 并发消费失败 顺序消费失败 死信队列 消息队列功能 解耦 异步 流量削峰 消息分发 消息分发如下，各个子系统（消费者组

/*--> */ /*--> */ 消息服务 背景 ： 有时需与其它系统集成来完成相关业务功能 ，原始的做法是程序内部相互调用，除此之外，还可 用消息服务中间件来进行业务处理 ，使 用消息服务中间件处理业务能够提升系统的异步通信和扩展解耦的能力，个人有点面向切面的意思 。 一 . 为什么要使用消息服务 ？ 因为 它有很多好处，能解决很多问题； 1. 异步处理 2.流量消峰 3.提高效率和可靠性 二、RabbitMQ 消息中间件的原理和工作模式 RabbitMQ 消息中间件的原理： 1. 消息发布者 P 向 RabbitMQ 代理（ Broker ）指定虚拟主机服务器发送消息。 2. 虚拟主机服务器内部交换器接收消息，并将消息传递并存储到与之邦定的消息队列中。 3. 消息消费者通过网络连接与消息代理建立连接。并且为了简化开发，在连接内部使用了多路复用的信道进行消息的最终消费。 消息中间件的工作模式的分类、具体的实现步骤、适用场景 工作模式：Publish/Subscrib （发布订阅模式） step1. 先配置一个 fanout 类型的交换器。 step2. 不需指定对应的路由键，同时会将消息路由到每一个消息队列。 step3. 每个队列都可以对不同的消息进行接收存储，进而各自消息队列关联的消费者进行消费。 适用场景：相同业务功能处理的场合。如用户注册成功后

package com.hometest.IBMMqTest; import java.io.IOException; import java.io.UnsupportedEncodingException; import com.ibm.mq.MQEnvironment; import com.ibm.mq.MQException; import com.ibm.mq.MQGetMessageOptions; import com.ibm.mq.MQMessage; import com.ibm.mq.MQPutMessageOptions; import com.ibm.mq.MQQueue; import com.ibm.mq.MQQueueManager; import com.ibm.mq.constants.MQConstants; public class TestMQ { private MQQueueManager qmanager = null; private MQQueue queue = null; private static final String MQ_HOST =""; private static final Integer MQ_PORT =1414; private static final String MQ_CHANNEL ="";

一、spring中配置监听队列的MQ相关信息 注：${}是读取propertites文件的常量，这里忽略。绿色部分配置在接收和发送端都要配置。 <bean id=" axx " class=" com.ibm.mq.jms.MQQueueConnectionFactory "> <property name="hostName" value="${}" /> <property name="port" value="${}" /> <property name="queueManager" value="${}" /> <property name="channel" value="${}" /> <property name="CCSID" value="${}" /> <property name="transportType" value="1"/> </bean> <bean id=" bxx " class=" org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter "> <property name="targetConnectionFactory" ref=" axx " /> </bean> <!-- 定义一个队列，因为mq中消息有queue和topic的区别 -->

转载：http://blog.csdn.net/ozwarld/article/details/7735915 IBM MQ 6.0中设置两个队列，（远程队列、通道之类都不设置）。 队列管理器是XIR_QM_1502 队列名称是ESBREQ IP地址是10.23.117.134（远程的一台电脑，跟我的电脑不在一个局域网内） 端口1414 CCSID 1208 MQ配置可以参考这个，有配图 http://wenku.baidu.com/view/06d108d0360cba1aa811daa3.html 程序如下，发送线程两个，接收线程一个。接收完毕后就结束。 /* * 创建日期 2012-7-10 * * TODO 要更改此生成的文件的模板，请转至 * 窗口 － 首选项 － Java － 代码样式 － 代码模板 */ package yerasel; /** * @author Fenglb E-mail:56553655@163.com * @version 创建时间：2009-4-30 下午04:13:38 类说明 */ import java.io.IOException; import com.ibm.mq.MQC; import com.ibm.mq.MQEnvironment; import com.ibm.mq.MQException; import com.ibm

RocketMq系列，第一章 1、MQ介绍 1.1、为什么要用MQ 消息队列是一种“先进先出”的数据结构 其应用场景主要包含以下3个方面 1.1.1、应用解耦 ​ 系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。 ​ 使用消息队列解耦合。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统恢复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。 1.1.2、流量削封 ​ 应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。 ​ 一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总体下单体验要好。 ​ 出于经济考量的目的 ​ 业务系统正常时段的QPS如果是1000，流量最高峰是10000，为了应对流量高峰配置高性能的服务器显然不划算，这时可以使用消息队列对峰值流量削峰。 1.1.3、数据分发 ​

MQ 全称为 Message Queue ，即消息队列， RabbitMQ 是由 erlang 语言开发，基于 AMQP （ Advanced Message Queue 高级消息队列协议）协议实现的消息队列，它是一种应用程序之间的通信方法，消息队列在分布式系统开 发中应用非常广泛 应用场景 1 、任务异步处理。 将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。 2 、应用程序解耦合 MQ 相当于一个中介，生产方通过 MQ 与消费方交互，它将应用程序进行解耦合 Jms和AMQP区别 JMS 是 java 提供的一套消息服务 API 标准，其目的是为所有的 java 应用程序提供统一的消息通信的标准，类似 java 的 jdbc ，只要遵循 jms 标准的应用程序之间都可以进行消息通信。它和 AMQP 有什么 不同， jms 是 java 语言专属的消 息服务标准，它是在 api 层定义标准，并且只能用于 java 应用；而 AMQP 是在协议层定义的标准，是跨语言的 Broker ：消息队列服务进程，此进程包括两个部分： Exchange 和 Queue 。 Exchange ：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过虑。 Queue ：消息队列，存储消息的队列，消息到达队列并转发给指定的消费方。