mq

RabbitMQ之入门 一、什么是MQ？ 消息队列(Message Queue，简称MQ)，从字面意思上看，本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已 二、主流MQ框架 MQ框架非常之多，比较流行的有RabbitMq、ActiveMq、ZeroMq、kafka，以及阿里开源的RocketMQ。 区别： 本文主要介绍RabbitMQ 三、应用场景 主要解决异步处理、应用解耦、流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构 1.异步处理 用户注册后，需要发注册邮件和注册短信 2.应用解耦 用户下单后，订单系统需要通知库存系统 3.流量削锋(重点) 流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛，例如双十一 四、Docker安装部署RabbitMQ 注意获取镜像的时候要获取 management 版本的，不要获取last版本的，management版本的才带有管理界面 1.查询镜像 $ docker search rabbitmq : management 2.获取镜像 $ docker pull rabbitmq : management 3.运行镜像 ##方式一：默认guest用户，密码也是guest $ docker run - d - p 5672 : 5672 - p 15672 : 15672 -- name

到目前为止，我们已经基本掌握了MQ的相关核心工作原理，同时一起设计了消息路由中心 （ 消息中间件路由中心你会设计吗，不会就来学学 ）和 Broker 主从架构( 消息队列Broker主从架构详细设计方案，这一篇就搞定主从架构 )，现在如果让你基于它的基本原理去设计一套 MQ 的生产部署架构出来，你准备怎么去思考呢？ 在这套架构中，你需要着重考虑的就是高可用问题，也就是说要保证整个系统在运行过程中，其中的任何一个环节宕机都不能影响整个系统。今天我们就来打卡如何设计一套高可用的消息中间件生产部署架构。 NameServer 集群化，保证路由高可用 首先，我们就是需要将NameServer 集群化部署，这里建议可以部署三台机器，这样可以充分的保证我们消息路由中心的可用性，哪怕其中的两台挂了，也还有一台 NameServer 在运行，这样就能保证我们 MQ 系统的稳定性。 前面我们也知道我们的NameServer 设计采用的是Peer-to-Peer 模式，即可以支持集群化部署的，每台机器是独立运行的，他们彼此直接不直接通信。 每台NameServer 机器都拥有所有的路由信息，包括所有的 Broker 节点信息、数据信息等 ，这样只要有一台 NameServer 存活就不会影响系统的稳定性。 所以，消息路由中心 NameServer 的集群化是我们整个MQ生产部署的第一步。

MQ 全称为 Message Queue，消息队列（MQ）是一种应用程序对应用程序的通信方法，即我们常说的中间件之一，而 RabbitMQ 则是 MQ 的一种开源实现，遵循 AMQP（高级消息队列协议） 协议。 AMQP 相关概念 MQ 的模型从大体上看，都是类似的，如下： 而 RabbitMQ 由于是基于 AMQP 协议的开源实现，AMQP 协议比 MQ 模型有更加详细的模型概念，如下： 生产者发送消息给交换器，交换绑定消息队列，消息队列通过信道传送给消费者。 信道 如果项目需要发布消息，那么必须要链接到 RabbitMQ，而项目于 RabbitMQ之间使用 TCP 连接，加入每次发布消息都要连接TCP，这不仅会造成连接资源严重浪费，会造成服务器性能瓶颈，所以 RabbitMQ 为所有的线程只用一条 TCP 连接，怎么实现的呢？RabbitMQ 引入了信道的概念，所有需要发布消息的线程都包装成一条信道在 TCP 中传输，理论上 一条 TCP 连接支持无限多个信道，模型如下： 队列 消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。 绑定 绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则

什么是消息队列 MQ全称为Message Queue 消息队列（MQ）是一种应用程序对应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 你可以想想在生活中的一种场景：当你把信件的投进邮筒，邮递员肯定最终会将信件送给收件人。我们可以把MQ比作 邮局和邮递员。 MQ和邮局的主要区别是,它不处理消息,但是,它会接受数据、存储消息数据、转发消息 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 如果有人问你这个问题，期望的一个回答 是说，你们公司有个什么业务场景 ，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个： 解耦 、 异步 、 削峰 。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合

事务模式 事务具有原子性，MQ发送消息也应当具有原子性，下面介绍一下事务模式： send ： public class Send { private static final String QUEUE_NAME = "simple_mq" ; public static void main ( String [ ] args ) throws IOException , TimeoutException { Connection connection = RabbitConnection . getConnection ( ) ; Channel channel = connection . createChannel ( ) ; channel . queueDeclare ( QUEUE_NAME , false , false , false , null ) ; String message = "hello simple_mq" ; try { channel . txSelect ( ) ; channel . basicPublish ( "" , QUEUE_NAME , null , message . getBytes ( ) ) ; channel . txCommit ( ) ; } catch ( IOException e ) { channel .

原文: 使用内存映射开发高性能进程间消息通信组件 一、背景 　　项目开发中免不了各模块或系统之间进行消息通信，目前热门的消息中间件有Redis、RabbitMQ、Kafka、RocketMQ等等。 以上几种组件中Redis在消息队列方面表现还可以，但是如果涉及发布订阅功能，就不行了，最近项目就使用了redis的发布订阅， 每秒只能发出几千条，虽然目前绰绰有余，但是瓶颈可以预期。 　　其余的几种都是比较重量级的消息中间件，什么跨平台、分布式、集群、支持N种协议等等，很高大全， 我们可能就只使用了其中1、2个功能。严格来说，项目中集成这几种MQ的工作量是不小的，对于中小型系统来说，可能维护MQ 稳定的工作量都比项目还大，难度也高，所有功能用全了的程序员恐怕不多。 　　从长远考虑出发，选择重量级MQ恐怕是板上钉钉的事，但是项目一开始就上这几种，我觉得那也是欠缺考虑的。如果项目 根本不要求跨机器通信，那杀鸡就不要用牛刀了。比如，你只是在模块之间、线程之间、进程之间，或者是在同一主机的各种不同系统之间， 其实都可以不用重量级MQ。当然你使用了也没事，看个人选择。 　　最近的项目有这么个场景，采集近所有底层设备，每个设备有点3000个，总共20多万个点需要采集上来。刚开始使用了Redis的发布订阅， 但是程序毫无疑问地挂了，根本带不起来；因为程序启动时每个点的值都是从0变成N，就需要发消息出来