一、RabbitMQ简介

    RabbitMQ是一个在AMQP基础上实现的企业级消息系统。何谓消息系统，就是消息队列系统，消息队列是“”消费-生产者模型“”的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。

    在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步操作，而这种异步处理的方式大大的节省了服务器的请求时间，从而提高了系统的吞吐量。而且不影响服务器做其他相应，不独占服务器资源。

    如：注册用户这种服务，它可能解耦成好几种独立的服务（账号验证，邮箱验证码，手机短信码等）。它们作为消费者，等待用户输入数据，在前台数据提交之后会经过分解并发送到各个服务所在的url，分发的那个角色就相当于生产者。消费者在获取数据时候有可能一次不能处理完，那么它们各自有一个请求队列，那就是内存缓冲区了。做这项工作的框架叫做消息队列。

    又比如：电商系统中的订单处理系统，传统处理模式是：下订单的时候，订单系统可能会调用库存系统的接口，这样两个系统之间存在一个严重依赖关系，如果库存系统宕机，那么整个流程都会受到影响。现在大多公司的处理方法是：引入消息队列，下完订单，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

    对库存系统来说，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。这样实现了两个系统间的解耦。

    即使在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。

二、几个概念说明：

        Broker：简单来说就是消息队列服务器实体。
        Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
        Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
        Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
        Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
        vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
        producer：消息生产者，就是投递消息的程序。
        consumer：消息消费者，就是接受消息的程序。
        channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

    消息队列的使用过程大概如下：

        （1）客户端连接到消息队列服务器，打开一个channel。

        （2）客户端声明一个exchange，并设置相关属性。

        （3）客户端声明一个queue，并设置相关属性。

        （4）客户端使用routing key，在exchange和queue之间建立好绑定关系。

        （5）客户端投递消息到exchange。

    exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。

    exchange也有几个类型：

        （1）完全根据key进行投递的叫做Direct交换机，例如，绑定时设置了routing key为”abc”，那么客户端提交的消息，只有设置了key为”abc”的才会投递到队列。

        （2）对key进行模式匹配后进行投递的叫做Topic交换机，符号”#”匹配一个或多个词，符号”*”匹配正好一个词。例如”abc.#”匹配”abc.def.ghi”，”abc.*”只匹配”abc.def”。

        （3）还有一种不需要key的，叫做Fanout交换机，它采取广播模式，一个消息进来时，投递到与该交换机绑定的所有队列。

    RabbitMQ支持消息的持久化，也就是数据写在磁盘上，为了数据安全考虑，我想大多数用户都会选择持久化。消息队列持久化包括3个部分：

        （1）exchange持久化，在声明时指定durable => 1

        （2）queue持久化，在声明时指定durable => 1

        （3）消息持久化，在投递时指定delivery_mode => 2（1是非持久化）

    如果exchange和queue都是持久化的，那么它们之间的binding也是持久化的。如果exchange和queue两者之间有一个持久化，一个非持久化，就不允许建立绑定。

三、Rabbit知识点整理：

    1. 优缺点：

        优点：

        1）解耦：一个消息想要推送给多个系统，通过一个MQ，Pub/Sub 发布订阅消息那么一个模型，就跟其他系统彻底解耦了

        2）异步：将消息写入mq队列，使用消费者消费，节省同步执行的代码执行时间

        3）削峰：如果访问高峰期，mysql的最大并发是2k，当时访问量达到了5k，可以将消息放入mq，然后每秒在mq取2k消息进行消费

        缺点：

        1）系统可用性降低：引入中间件，服务不一定高可用，影响整体服务的高可用

        2）系统复杂度提高：不能保证消息是否重复消费，消息是否会丢失，怎么保证消息传递的顺序性

        3）一致性问题：如何保证数据一致性

    2. 各类MQ服务器对比：

        1）rabbitMQ：消息实时，消息传递性可靠，支持事务，不支持批量操作，消息可存放到内存或者磁盘，吞吐量小

        2）kafka：对消息顺序不依赖，且不是那么实时的系统，无消息的确认机制，但是消息处理的效率高，吞吐量高

    3. 高可用架构：

        1）单机模式

        2）普通集群模式：在一台机器上创建多个集群，根据元数据找到queue上读取数据消费

        3）镜像集群模式：多个机器，但是每台机器上的queue数据都是一样的，不利于机器扩展，也不是真正的主从

    4. 重复消费：

        1）原因：消费者消费消息后，在给MQ发送消息确认的时候出现了网络异常（或者是服务中断），MQ没有接收到确认，此时MQ不会将发送的消息删除，为了保证消息被消费，当消费者网络稳定后，MQ就会继续给消费者投递之前的消息，这时候消费者就接收到两条一样的消息

        2）解决方案：

            1. mysql：查询数据表是否存在，存在就update或者不操作

            2. redis：set命令天然就是幂等性

    5. 数据丢失的解决方案：

        1）生产者丢失数据：开启事务（同步 不推荐）、开启confirm（异步 推荐）

        2）RabbitMQ弄丢了数据：将消息数据持久化到磁盘

        3）消费端弄丢了数据：关闭自动ack，开启ack

    6. 消息顺序：

        1）将需要顺序执行的消息打包到一个消息里面

        2）一个queue对应一个消费者

    7. 队列数据堆积太多处理：

        1）产生的影响：

            （1）磁盘满了，新消息就进不来了

            （2）如果设置了过期时间，那么消息会被丢弃

            （3）如果没有设置过期时间，会产生海量消息等待被消费，mq内存被占满，mq服务器挂掉

        2）处理方案：

            （1）增加消费者

            （2）将队列数据抛弃掉，等高峰期过了，再将数据重新跑进队列进行消费

            （3）判断队列的数据是否太大，如果超出预期就丢失消息，并报警

四、PHP源代码实现：

生产者文件：

消费者文件：