AMQP
- AMQP(Advanced Message Queueing protocol). 高级消息队列协议，是进程之间床底一步新消息的网络协议
- AMQP工作原理如下：
- 发布者（Publisher）发布消息（Message）经过交换机（Exchange），交换机根据绑定的路由规则（RoutingKey）将收到消息分发给交换机绑的队列（Queue），最后AMQP代理会将消息投递给订阅了此队列的消费者，或者消费者按照需求自行获取（取RoutingKey对应的消息）。
RabbitMQ 中交换机
- 交换机负责接收客户端传递过来的消息，并且转发到对应的队列中，在Rabbit中有4中交换机
| 交换机 | 作用 |
|---|---|
| Direct Exchange 直接交换机 | direct交换机是Rabbit默认交换机，默认会进行公平调度，交换机中的所有消息会依次投递到每一个绑定的Queue中，采用轮询的方式，当轮训到A队列时候一定会分发到A队列对其他BCD队列没有任何影响 ，同时能绑定RoutingKey，按照RoutingKey直接精确匹配路由 |
| Fanout Exchange 扇形交换机 | 扇形交换机，实际上就是广播模式，fanout会把消息发送给所有绑定的交换机的队列。并且每个队列消息中第一个consumer能收到消息，并且忽略Routingkey |
| Topic Exchange 主题交换机 | topic交换机，允许路由键（RoutingKey）中出现匹配规则，路由键的写法和包名写法类似，com.za.xxx.xxx格式，绑定可以带上特殊字符，例如 * 代表任意单词， # 代表0个或者多个字符匹配所有 |
| Header Exchange 首部交换机 | header模式是基于一个key-value方式的绑定关系，让Exchange和Queue安指定的关系绑定在一起的一种规则，可以采用类型更加丰富 如下图示例， 设置绑定匹配规则x-match = all/any， all：代表key value 都必须匹配才能投递，any：代表key value任意匹配即可投递，因此生产者发消息时候必须携带一个header的参数，header中包括key value值，在按照如上规则去实施投递 |
RabbitMQ中vHost的作用
- vHost可以看成是一个迷你版本的服务器，里面有自己的exchange，queue，binding关系，vHost还有自己的权限系统，我们可以通过admin账号将某个vHost授权给某个账号A，这样账号A才能看到vHost内部的queue，exchange，binding关系
- 这样设计目的，利用vHost来完成不同权限的隔离，比如公司有多个域，但是公用一套RabbitMQ，这样我们可以为每一个域创建不同的账号以及vHost，这样每个域就可以用自己的账号单独使用RabbitMQ而且互相不干扰
RabbitMQ上的Queue中存放的Message是否有数量限制，限制多少
- 默认情况下一般是没有限制的，因为限制取决于机器的内存，但是消息过多会导致处理效率降低
- 在RabbitMQ中提供了参数来限制Message的数量，x-max-length：队列中消息的条数限制，x-max-length-bytes：队列中消息总量大小限制
RabbitMQ开启持久化机制，有什么要注意的点
- RabbitMQ中每个vHost都有exchange，Queue，bingding关系，当没持久化的时候，queue中数据是在内存中，因此开启持久化之后，投递的消息不仅仅写入内存还需要写入磁盘中
- 即使数据持久化了，当RabbitMQ宕机，vhost中的关键数据exchange，queue，binding关系也会丢失，因此我们必须将queue队列名称元数据，binding关系，exchange元数据信息也必须持久化
- 一旦开启持久化，性能会大受影响，不开启持久化官方给的性能指标并发度是1.2W TPS，开启持久化之后可能降低到原来的1/4 ，2k到3k的TPS，因此如果业务流量并不少特别大并且要保证消息不丢失，可以采用持久化的方法，否则不建议开启持久化，毕竟RabbitMQ宕机是小概率事件，并且我们可以通过其他方式保证高可用例如集群等。
RabbitMQ如何保证消息发送成功和消息接收成功
-
消息发送确认
- 第一种方法 confirmCallback方法：
- confirmCallback方法是一个回调接口，消息发送到Broker后触发回调，确认消息是否到达Broker服务器，也就是只确认是否正确到达Exchange中
- 第二种方法：ReturnCallback方法
- 通过实现RenturnCallback接口，启动消息失败返回，此接口是在交换器路由不到队列的时候触发回调，改方法可以不使用，因为交换机和队列是在代码里面绑定的，如果消息成功投递到Exchange后几乎不存在绑定队列收不到，除非代码写错了
-
消息确认接收：
- Rabbit消息确认机制（ACK）默认是自动ACK的，自动ACK会在消息发送给消费者后立刻确认，但是存在消息丢失的可能，因为如果消费者消费逻辑异常回滚此时也是只能保证数据一致性，之前被消费的消息并不会再次被消费。
- 消息确认模式有以下几种
- AcknowledgeMode.NONE ： 自动确认
- AcknowledgeMode.AUTO ： 更具情况确认
- AcknowledgeMode.MANUAL ： 手动确认
- 消费者收到消息后，手动调用Basic.Ack 或者 Basic.Nack 或者 Basic.Reject后，RabbitMQ收这些消息后才认为本次投递完成。
- Basic.Ack命令：用于确认当前消息已经正确消费
- Basic.Nack命令：用于否定当前消息，使用场景：当消费异常，但是非致命错误重试可能成功的情况下，我们希望RabbitMQ能够给我们重新投递这个消息，可以使用Nack反馈，可以将其中requeue设置为true，则会重新投递
- Basic.Reject命令：用于拒接当前消息，使用场景：消费数据时候遇到致命异常，重试依然会失败，那么应该直接反馈Reject命令，并且设置参数requeue为false，将丢弃这条数据或者进入死信交换机。
- Nack，Reject后都有能力要求是否重复投递消息，可以将他们投递到死信队列
RabbitMQ 死信队列，延迟队列分别是怎么实现的
-
DLX（Dead Letter Exchange） 死信交换机
-
当队列中的消息被拒绝 Basic.Reject，或者过期此时消息会变成死信，死信可以被重新投递到另外一个交换器，这个交换机就是DLX，与DLX绑定的队列就是死信队列，因此有如下三种原因：
- 信息被拒绝
- 信息超时
- 超过队列最大长度
-
过期消息定义：Rabbit可以通过参数设置消息过去时间，第一种通过队列设置，设置这个参数会使得队列中所有消息都存在相同过期时间，第二种通过对消息本身设置，那么每一条消息的过期时间都不一样，同时使用两个方法取最小的那个
-
队列设置： 队列声明的时候使用x-message-ttl，单位为秒
-
单个消息设置：设置消息属性expiration参数知，单位为秒
-
延迟队列
-
RabbitMQ支持延迟消息，投递后到exchange之后，并不会立刻给消费者，而是指定时间之后给
-
RabbitMQ没有直接支持延迟队列，而是通过死信队列实现，在死信队列中，可以为普通交换机绑定多个消息队列，假设绑定过期时间为5分钟，10分钟，30分钟，3个消息队列，然后为每一个对了设置一个DLX，为每一个DLX关联一个死信息队列，这样因为普通队列没有被消费，等指定时间后久会到DLX中，接着DLX中的绑定消费者消费这条消息，间接实现了延迟队列