mq

Spring Cloud Stream消息总线 Springcloud 里面对于MQ的整合一个是前一篇的消息总线一个是本文介绍的消息驱动 大体要学习这么几个知识点： 课题:SpringCloud消息驱动Stream 1.什么是SpringCloud消息驱动 2.消息驱动Stream实现原理 3.消息驱动Stream与传统MQ区别 4.基于消息驱动整合Kafka 5.基于消息驱动整合Rabbitmq 6.基于消息驱动Stream消息分组 什么是消息驱动？ SpringCloud Stream消息驱动可以简化开发人员对消息中间件的使用复杂度，让系统开发人员更多尽力专注与核心业务逻辑的开发。SpringCloud Stream基于SpringBoot实现，自动配置化的功能可以帮助我们快速上手学习，类似与我们之前学习的orm框架，可以平滑的切换多种不同的数据库。 目前SpringCloud Stream 目前只支持 RabbitMQ和kafka 在topic模式上 区别很大的 这两个MQ SpringCloud去整合了 类似于Hibernate 通过对象得到sql语句 开发人员不需要知道具体的MQ底层实现，只需要关心业务逻辑编码就OK了 底层是如何实现的？ Stream组件对rabbitMQ和kafka进行封装成同一个API，开发人员只需要对接Stream即可 ！ 消息驱动原理 绑定器

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

目前主流的MQ产品 1.ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。 扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。 2.RabbitMQ 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。 性能较好，但是不利于做二次开发和维护。 3.ActiveMQ 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好。 4.Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。 测试数据分为 128Bytes、512Bytes、1K和10K四个不同大小的数据。 实验表明：入队时

队列（Queue）和主题（Topic）是JMS支持的两种消息传递模型： 1、点对点（point-to-point，简称PTP）Queue消息传递模型： 通过该消息传递模型，一个应用程序（即消息生产者）可以向另外一个应用程序（即消息消费者）发送消息。在此传递模型中，消息目的地类型是队列（即Destination接口实现类实例由Session接口实现类实例通过调用其createQueue方法并传入队列名称而创建）。消息首先被传送至消息服务器端特定的队列中，然后从此对列中将消息传送至对此队列进行监听的某个消费者。同一个队列可以关联多个消息生产者和消息消费者，但一条消息仅能传递给一个消息消费者。如果多个消息消费者正在监听队列上的消息，JMS消息服务器将根据“先来者优先”的原则确定由哪个消息消费者接收下一条消息。如果没有消息消费者在监听队列，消息将保留在队列中，直至消息消费者连接到队列为止。这种消息传递模型是传统意义上的懒模型或轮询模型。在此模型中，消息不是自动推动给消息消费者的，而是要由消息消费者从队列中请求获得。 2、发布/订阅（publish/subscribe，简称pub/sub）Topic消息传递模型： 通过该消息传递模型，应用程序能够将一条消息发送给多个消息消费者。在此传送模型中，消息目的地类型是主题

版本不兼容 erl：otp_win64_21.0.1.exe rabbitmq：rabbitmq-server-3.8.1.exe（2019.12.06时最新版） 根据官方文档的匹配表： https://www.rabbitmq.com/which-erlang.html 可知若erl为21.0.1，则mq范围在3.7.[7-18]，我选择下载3.7.18（其中因为erl下载奇慢无比，有时候还断掉，所以我选择保持erl 21.0.1，改掉mq另一个版本来妥协） 来源： https://www.cnblogs.com/Roni-i/p/11994751.html

目的：　　 消息如何保证100%的投递 幂等性概念 Confirm确认消息 Return返回消息 自定义消费者 前言： 　　 想必知道消息中间件RabbitMQ的小伙伴，对于引入中间件的好处可以起到抗高并发，削峰，业务解耦的作用并不陌生。 　　康康简单流程图了解一下。详情了解RabbitMQ可移步： https://www.cnblogs.com/huangting/p/11989597.html 注意：一般MQ中间件为了提高系统的吞吐量会把消息保存在内存中，如果不作其他处理，MQ服务器一旦宕机，消息将全部丢失； 　　这样会造成巨大影响，在业务流程上是不可以的。 以下就是我们去解决所使用的方法 消息如何保证100%的投递 　　 什么是生产端的可靠性投递？ 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点（Broker）确认应答 完善的消息进行补偿机制（如网络问题没有返回确认应答 ） 幂等性概念 Confirm确认消息 Return返回消息 自定义消费者 来源： https://www.cnblogs.com/huangting/p/11994539.html

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

目前主流的MQ产品 1.ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。 扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。 2.RabbitMQ 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。 性能较好，但是不利于做二次开发和维护。 3.ActiveMQ 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好。 4.Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。 测试数据分为 128Bytes、512Bytes、1K和10K四个不同大小的数据。 实验表明：入队时