消息队列学习笔记（一）

1.消息队列常用场景

    消息队列最常被使用的三种场景：异步处理、流量控制和服务解耦。
    消息队列的适用范围不仅仅局限于这些场景，还有包括：作为发布 / 订阅系统实现一个微服务级系统间的观察者模式；连接流计算任务和数据；用于将消息广播给大量接收者。
    简单的说，我们在单体应用里面需要用队列解决的问题，在分布式系统中大多都可以用消息队列来解决。同时我们也要认识到，消息队列也有它自身的一些问题和局限性，包括：引入消息队列带来的延迟问题；增加了系统的复杂度；可能产生数据不一致的问题。

2.消息队列的基本标准

• 消息的可靠传递：确保不丢消息；
• Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息；
• 性能：具备足够好的性能，能满足绝大多数场景的性能要求。

3.选择消息队列

    如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，使用RabbitMQ。
    如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。
    如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。

4.消息丢失

一条消息从生产到消费完成这个过程，可以划分三个阶段：

• 生产阶段: 在这个阶段，从消息在 Producer 创建出来，经过网络传输发送到 Broker 端。
• 存储阶段: 在这个阶段，消息在Broker端存储，如果是集群，消息会在这个阶段被复制到其他的副本上。
• 消费阶段: 在这个阶段，Consumer 从 Broker 上拉取消息，经过网络传输发送到 Consumer 上。

    在生产阶段，消息队列通过最常用的请求确认机制，来保证消息的可靠传递，正确处理返回值或者捕获异常，就可以保证这个阶段的消息不会丢失。

    存储阶段正常情况下，只要Broker在正常运行，就不会出现丢失消息的问题，但是如果 Broker出现了故障，比如进程死掉了或者服务器宕机了，还是可能会丢失消息的。如果对消息的可靠性要求非常高，可以通过配置Broker参数来避免因为宕机丢消息。

    在消费阶段，不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。

• 在生产阶段，需要捕获消息发送的错误，并重发消息。
• 在存储阶段，可以通过配置刷盘和复制相关的参数，让消息写入到多个副本的磁盘上，来确保消息不会因为某个 Broker 宕机或者磁盘损坏而丢失。
• 在消费阶段，需要在处理完全部消费业务逻辑之后，再发送消费确认。

5.消息重复

幂等性：其任意多次执行所产生的影响均与一次执行的影响相同。

    实现幂等性的方法：

1. 利用数据库的唯一约束实现幂等
2. 为更新的数据设置前置条件
3. 记录并检查操作

6.消息积压

1.避免消息积压

生产端性能优化：

    对于发送消息的业务逻辑，只需要注意设置合适的并发和批量大小，就可以达到很好的发送性能

消费端性能优化：
    一定要保证消费端的消费性能要高于生产端的发送性能，这样的系统才能健康的持续运行。

    消费端的性能优化除了优化消费业务逻辑以外，也可以通过水平扩容，增加消费端的并发数来提升总体的消费性能。特别需要注意的一点是，在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区（也叫队列）数量，确保Consumer的实例数和分区数量是相等的。

2.处理消息积压

    能导致积压突然增加，最粗粒度的原因，只有两种：要么是发送变快了，要么是消费变慢了。大部分消息队列都内置了监控的功能，只要通过监控数据，很容易确定是哪种原因。
    如果是单位时间发送的消息增多，比如说是赶上大促或者抢购，短时间内不太可能优化消费端的代码来提升消费性能，唯一的方法是通过扩容消费端的实例数来提升总体的消费能力。如果短时间内没有足够的服务器资源进行扩容，没办法的办法是，将系统降级，通过关闭一些不重要的业务，减少发送方发送的数据量，最低限度让系统还能正常运转，服务一些重要业务。
    还有一种不太常见的情况，你通过监控发现，无论是发送消息的速度还是消费消息的速度和原来都没什么变化，这时候你需要检查一下你的消费端，是不是消费失败导致的一条消息反复消费这种情况比较多，这种情况也会拖慢整个系统的消费速度。
    如果监控到消费变慢了，你需要检查你的消费实例，分析一下是什么原因导致消费变慢。优先检查一下日志是否有大量的消费错误，如果没有错误的话，可以通过打印堆栈信息，看一下你的消费线程是不是卡在什么地方不动了，比如触发了死锁或者卡在等待某些资源上了。

7.消息的序列化

    要想使用网络框架的API来传输结构化的数据，必须得先实现结构化的数据与字节流之间的双向转换。这种将结构化数据转换成字节流的过程，我们称为序列化，反过来转换，就是反序列化。
    在选择序列化实现时，需要权衡这样几个因素：

• 序列化后的数据最好是易于人类阅读的；
• 实现的复杂度是否足够低；
• 序列化和反序列化的速度越快越好；序列化后的信息密度越大越好，也就是说，同样的一个结构化数据，序列化之后占用的存储空间越小越好；

8.Kafka的高性能IO

1.使用批量消息提升服务端处理能力
    构建批消息和解开批消息分别在发送端和消费端的客户端完成，不仅减轻了Broker的压力，最重要的是减少了 Broker处理请求的次数，提升了总体的处理能力。
2.使用顺序读写提升磁盘 IO 性能
    顺序读写相比随机读写省去了大部分的寻址时间，它只要寻址一次，就可以连续地读写下去，所以说，性能要比随机读写要好很多。Kafka就是充分利用了磁盘的这个特性。它的存储设计非常简单，对于每个分区，它把从Producer收到的消息，顺序地写入对应的 log 文件中，一个文件写满了，就开启一个新的文件这样顺序写下去。消费的时候，也是从某个全局的位置开始，也就是某一个 log 文件中的某个位置开始，顺序地把消息读出来。
3.利用 PageCache 加速消息读写
    Kafka在读写消息文件的时候，充分利用了PageCache的特性。一般来说，消息刚刚写入到服务端就会被消费，按照LRU的“优先清除最近最少使用的页”这种策略，读取的时候，对于这种刚刚写入的PageCache，命中的几率会非常高。也就是说，大部分情况下，消费读消息都会命中 PageCache，带来的好处有两个：一个是读取的速度会非常快，另外一个是，给写入消息让出磁盘的 IO 资源，间接也提升了写入的性能。
4.使用零拷贝技术加速消费流程。

9.数据压缩

• 不压缩直接传输需要的时间是： 传输未压缩数据的耗时。
• 使用数据压缩需要的时间是： 压缩耗时 + 传输压缩数据耗时 + 解压耗时。

10.RocketMQ Producer

DefaultMQProducer的启动过程

• 通过一个单例模式（Singleton Pattern）的 MQClientManager 获取 MQClientInstance 的实例 mQClientFactory，没有则自动创建新的实例；
• 在 mQClientFactory 中注册自己；
• 启动 mQClientFactory；
• 给所有 Broker 发送心跳。

    //获取 MQClientInstance 的实例 mQClientFactory，没有则自动创建新的实例
    this.mQClientFactory = MQClientManager.getInstance().getOrCreateMQClientInstance(this.defaultMQProducer, rpcHook);
    //在 mQClientFactory 中注册自己
    boolean registerOK = mQClientFactory.registerProducer(this.defaultMQProducer.getProducerGroup(), this);
    if (!registerOK) {
        this.serviceState = ServiceState.CREATE_JUST;
        throw new MQClientException("The producer group[" + this.defaultMQProducer.getProducerGroup()
            + "] has been created before, specify another name please." + FAQUrl.suggestTodo(FAQUrl.GROUP_NAME_DUPLICATE_URL),
            null);
    }

    this.topicPublishInfoTable.put(this.defaultMQProducer.getCreateTopicKey(), new TopicPublishInfo());

    if (startFactory) {
        mQClientFactory.start();
    }

    ...
    
    给所有 Broker 发送心跳
    this.mQClientFactory.sendHeartbeatToAllBrokerWithLock();

11.Kafka Consumer

Kafka 消费模型的几个要点：

• Kafka 的每个 Consumer（消费者）实例属于一个ConsumerGroup（消费组）；
• 在消费时，ConsumerGroup中的每个Consumer独占一个或多个Partition（分区）；
• 对于每个 ConsumerGroup，在任意时刻，每个 Partition 至多有 1 个 Consumer 在消费；
• 每个 ConsumerGroup 都有一个 Coordinator(协调者）负责分配 Consumer 和 Partition 的对应关系，当 Partition或是Consumer发生变更时，会触发rebalance（重新分配）过程，重新分配 Consumer 与 Partition 的对应关系；
• Consumer 维护与 Coordinator 之间的心跳，这样 Coordinator 就能感知到 Consumer 的状态，在 Consumer 故障的时候及时触发 rebalance。