消息队列

文章目的: 关于rabbitmq日志记录的文章,比较多的提及如何用rabbitmq记录日志. 本文要提及的是,记录rabbitmq的发送消息以及接收消息记录. rabbitmq记录自身的日志,有对应的方案,比如使用trace 命令行开启trace: rabbitmqctl trace_on 命令行关闭trace: rabbitmqctl trace_off 自定义queue,绑定到amq.rabbitmq.trace(exchange) 此方案的作用: 可以记录所有发送和接收的消息,不管消费方是否成功消费. 使用trace无法实现的功能: 业务方是否消费成功. 使用切面方式,记录消息队列发送,接收,消费的日志. 1.通过切面,记录消息发送消息,并生成messageI方便消息跟踪. 2.通过界面,记录消息接收内容,并存储到日志或者数据库. 参考文献: rabbitmq–trace 来源： CSDN 作者： 奔随梦 链接： https://blog.csdn.net/lzhlove/article/details/103559894

一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式 a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。 b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？ 引入消息队列

转载 https://cloud.tencent.com/developer/article/1399226 首席架构师智库 发表于 智能计算时代 订阅 382 在这篇文章中： RabbitMQ Apache Kafka 结论 在这一部分中，我们将探讨RabbitMQ和Apache Kafka以及它们的消息传递方法。每种技术在设计的每个方面都做出了截然不同的决定，每种方面都有优点和缺点。我们不会在这一部分得出任何有力的结论，而是将其视为技术的入门，以便我们可以深入探讨该系列的后续部分。 RabbitMQ RabbitMQ是一个分布式 消息队列 系统。分布式，因为它通常作为节点集群运行，其中队列分布在节点上，并可选择复制以实现容错和高可用性。它原生地实现了AMQP 0.9.1，并通过插件提供其他协议，如STOMP，MQTT和HTTP。 RabbitMQ同时采用经典和新颖方式。从某种意义上来说，它是面向消息队列的经典，并且具有高度灵活的路由功能。正是这种路由功能才是其杀手级功能。构建快速，可扩展，可靠的分布式消息传递系统本身就是一项成就，但消息路由功能使其在众多消息传递技术中脱颖而出。 交换机（exchanges）和队列 超简化概述： 发布者向交换机（exchanges）发送消息 将消息路由到队列和其他交换机（exchanges） RabbitMQ在收到消息时向发布者发送确认

在阅读完uC/OS-III（V3.03.01）和FreeRTOS（V10.0.1）的源码后，我对RTOS有了较深的认识。现将它们之间的一些区别总结出来，有利于大家理解这两个RTOS。 1、uCOS-III中所有的内核对象（如任务控制块、消息队列、信号量等）都是静态创建的，需要用户提供。FreeRTOS中的内核对象支持动态和静态两种创建方法。 （PS： 其实系统提不提供动态创建功能并不那么重要，因为在静态创建的方法的基础上加入内存管理机制，就能自已封装实现动态创建函数） 2、uCOS-III中的任务状态较多，因为它存在“基本状态+挂起状态”这类状态，FreeRTOS中挂起态是个单独的状态。在FreeRTOS中，如果suspend一个正在阻塞的任务，API内部会把任务从相应阻塞表中删除，并将其挂在xSuspendedTaskList上，当该任务被resume后，它就是就绪态，而不会重新返回阻塞态。而uCOS-III中的任务即便在阻塞时被suspend了，它依然处于阻塞态（即等待某个事件发生），如果在suspend的过程中事件发生了，它将解除阻塞态，变为纯粹的挂起态；如果在resume后，该事件仍未发生，它将解除挂起态，变为阻塞态。 （PS： 我感觉uCOS-III中的“挂起”更能称之为“挂起”） 3、为了实现中断和任务的同步，需要在中断中进行post操作，uC/OS

kafka:消息引擎系统 Kafka 的标准定位是分布式流式处理平台（ Kafka 0.10.0.0 版本正式推 出了 Kafka Streams ，即流式处理组件 。自 此 Kafka 正式成为了 个流式处理框架，而不仅仅是 消息引擎了。 ） 消息引擎系统的两个重要因素： 消息设计 + 传输协议设计 消息设计：即结构化消息，如soap的xml格式，webservcie的json，kafka采用二进制； 传输协议设计：主流的有AMQP，webservice,RPC中有阿里的dubbo，kafka自己设计了一套二进制消息传输协议； 消息引擎范型：消息队列模型（queue\sender\receiver\p2p）、发布/订阅模型(pub/sub/topic) kafka的设计理念： 吞吐量/延时（高并发性）； 消息持久化（高可靠性）； 负载均衡和故障转移（高可用性）； 伸缩性； 一、kafka的高吞吐量、低延时 采用了追加写入消息的方式，即只能在日志文件末尾追加写入的新消息，且不允许修改已写入的消息，因此它属于典型的磁盘顺序访问型操作，在实际操作中可以很轻松的做到每秒写入几万甚至几十万条消息。 如果我 们监控 一个经过良好调优的 Kafka 生产集群便 可以发现，即使是那些有负载的 Kafka 服务器，其磁盘的读操作也很少，这是因为大部分的消 息读取操作会直接命中页缓存。 二、持久化：

RabbitMQ的六种工作模式 一.基于erlang语言： 是一种支持高并发的语言 RabbitMQ的六种工作模式： 1.1 simple简单模式 消息产生着§将消息放入队列 消息的消费者(consumer) 监听(while) 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失)应用场景:聊天(中间有一个过度的服务器;p端,c端) 1.2 work工作模式(资源的竞争) 消息产生者将消息放入队列消费者可以有多个,消费者1,消费者2,同时监听同一个队列,消息被消费?C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患,高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize,与同步锁的性能不一样) 保证一条消息只能被一个消费者使用) 应用场景:红包;大项目中的资源调度(任务分配系统不需知道哪一个任务执行系统在空闲,直接将任务扔到消息队列中,空闲的系统自动争抢) 1.3 publish/subscribe发布订阅(共享资源) X代表交换机rabbitMQ内部组件,erlang 消息产生者是代码完成,代码的执行效率不高,消息产生者将消息放入交换机,交换机发布订阅把消息发送到所有消息队列中,对应消息队列的消费者拿到消息进行消费 相关场景:邮件群发

业务场景说明 : 消息队列在大型电子商务类网站，如京东、淘宝、去哪儿等网站有着深入的应用， 队列的 主要作用 是 消除高并发访问高峰 ， 加快网站的响应速度 。 在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下，会对数据库造成巨大的压力，同时也使得系统响应延迟加剧。 在使用队列后，用户的 请求发给队列 后立即返回, （例如: 当然不能直接给用户提示订单提交成功，京东上提示：您“您提交了订单，请等待系统确认”）， 再由消息队列的 消费者 进程 从消息队列 中 获取数据 ， 异步写入数据库 。 由于消息队列的服务处理速度 远快于数据库 ，因此用户的 响应延迟可得到有效改善 。 图解说明: 1. 消息队列说明 消息队列中间件是 分布式系统中重要的组件 ，主要解决应用耦合，异步消息，流量削锋等问题。 实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有 ActiveMQ ， RabbitMQ ， ZeroMQ ， Kafka ， MetaMQ ， RocketMQ 等。 2. 消息队列应用场景 消息队列在实际应用中常用的使用场景。 异步处理，应用解耦，流量削锋和消息通讯四个场景 。 2.1. 异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1. 串行的方式； 2. 并行方式。

介绍 RabbitMQ 解耦组件是软件设计的重要部分，其中一种实现是使用消息系统。其提供异步方式实现组件或服务间通信。本文我们介绍其中一个消息系统实现：RabbitMQ。 RabbitMQ是实现Advanced Message Queuing Protocol (AMQP)协议的消息代理中间件，对主流语言都提供了客户端库。 除了对软件组件进行解耦，还可以用于下列场景： 执行后端操作 执行异步操作 在网络仅允许单向访问时，使用可以避免繁琐的轮询方式。 1. 消息模型 首先我们从高层看下消息是如何工作的。简言之，有两类应用于消息系统进行交互：生产者和消费者。生产者给代理发送(发布)消息，消费者从代理接收消息。通常这些软件组件运行在不同的主机上，RabbitMQ作为它们之间通信中间件。 本文我们讨论一个简单示例，两个组件使用RabbitMQ进行通信，其中一个服务负责发布消息至RabbitMQ，另一个负责消费。 2. 示例实现 2.1. 环境准备 开始之前需要先运行RabbitMQ，读者可以参考 官方指南 。 当然我们需要使用Java客户端与RabbitMQ服务端进行交互，Maven依赖如下： <dependency> <groupId>com.rabbitmq</groupId> <artifactId>amqp-client</artifactId> <version>4.0.0<

Kafka工作流程分析 写入方式 producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。 分区（Partition） Kafka集群有多个消息代理服务器（broker-server）组成，发布到Kafka集群的每条消息都有一个类别，用主题（topic）来表示。通常，不同应用产生不同类型的数据，可以设置不同的主题。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生成者写入的新消息。 Kafka集群为每个主题维护了分布式的分区（partition）日志文件，物理意义上可以把主题（topic）看作进行了分区的日志文件（partition log）。主题的每个分区都是一个有序的、不可变的记录序列，新的消息会不断追加到日志中。分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，叫做偏移量（offset），这个偏移量能够唯一地定位当前分区中的每一条消息。 消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成，其组织结构如下图所示： 下图中的topic有3个分区，每个分区的偏移量都从0开始，不同分区之间的偏移量都是独立的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Android系统的消息队列和消息循环都是针对具体线程的，一个线程可以存在（当然也可以不存在）一个消息队列（Message Queue）和一个消息循环（Looper）。Android中除了UI线程（主线程），创建的工作线程默认是没有消息循环和消息队列的。如果想让该线程 具有消息队列和消息循环，并具有消息处理机制，就需要在线程中首先调用Looper.prepare()来创建消息队列，然后调用 Looper.loop()进入消息循环。如以下代码所示： class LooperThread extends Thread { public Handler mHandler; public void run() { Looper.prepare(); mHandler = new Handler() { public void handleMessage(Message msg) { // process incoming messages here } }; Looper.loop(); } } 这样该线程就具有了消息处理机制了。如果不调用Looper.prepare()来创建消息队列，会 报"java.lang.RuntimeException: Can't create handler inside thread