mq

 

    消息丢失
        1.1消息应答
    为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制
    消息应答就是：消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了

       1.2 自动应答 (默认是自动应答)
    消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡
    当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽，最终这些消费者线程被操作系统杀死，所以这种模式仅适用在消费者可以高效并以 某种速率能够处理这些消息的情况下使用

    消息自动重新入队
    如果没被消费到，则重新排队，如果此时还有其他消费者可以处理，则会重新分发给另一个消费者

    我们要想实现消息消费过程中不丢失，需要把自动应答改为手动应答，


    RabbitMQ 持久化
    确保消息不会丢失需要做两件事：我们需要将队列和消息都标记为持久化

    1、队列如何实现持久化
        我们创建的队列都是非持久化的,rabbitmq如果重启的化,该队列会被删除掉,如果要队列实现持久化,需要在声明队列的时候把durable 参数设置为持久化
//    但是需要注意的就是如果之前声明的队列不是持久化的，需要把原先队列先删除，或者重新创建一个持久化的队列，不然就会出现错误

    2、消息实现持久化
        想让消息实现持久化需要在消息生产者修改代码,MessageProperties.PERSISTENT_TEXT_PLAIN 添加这个属性,但是
    将消息标记为持久化并不能完全保证不会丢失消息,但是这里依然存在当消息刚准备存储在磁盘的时候 但是还没有存储完，消息还在缓存的一个间隔点。此时并没
    有真正写入磁盘。持久性保证并不强，但是对于我们的简单任务队列而言，这已经绰绰有余了

    3、不公平分发
        rabbitmq分发消息采用的轮训分发,但是对于 一个线程处理的很快,一个线程处理的很慢,这种策略不是很好
        为了避免这种情况，我们可以设置参数 channel.basicQos(1);

//    意思就是如果这个任务我还没有处理完或者我还没有应答你，你先别分配给我，我目前只能处理一个
//    任务，然后 rabbitmq 就会把该任务分配给没有那么忙的那个空闲消费者，当然如果所有的消费者都没有完
//    成手上任务，队列还在不停的添加新任务，队列有可能就会遇到队列被撑满的情况，这个时候就只能添加
//    新的 worker 或者改变其他存储任务的策略。

    4、预取值
        本身消息的发送就是异步发送的，所以在任何时候，channel 上肯定不止只有一个消息另外来自消费
        者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区，因此希望开发人员能限制此
        缓冲区的大小，以避免缓冲区里面无限制的未确认消息问题,的负载该值取值也不同 100 到 300 范围内的值通常可提供最佳的吞吐量


    发布确认:
        生产者将信道设置成 confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始)，一旦消息被投递到所有匹配的队列之后，broker 就会
    发送一个确认给生产者(包含消息的唯一 ID)，这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出，broker 回传给生产
    者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置basic.ack 的multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。

    confirm 模式最大的好处在于他是异步的一旦发布一条消息，生产者应用程序就可以在等信道
    返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方
        法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息，
        生产者应用程序同样可以在回调方法中处理该 nack 消息


    开启发布确认方法
        发布确认默认是没有开启的，如果要开启需要调用方法 confirmSelect，每当你要想使用发布
        确认，都需要在 channel 上调用该方法

        1 单个确认发布         它是一种同步确认发布的方式，也就是发布一个消息之后只有它被确认发布，后续的消息才能继续发布,会阻塞
        2 批量确认发布        当发生故障导致发布出现问题时，不知道是哪个消息出现
                            问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。当然这种
                            方案仍然是同步的，也一样阻塞消息的发布
        3 异步确认发布        他是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功

        4 如何处理异步未确认消息   最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传
    递


    5. 交换机 Exchanges（接受来自生产者的消息，另一方面推入队列）（direct，topic，headers，fanout）
            RabbitMQ 消息传递的核心思想：生产者生产的消息从不会直接发送到队列。实际上，通常生产者深圳都不知道这些消息传递到了那些队列中。
                    生产者只能将消息发送到交换机（exchange）。
        1.1、无名exhange
            但仍然能够将消息发送到队列。之前能实现的原因是因为我们使用的是默认交换，我们通过空字符串(“”)进行标识。
            第一个参数是交换机的名称。空字符串表示默认或无名称交换机：消息能路由发送到队列中其实是由 routingKey(bindingkey)绑定 key 指定的，如果它存在的话
            1.2、临时队列
                每当我们连接到 Rabbit 时，我们都需要一个全新的空队列，为此我们可以创建一个具有随机名称
                的队列，或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连
                接，队列将被自动删除  创建临时队列：String queueName = channel.queueDeclare().getQueue()

            1.3、绑定 exchange和queue之间的桥梁

        2、Fanout（它是将接收到的所有消息广播到它知道的所有队列中）

        3、Direct 这种类型的工作方式是，消息只去到它绑定的routingKey 队列中去。）

        4、Topic（更灵活比Direct） 尽管使用direct 交换机改进了我们的系统，但是它仍然存在局限性-比方说我们想接收的日志类型有
                info.base 和 info.advantage，某个队列只想 info.base 的消息，那这个时候direct 就办不到了。这个时候
                就只能使用 topic 类

                *(星号)可以代替一个单词
                #(井号)可以替代零个或多个单词

    6、死信队列（就是无法被消费的消息，就变成了死信，有死信自然就有了死信队列）
        应用场景:为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制，当消息
        消费发生异常时，将消息投入死信队列中.还有比如说: 用户在商城下单成功并点击去支付后在指定时间未支付时自动失效

        6.1、消息 TTL 过期
            队列达到最大长度(队列满了，无法再添加数据到 mq 中)

        6.2 消息被拒

    7、延迟队列
        延时队列,队列内部是有序的，最重要的特性就体现在它的延时属性上，延时队列中的元素是希望
        在指定时间到了以后或之前取出和处理，简单来说，延时队列就是用来存放需要在指定时间被处理的元素的队列

        延迟队列使用场景

        消息设置TTL： 消息即使过期，也不一定会被马上丢弃，因为消息是否过期是在即将投递到消费者
                    之前判定的，如果当前队列有严重的消息积压情况，则已过期的消息也许还能存活较长时间；另外，还需
                    要注意的一点是，如果不设置 TTL，表示消息永远不会过期，如果将 TTL 设置为 0，则表示除非此时可以
                    直接投递该消息到消费者，否则该消息将会被丢弃
        队列设置TTL：了队列的 TTL 属性，那么一旦消息过期，就会被队列丢弃(如果配置了死信队列被丢到死信队列中)

    8、发布确认高级



    RabbitMQ实现消费端异常处理
        开启消费者重试”模式：若异常发生，重试n次（n为yml中的 max-attempts），之后消息就自动进入死信队列（或者如果没配置死信队列，消息被扔掉）

    mq消息堆积处理
        1、开启新的消费者队列去消费
        2、消息设置过期时间，过期就丢掉


    数据丢失
            1、生产者丢失数据
                程序发送失败抛异常了没有重试处理
                发送的过程成功但是过程中网络闪断MQ没收到
                一般是异步进行发送消息
                解决：异步发送+回调通知+本地消息表
            2、MQ丢失数据
            3、消费者丢失数据
            4、那如果消息积压达到磁盘上限，消息被删除了怎么办？
                最初，我们发送的消息记录是落库保存了的，而转发发送的数据也保存了，那么我们就可以通过这部分数据来找到丢失的那部分数据，再单独跑个脚本重发就可以了。
                如果转发的程序没有落库，那就和消费方的记录去做对比，只是过程会更艰难一点。