1、什么是rabbitmq
一种采用AMQP高级消息队列协议的消息队列技术，最大的特点是消费无需确保提供商的存在，实现了服务间的高级解耦
2、为什么要使用rabbitmq
1 )在分布式系统下具备异步、调峰、负载均衡等一系列高级功能；
2 )还可以保存持久化机制、进程消息和队列中的信息。
3 )实现消费者与生产者之间的解除耦合。
4 )在并发方案中，通过使用消息队列，可以将同步访问限制为一定量的串行访问流，使数据库的操作变得容易。
您可以使用消息队列获得异步订单的效果，并在队列中的后台进行逻辑订单
3、使用rabbitmq的场景
1 )服务间异步通信
2 )序贯消费
3 )定时任务
4 )请剪高峰
4、如何确保消息正确发送到RabbitMQ？ 如何确保消息收件人已消耗了消息？
发送侧确认模式
当通道设置为confirm模式(发送方确认模式)时，将为在通道上发布的所有消息指定唯一的ID。
在消息传递到目标队列或消息写入磁盘(可持久化消息)之后，通道向生产者发送包含消息特定ID的确认。
如果RabbitMQ发生内部错误且消息丢失，则会发送未确认(nack )消息。
发送方的确认模式是异步的，生产者APP应用可以在等待确认的同时继续发送消息。 当确认消息到达生产者APP应用产品时，将触发生产者APP应用产品的回调方法来处理确认消息。
接收方确认机制
接收方消息确认机制
消费者在接收到每条消息后必须进行确认(消息接收和消息确认是两种不同的操作)。 只有消费者确认消息，RabbitMQ才能安全地从队列中删除消息。
此处没有使用超时机制，RabbitMQ将检查是否只需要Consumer断开连接就需要重新发送消息。 也就是说，只要连接没有中断，RabbitMQ就给了Consumer足够的时间来处理消息。 保证数据的最终一致性
下面罗列一些特殊情况
如果消费者在接收和确认消息之前断开连接或取消订阅，RabbitMQ将认为没有发布消息，并将其重新发布给下一个订阅者。 (有信息重复消费的危险，需要加重) ) )。
如果消费者收到消息时没有确认消息，连接也没有断开，则RabbitMQ认为该消费者很忙，不会向该消费者分发更多的消息。
5、如何避免消息的重复发送和重复消费？
消息生产时，MQ内部为生产者发送的每条消息生成inner-msg-id，避免重复消息进入队列；
在消费信息时，为了不使信息主体重复消费bizId (支付ID、订单ID、投稿ID等在同一业务的全球唯一的东西)，需要作为再利用的依据。
6、消息基于什么传输？
由于创建和销毁TCP连接的开销很大，并发行数受到系统资源的限制，因此会出现性能瓶颈。 RabbitMQ使用通道来传输数据。 通道是在实际TCP连接中建立的虚拟连接，每个TCP连接的通道数量没有限制。
7、短信怎么发布？
如果此队列中至少有一个消费者订阅，则消息将以循环方式发送给消费者。 每封邮件仅分发给订阅的消费者，前提是他们可以成功处理和确认邮件。 通过路由实现多消费功能
8、消息如何路由？
消息提供器-路由-向交换机发出一个或多个队列消息时，消息将具有路由密钥，并在创建消息时进行设置。 队列路由密钥允许将队列绑定到交换机。
当消息到达交换机时，RabbitMQ会将消息的路由密钥与队列的路由密钥匹配(每个交换机有不同的路由规则)。
常用开关主要分为以下三类
fanout交换机接收到消息时，它将广播到所有绑定的队列
direct :当路由密钥完全匹配时，消息将传递到相应的队列
主题：允许来自不同源的消息到达同一队列。 使用topic开关时，可以使用通配符
9、如何防止信息丢失？
消息持久化。 当然，需要队列持久化的RabbitMQ会将持久消息写入磁盘上的持久化日志文件，并在向持久交换机发出持久消息时，Rabbit会在将消息提交到日志文件后发送响应
当消费者从持久队列中消耗持久化消息时，RabbitMQ会将该消息标记为等待垃圾回收。 如果在消耗持久化消息之前重新启动RabbitMQ，Rabbit将自动重建交换机和队列(以及绑定)，并将持久化日志文件中的消息重新发布到相应的队列。
10、使用RabbitMQ有什么好处？
1 )服务之间的高级解耦
2 )异步通信性能高
3 )流量切峰
11、rabbitmq的集群
镜像集群模式
你创建的queue，即使是元数据也是queue中的
消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
12、mq的缺点
系统可用性降低
系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。
系统复杂性提高
硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
13、一致性问题
A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的
14、分布式事务
分段提交。会有一个仲裁者，然后给所有节点来发消息。当所有节点都ack之后，才会成功。否则就得等待重发。
15、针对直播这种突然大流量的情况，该怎么设计。
1)NGINX加机器
2)cdn缓存静态页面
3)redis队列，让用户慢点进来。
4)加缓存。缓存用户数据，比如用户信息。
5)数据库使用主从
6)弹性扩容
7)限流熔断
点关注，不迷路
好了各位，以上就是这篇文章的全部内容了，能看到这里的人呀，都是人才。之前说过，PHP方面的技术点很多，也是因为太多了，实在是写不过来，写过来了大家也不会看的太多，所以我这里把它整理成了PDF和文档，如果有需要的可以
ziliao4.png
ziliao5.png
以上内容希望帮助到大家，很多PHPer在进阶的时候总会遇到一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家，需要的可以加入我的