mq

ActiveMQ 　　 单机吞吐量： 万级 　　 topic数量对吞吐量的影响： 　　 时效性： ms级 　　 可用性： 高，基于主从架构实现高可用性 　　 消息可靠性： 有较低的概率丢失数据 　　 功能支持： MQ领域的功能极其完备 　　 总结： 　　　　非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用 　　　　偶尔会有较低概率丢失消息 　　　　现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本 　　　　主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 RabbitMQ 　　 单机吞吐量： 万级 　　 topic数量对吞吐量的影响： 　　 时效性： 微秒级，延时低是一大特点。 　　 可用性： 高，基于主从架构实现高可用性 　　 消息可靠性： 　　 功能支持： 基于erlang开发，所以并发能力很强，性能极其好，延时很低 　　 总结： 　　 　　　　erlang语言开发，性能极其好，延时很低； 　　　　吞吐量到万级，MQ功能比较完备 　　　　开源提供的管理界面非常棒，用起来很好用 　　　　社区相对比较活跃，几乎每个月都发布几个版本分 　　　　在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。 　　　

这篇文章有一半是copy别人的，站在巨人的肩膀上，我们才能看得更高更远...... 在开始讨论android的消息处理机制前，先来谈谈一些基本相关的术语。 通信的同步 （Synchronous）：指向客户端发送请求后，必须要在服务端有回应后客户端才继续发送其它的请求，所以这时所有请求将会在服务端得到同步，直到服务端返回请求。 通信的异步 （Asynchronous）：指客户端在发送请求后，不必等待服务端的回应就可以发送下一个请求。 所谓同步调用，就是在一个函数或方法调用时，没有得到结果之前，该调用就不返回，直到返回结果。异步调用和同步是相对的，在一个异步调用发起后，被调用者立即返回给调用者，但是调用者不能立刻得到结果，被调用都在实际处理这个调用的请求完成后，通过状态、通知或回调等方式来通知调用者请求处理的结果。 android的消息处理有三个核心类：Looper,Handler和Message。其实还有一Message Queue（消息队列），但是 MQ被封装到Looper里面了，我们不会直接与MQ打交道，所以它不算是个核心类。 1. 消息类：Message类 android.os.Message的主要功能是进行消息的封装，同时可以指定消息的操作形式，Message类定义的变量和常用方法如下： （1）public int what：变量，用于定义此Message属于何种操作 （2

高可用，重复消费，幂等，可靠性传输，消息丢失 1、 kafka,rabbitMQ,activemq,rocketMQ使用场景及区别技术选型 吞吐量、topic数量对吞吐量的影响、时效性、可用性、可靠性、核心特点、优劣势总结 activemq：吞吐量万级 非常成熟，功能比较强大，大量的公司再项目中有应用 偶尔会有低概消息丢失，近些年应用越来越少 官方社区维护越来越少，而且确实主要基于解耦和异步来用的，较少在大规模吞吐的场景下使用 rabbitMQ: 吞吐量万级 跟服务器有关系 基于erlang开发，性能较好 延时低，而且提供开源的管理界面 社区比较活跃，近些年互联网公司用rabbitmq的比较多，因为基于erlang语言 不懂源码，比较难进行定制和掌控； rocketMQ:单机吞吐量10w，topic可以达到几百或者上千级别 topic越多吞吐量会有较小幅度的下降，阿里大规模使用，比较可靠、日处理消息上百亿、拓展方便、社区维护可以，只会复杂MQ业务场景 kafka:功能简单，主要支持简单的mq功能，ms级延迟 极高的可用性和可靠性不过有消息重复消费 在大数据领域的实时计算以及日志采集被大规模使用。 中小型公司：rabbitMQ，技术实力一般 挑战不是很高 社区比较活跃； 大型公司：rocketMQ 基础架构研发实力较强 如果是大数据领域的实时计算、日志采集等场景

目录 RocketMQ 源码学习笔记————Producer 是怎么将消息发送至 Broker 的？ 前言 项目结构 rocketmq-client 模块 DefaultMQProducerTest RocketMQ 源码学习笔记————Producer 是怎么将消息发送至 Broker 的？ 前言 本次分析基于 RocketMQ release-4.5.2 版本。 分析的目标是： RocketMQ 中 Producer 是怎么将消息发送至 Broker 的？ 说到学习源码，首先当然是要把源代码下载下来， 官方地址 。使用 git clone https://github.com/apache/rocketmq.git 将源代码 clone 至本地。 项目结构 用 IDEA 打开该项目 rocketmq-client 模块 可以看到有很多子模块，这次学习的是 Producer 故打开 rocketmq-client 模块，可以在单元测试用找到测试 Producer 功能的类。 DefaultMQProducerTest 打开该类，观察其方法 可以看出以 test 开头的方法都是单元测试方法，可以直接运行。 init 方法和 terminate 分别是单元测试的初始化方法和销毁方法。 init 和 terminate // 创建一个默认的客户端实例 @Spy private

本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎，进行各种聚合运算，产生输出结果，并且写入下游。 现代的一些处理框架

https://www.cnblogs.com/PatrickLiu/tag/RabbitMQ/ 来源： https://www.cnblogs.com/macT/p/11646051.html

rabbitMQ是一个在AMQP协议标准基础上完整的，可服用的企业消息系统。他遵循Mozilla Public License开源协议。采用 Erlang 实现的工业级的消息队列(MQ)服务器。 RabbitMQ的官方站： http://www.rabbitmq.com/ AMQP (高级消息队列协议) 是一个异步消息传递所使用的应用层协议规范，作为线路层协议，而不是API（例如JMS），AMQP 客户端能够无视消息的来源任意发送和接受信息。AMQP的原始用途只是为金融界提供一个可以彼此协作的消息协议，而现在的目标则是为通用消息队列架构提供通用构建工具。因此，面向消息的中间件 （MOM）系统，例如发布/订阅队列，没有作为基本元素实现。反而通过发送简化的AMQ实体，用户被赋予了构建例如这些实体的能力。这些实体也是规范的一 部分，形成了在线路层协议顶端的一个层级：AMQP模型。这个模型统一了消息模式，诸如之前提到的发布/订阅，队列，事务以及流数据，并且添加了额外的特性，例如更易于扩展，基于内容的路由。 AMQP当中有四个概念非常重要 virtual host，虚拟主机 exchange，交换机 queue，队列 binding，绑定 一个虚拟主机持有一组交换机、队列和绑定。 为什么需要多个虚拟主机呢？因为RabbitMQ当中，用户只能在虚拟主机的粒度进行权限控制。因此

RabbitMQ 解决大量 unacked 问题 为了快速响应用户请求，我们需要消息异步处理机制，比较简单的做法是用 redis 的 List 结构，我们项目使用更专业的 RabbitMQ 。关于 redis 和 RabbitMQ 队列处理的性能比较可以查看这篇文章 http://blog.csdn.net/educast/article/details/34521603 这里不扯 RabbitMQ 的一些定义了，我们遇到的问题是，入队并发和速度速度很快，但是消费端的处理速度慢得惊人。为了数据安全我们做了持久化而且消费端需要 ack 或者 unack 响应。从其提供的 web 控制台可以看到量大的时候产生大量的 unacked 消息，也就是说 MQ 把数据放到 channel 里，很长时间过去了 channel 没有给任何响应。我们创建了 600 个 channel 问题也依旧。查看了硬件没有瓶颈，网上有文章说是 channel 连接断了 mq 无法及时识别，还会往这些失效的 channel 里传递数据，误认子弟啊，拉出去枪毙了。 Netstat 一下，发现一共 MQ 服务器一共有 4 个外部连接连入了 5672 端口，两个 productor 两个 consumer 跟预想的一样。 Jstack 一下，发现 pool-xxx 线程远远没有预想的多，才 50 个，我们创建了 600

目前RabbitMQ官方给的出的客户端发送消息的Demo的都是基于短连接来做的，例如： ConnectionFactory cf = new ConnectionFactory(); cf.Uri = serverAddress; using (IConnection conn = cf.CreateConnection()) { using (IModel ch = conn.CreateModel()) { if (exchange != “”) { ch.ExchangeDeclare(exchange, exchangeType); } ch.BasicPublish(exchange, routingKey, null, Encoding.UTF8.GetBytes(message)); } } 我们刚开始也是采用这种方式来实现的，但做压力测试时，发现这种每次新建Connection和新建Channel是非常耗时的，在大并发下，一般都要8毫秒左右，慢的话，好多都是几十毫秒，为此，我专门查了资料，得出如下结论： 1、Rabbit Client提供的连接方式介绍： RabbitMQ官方提供了： Connection对象，就是一个TCP连接对象。 Channels对象，虚拟连接。虚拟连接建立在上面Connection对象的TCP连接中。数据流动都是在Channel中进行的

交换器介绍   RabbitMQ中有三种主要的交互器分别如下 交换器 说明 direct 发布与订阅 完全匹配 fanout 广播 topic 主体，规则匹配 Fanout   FanoutExchange 的数据交换策略是把所有到达 FanoutExchang 的消息转发给所有与它绑定的Queue ，在这种策略中， routingkey 将不起任何作用. 1.创建消费者 项目结构 配置文件 spring.application.name=springcloud-mq spring.rabbitmq.host=192.168.88.150 spring.rabbitmq.port=5672 spring.rabbitmq.username=dpb spring.rabbitmq.password=123 mq.config.exchange=order.fanout #短信服务队列名称 mq.config.queue.sms=order.sms #push 服务队列名称 mq.config.queue.push=order.push 两个消费者 @Component @RabbitListener ( bindings = @QueueBinding ( value = @Queue ( value = "${mq.config.queue.sms}" , autoDelete =