RabbitMQ:RabbitMQ之消息确认机制(事务+Confirm)

1、概述

在Rabbitmq中我们可以通过持久化来解决因为服务器异常而导致丢失的问题, 除此之外我们还会遇到一个问题:生产者将消息发送出去之后,消息到底有没有正确到达 Rabbit服务器呢?如果不错得数处理,我们是不知道的,(即Rabbit服务器不会反馈任何消息给生产者),也就是默认的情况下是不知道消息有没有正确到达;

RabbitMQ:Spring整合RabbitMQ

在前面的几篇博客里面已经把RabbitMQ的一些理论详细了说明了,在这一篇中将记录下Spring整合RabbitMQ,本文只是简单一个整合介绍,属于抛砖引玉,具体实现还需大家深入研究哈..

代码我会上传到我的码云上,如需下载请在文章的末尾寻找下载地址

1、POM引入

1
2
3
4
5
6
7
8
9
10
11
<!-- RabbitMQ -->
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>3.5.1</version>
</dependency>
<dependency>
<groupId>org.springframework.amqp</groupId>
<artifactId>spring-rabbit</artifactId>
<version>1.4.5.RELEASE</version>
</dependency>

RabbitMQ:Topic类型的exchange

尽管使用了direct类型的exchange对日志系统有所提升,但还是有一些限制(消息不能够基于多重因素来路由)。

在我们的日志系统中,希望不仅仅能够根据日志级别来订阅,还可以根据指定的routing key来订阅。你应该可以理解的,就如unix的系统日志工具,日志消息路由规则不仅仅基于日志级别(info/warn/crit…),还可以基于设备(auth/cron/kern…)。

RabbitMQ:订阅模式Publish:Subscribe

我们之前学习的都是一个消息只能被一个消费者消费,那么如果我想发一个消息 能被多个消费者消费,这时候怎么办? 这时候我们就得用到了消息中的发布订阅模型。

RabbitMQ:消息应答与消息持久化

在正式的生产环境中,我们不想丢失任何任务,如果有一个消费者挂掉了,那么我们应该将分发给它的任务交付给另一个消费者去处理。 为了确保消息不会丢失,RabbitMQ支持消息应答。消费者发送一个消息应答,告诉RabbitMQ这个消息已经接收并且处理完毕了。RabbitMQ可以删除它了。
那么如何设置RabbitMQ为手动应答模式呢?

RabbitMQ:work queues 工作队列(Round-robin:Fair dispatch)

在上篇中我们实现了程序来从一个已经命名的队列里发送和接收消息。本篇博文中我们将要创建工作队列用来把一些比较耗时的任务分配给多个worker。

工作队列的主要思想就是避开立刻处理某个资源消耗交大的任务并且需要等待它执行完成。取而代之的是我们可以将它加入计划列表,并在后边执行这些任务。我们将任务分装成一个消息,并发送到队列中。后台的工作程序在接收到消息后将会立刻执行任务。当运行多个执行器时,任务将会在他们之间共享。

RabbitMQ:RabbitMQ-理论基础

最近在学习消息中间件RabbitMq,把学习的一些笔记记录下来,希望大家可以能通过这一系列的博客,也可以尽快的掌握,网上这类的博客也特别多,因此有写的不足之处,欢迎大家指导!

1. 定义

消息队列: 在消息的传输过程中保存消息的容器。

学习过程中主要就是消费者-生产者模型,具体来说就是:A线程需要给B线程发送消息(A和B线程不一定在一台机器上),A线程先把消息发送到消息队列上,然后B线程去读取或者订阅消息服务器上消息队列的消息,线程A和线程B是没有进行直接通信的。MQ服务器在中间起到一个中间的左右。

RabbitMQ:快速入门hello word

1、相关概念

RabbitMQ是一个消息代理,事实上,它接收生产者产生的消息,然后将消息传递给消费者。在这个过程中,它可以路由,可以缓冲,或者更具你设定的规则来将消息持久化。RabbitMQ和消息传输过程中一般会用一些术语:

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×