分布式中间技术——RabbitMQ

RabbitMQ在一些典型的应用场景和业务模块处理中具有重要的作用，比如业务服务模块解耦、异步处理、高并发限流、超时业务和数据延迟处理等；
基本流程：
1.生产者把消息投递到exchange交换机（3个过程：先投递到mq服务器（建立连接，设置地址；端口号）然后投递到那个虚拟主机（Virtual host）上进行定义，最后投递到交换机）
2.exchange接受到消息后,根据消息的key和已经设置好的binging,进行消息路由,将消息投递到对应的队列中，消费者监听队列获取消息消费；
AMQP核心概念：
Server又称Broker，接受客户端的连接，实现AMQP实体服务。
Connection：连接，应用程序与Broker的网络连接。
Channel：网络信道，几乎所有的操作都在Channel中进行，Channel是进行消息读写的通道。客户端可以建立多个Channel，每个Channel代表一个会话任务。
Message：消息，服务器和应用程序之间传送的数据，由Properties和Body组成。Properties可以对消息进行修饰，比如消息的优先级、延迟等高级特性；Body就是消息体内容。
Virtual Host：虚拟地址，用于进行逻辑隔离，最上层的消息路由。一个Virtual Host里面可以由若干个Exchange和Queue，同一个Virtual Host里面不能由相同名称的Exchange和Queue。
Exchange：交换机，接受消息，根据路由键转发消息到绑定的队列。
Binding：Exchange和Queue之间的虚拟连接，binding中可以包含routing key。
Routingkey：一个路由规则，虚拟机可以用它来确定如何路由一个特定消息。
Queue：也称为Message Queue，消息队列，保存消息并将他们转发给消费者。

异步处理：
一条线走到底：开始注册—校验—写入数据库—用户信息表 –发邮件给用户—发信息给用户—提示用户注册成功；假如发邮件和发信息耗时200秒，发邮件发信息出现逻辑错误，程序就终止了 ，这里可以发现 校验是核心逻辑判断是否写入数据库，而发邮件发信息并不是核心业务逻辑，启用异步处理：使用rabbitMQ 发信息和发邮件异步操作，注册到结束节省200秒响应时间，发邮件和发信息就算出现错误也不会影响注册，还实现了解耦的功能；

高并发限流：
双11的时候有几十万订单，如果每个订单都去访问数据库，数据库可能挂掉，可以把订单信息发送到MQ中，然后我们在从MQ消费这个订单信息，再去访问数据库；

应用解耦：
分布式，一个大项目分成一堆小项目，项目之间可以通过mq进行通信,比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可，中单用户感受不到物流系统的故障。提升系统的可用性。

超时业务：订单下单30分钟后，用户未付款，系统自动取消订单。。如果一直轮询查看订单设置状态非常消耗资源，可以是使用rabbit的TTL,设置失效时间；

消息应答：自动应答和手动应答
自动应答，rabbitMQ 消息发送给消费者，就会删除内存中消息信息，如果正在执行的消费者崩溃了。。就会丢失正在处理的消息；因为已经删除了；
手动应答消费者接受并处理完一个消息后，会发送应答给rabbitmq，rabbitmq收到应答后，会将该条消息从内存中删除。如果一个消费者在处理消息的过程中“崩溃”，rabbitmq没有收到应答，那么”崩溃“前正在处理的这条消息会重新被分发到别的消费者。

生产者发送消息之后，消息到底有木有到达rabbitmq服务器：
comfirm（确认）将信道设置成confirm模式，所有再该信道上发布消息都被指派一个唯一的Id，一旦消息被投递到所有匹配的队列之后，broker（rabbitmq服务器）就会返回一个确认（包含Id）给生产者，如果消息和队列是持久化的的，那么确认消息会再写入磁盘之后发出；confirm模式最大的好处是异步的，生产者可以 一直发送信息，等待确认 channel.waitForConfirms() ;
保证消息100%传递成功：
1，保障消息的成功发出；2，保障mq节点成功接收，3，发送端收到mq节点broker确认应答，4，完善消的息补偿机制；

订单业务入库，然后发送给broker，消费端监听到收到消息 确认后给broker一个confirm消息， callback服务监听confirm收到消息存入数据库DB，订单业务首次发送消息实际发送两次，1个直接给broker，1个延迟1分后发送。两次发送的队列不一样，一个是消费者的队列，第二个是callback的 队列 ，callback监听这个延迟消息，进行检查，发现db数据库已经处理过这个消息了，就不做其他事了，但是如果检查数据库db没有这个消息的确认，rpc ReSend command,给生产者一个重发的指令，指令肯定有需要重新发送消息的Id；生产者就从数据库找到对应的消息重新发送。。。

return机制：生产者发送消息找不到交换机，或者没有路由去那个队列 ； return linstener：mandatory （ 强制） ，如果为true，则监听机制会收到信息后续处理，如果为false broker端就自动删除消息；生产者发送消息设置mandatory属性，只有为true 才会去监听；

消费端的限流：假如mq服务器挤压了很多未处理的消息，这时打开消费端，巨量的消息全部瞬间推送过来，单个客户端无法处理那么多消息；QOS （服务质量保证）；一般设置为1条，生产者推送过来一条，消费者给一个应答，生产者再推送；必须设置自动应答为false；envelope包含了消息的属性；

死信队列：

声明交换机 队列 路由键用# 只要有消息进入这个队列任何路由键都会绑定到这个队列中，然后我们需要一个监听 监听这个队列；正常声明交换机的时候有个参数固定键 x-dead-letter-exchange；值就是自己声明的死信队列的交换机名字；如果没有任何消费者消费的消息会指定到这个死信交换机上；这样消息过期，requeue，或者队列在最大长度时会路由到死信队列中；

日志收集：
登录模块；用户登录表主要包含用户id，账号，密码字段
日志收集模块：日志记录表，记录用户的登录信息；
创建表，使用mybatis逆向工程；
注意
数据库连接配置 添加
<property name = “nullCatalogMeansCurrent” value = “true”/
这个默认false ，逆向生成表的时候会尝试从自带的数据库中表生成代码。如果你要生成的表恰好与自带数据库中的表重名。就可能把重名的表中的字段也都生成出来引发各种问题；

添加依赖

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-amqp</artifactId>
 </dependency>

配置文件配置RabbitMq相关：

spring.rabbitmq.virtual-host=/
spring.rabbitmq.addresses=127.0.0.1:5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=admin
#自定义
mq.login.queue.name=login.queue
mq.login.exchange.name=login.exchange
mq.login.routing.key.name=login.routing.key