# rabbitmq-server

**Repository Path**: kkmy/rabbitmq-server

## Basic Information

- **Project Name**: rabbitmq-server
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-04-04
- **Last Updated**: 2024-03-01

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 问题总结
Rabbitmq为什么基于channel去处理而不是连接？
可以存在没有交换机的队列吗？不存在，会有默认的交换机
如何保证生产者投递成功？
1.amqp事务机制
2.confirm模式
如何保证消费者可靠消费？
如何保证消息消费幂等性？

# 函数说明
channel.basicQos(1)
指该消费者在接收到队列里的消息但没有返回确认结果之前,队列不会将新的消息分发给该消费者。
队列中没有被消费的消息不会被删除，还是存在于队列中。

## channel.basicAck(...参数);
用于肯定确认 

# channel.basicNack(...参数);
用于否定确认（注意：这是AMQP 0-9-1的RabbitMQ扩展） 
第一个参数依然是当前消息到的数据的唯一id;
第二个参数是指是否针对多条消息；如果是true，也就是说一次性针对当前通道的消息的tagID小于当前这条消息的，都拒绝确认。
第三个参数是指是否重新入列，也就是指不确认的消息是否重新丢回到队列里面去。
同样使用不确认后重新入列这个确认模式要谨慎，因为这里也可能因为考虑不周出现消息一直被重新丢回去的情况，导致积压。


# channel.basicReject(...参数);
用于否定确认，但与basic.nack相比有一个限制:一次只能拒绝单条消息 
拒绝消费当前消息，如果第二参数传入true，就是将数据重新丢回队列里，那么下次还会消费这消息。
设置false，就是告诉服务器，我已经知道这条消息数据了，因为一些原因拒绝它，而且服务器也把这个消息丢掉就行。 
下次不想再消费这条消息了。
使用拒绝后重新入列这个确认模式要谨慎，因为一般都是出现异常的时候，catch异常再拒绝入列，选择是否重入列。
但是如果使用不当会导致一些每次都被你重入列的消息一直消费-入列-消费-入列这样循环，会导致消息积压。

# channel.basicGet

# 生产者消息确认机制
channel.confirmSelect
1.普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm。实际上是一种串行confirm了。
2.批量confirm模式：每发送一批消息后，调用waitForConfirms()方法，等待服务器端confirm。
3.异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后Client端会回调这个方法。

# rabbitmq事务

# 死信交换器和备用交换器的区别

# 流量控制（服务质量保证）