消息队列大总结（精华）

为什么使用消息队列：

• 场景：解耦，异步，削峰。
  • 解耦
    • 如果某个系统与多个系统之间耦合度很大，可以加入消息队列，这个系统产生一条数据发送到消息队列中，其他系统从消息队列取出自己想要的数据，进行异步化解耦。
  • 异步
    • 将不必及时处理的操作，放到MQ中，然后直接返回结果，最后再从消息队列中慢慢处理。
  • 削峰
    • 在某个时间段，突增的请求，可能会使数据库崩溃，先把数据放到MQ，然后在从MQ中往外取，通俗的说就是粗管子接收，细管子徐徐图之。

消息队列的优缺点：

• 优点就是：解耦，异步，削峰。
• 缺点是：系统可用性降低
  • 本来有可能四个系统互相调接口还能用，后来引入MQ，系统复杂性变高，万一MQ挂了，整个系统就挂了
  • 所以必须解决消息队列的高可用性：
    • 因为你可以选择MQ有很多，可以是RabbitMQ，Kafka，ActiveMQ...
    • RabbitMQ，是基于主从（非分布式）做高可用性，RabbitMQ有三种模式
      • 单机模式
        • 单机环境，没啥意思，一般没人用
      • 普通集群模式（无高可用性）
        • 就是在多台服务器上启动多个RabbitMQ实例，每个机器启动一个，你创建的Queue只会存在一个实例上，但是每个实例同步Queue的元数据，可以从这个实例上拉取数据过来
        • 如果你绑定的是其他实例，会有拉取数据性能的消耗，如果你绑定的唯一那个实例又会出现性能瓶颈问题，但是当你存储的那个实例挂了，其他实例也无法拉到数据，你当然也可以开启消息持久化，让消息落地到每个实例上，但是又得考虑多个机器数据同步持久化的损耗。
        • 所有普通的集群模式主要目的是为了提高吞吐量，让多个机器服务这个queue节点。
      • 镜像集群模式（高可用性）
        • 在镜像集群模式下，你创建的queue包含元数据，都会存在于多个实例上，每个RabbitMQ上都有一个完整的镜像，写入数据的时候会自动同步多个queue实例上。
        • 开启这个镜像集群模式，只需要在管理控制台加入镜像集群策略模式，可以指定同步部分节点，或者全部节点。
        • 缺点：性能消耗太大，不是分布式也没用扩展性可言，因为你增加一台新的机器还是会同步所有数据，跟不加一样。
    • Kafka
      • 真正意义的分布式消息队列
      • 架构模式：由多个broker组成，每个broker是一个节点，你创建一个topic，存储着多个数据，可以划分成多个partition，每个partition存储着一部分数据。
      • 这才是真正的分布式消息队列，每个partition存储着topic的一部分数据，数据分散在多台机器上，每台机器存储着部分数据。
      • kafka,0.8以前，并没有实现高可用性HA，假设数据分布在三台机器上，有三个partition，其中有一个挂了，那么数据就丢失三分之一，没有高可用性。
      • kafka0.8以后，提供了HA机制，就是replica（复制品）副本机制，每个partitation的数据都会同步其他机器上，形成了多个副本，然后选举出一个leader，其他的replica就成了follower， 生产者和消费者都是跟这个leader打交道，写的时候，leader会把数据同步到follower上，读的时候直接从leader上，读取数据即可，如果你要把权限可以，随意读写其他follower，那么就需要关注数据一致性问题，系统复杂度更高。
      • 这样一来如果某个服务器宕机了，还有其他副本可以使用，如果挂了某个partition的leader，那么follower就会重新选举leader，继续读这个既可以了。
      • 写数据的时候，leader将写入的数据落地写到数据库，然后其他follower会从leader拉取数据，如果拉取成功返回一个ack，leader收到所有follower返回的ack，才返回写成功。
      • 消费数据的时候，直接从leader读，读取的数据也必须是已经返回所有ack的数据。
• 系统的复杂度升高
  • 新加入进来一个MQ，需要保证消费没用重复，消费没有丢失，消息传递的顺序性。
    • 保证消费没有被重复消费，也就是如何保证消息的幂等性？
      • 其实RocketMQ，ActiveMQ，RabbitMQ都会存在消费重复的问题，就kafka而言：
        • kafka上有一个offset的概念，每个消息写进去都有一个offset的概念，代表消息的序号，然后consumer消费数据之后，每隔一段时间，会上传这个offset，为了标识下一次开始消费的位置，如果出现特殊情况，你kill进程太快，无法来得及保存，就会出现下次消费的时候，会出现部分消息重复消费的情况。
        • 我们要保证幂等性，就是查看这个消费是否被消费过，一个数据一个请求，再来多少次结果还是一致的。
        • 出现的情况及解决方案
          • 数据库重复插，先根据主键查一下，如重复直接update。
          • Redis，用set，无需考虑重复
          • 加一个全局唯一id，类似于加个版本号。
    • 保证消息不丢失，也就是保证可靠性传输？
      • 数据丢失可能会发生在生产者，MQ，消费者中，都有可能发生
        • RabbitMQ
          • 生产者弄丢了数据，生产者将数据发送到MQ的路上，有可能因为网络原因，数据丢失
            • 可以选择使用RabbitMQ的事务机制，生产者发送数据之前，开启RabbitMQ的事务channel。txSelect,然后发送消息到MQ，如果MQ没有成功收到，抛出异常，回滚事务。channel。RollBack，重写来一遍，直到成功，提交事务，channel。txCommit.
            • 但是这样的事务机制，会大大降低吞吐量，太消耗性能。
            • 可以使用confirm机制，给每个消息分配一个唯一id，如果传过去了，就返回ack，没有返回nack，区别就是异步处理，而事务机制是同步的，会阻塞，所以一般采用confirm机制。
          • RabbitMQ弄丢了数据
            • 开启RabbitMQ的持久化
              • 创建queue的时候，就将其设置成持久化。但是这个不会持久化queue的数据，只会弄元数据
              • 发送消息的时候将deliveryMode设置为2，持久queue中的数据
              • 可以结合着前面的confirm机制，当持久化到磁盘的时候，在返回ack信号。
          • 消费者弄丢了数据
            • 关闭RabbitMQ的自动ack机制，手动调用ack，当我们确保全部处理完之后，在调用ack。
        • kafka
          • kafka的生产者，不会弄丢数据，因为在写入数据的时候，leader会收到所有ack之后才能确认成功。否则重试
          • kafka的MQ ，这个情况会发生，某个broker宕机了，重新选举leader的时候，数据还没同步完，就会丢失一些数据
            • 这样的情况发生我们一般设置四个参数
              • 给每个topic的replication》1。factor要求每个partication必须有两个以上副本
              • 要求leader，至少感知自己有一个follower，挂了之后还能在选举
              • 生产端，ack=all ,全部成功才算成功
              • retries=MAX ，失败无限次重试。
      • 如何保证消息的顺序性？
        • 有些消息是有顺序的，如果顺序打乱，会出现很下饭的操作。所以我们要保证消息的有序性
          • RabbitMQ可以通过一个queue，一个consumer
          • Kafka一个topic一个partition一个consumer，内部是单线程消费
          • 或者N个queue，相同的key放到同一queue，一个consumer消费一个queue。
      • 一致性问题
        • 有个系统处理完成返回成功，但是其他系统有可能返回失败，一致性失败。
• kafka，RabbitMQ，RocketMQ，ActiveMQ优缺点？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

建议使用：RabbitMQ、RocketMQ

大数据：kafka。

消费队列会出现的问题：

• 大量消息积压在MQ几个小时还没被解决？
  • 最土的方法：修复consumer问题，等他消费完
  • 或者采用临时紧急扩容
    • 先修复consumer问题，确保恢复消费速度，然后将现有的consumer都停掉
    • 新建一个topic，partition是原来的十倍，临时建立好原先十倍的queue数量
    • 然后写一个临时分发数据的consumer程序，进行消费积压消息
    • 说白了就是使用十倍的机器部署consumer使用十倍的速度去消费掉积压数据，然后恢复原先的部署。
• mq中消息过期失效了？
  • RabbitMQ中有个过期时间，也就是TTL，如果消息在积压时间过长，就会被清理掉，这就变成了大量丢失数据，只能采用批量重导
• mq都快写满了？
  • 快速消费掉所有数据，丢失的数据，在批量导入。
• 写一个消息队列的设计？
  • 考虑消息队列的伸缩性
    • 分布式系统，参考kafka，broker》topic-》partition》每个partition存放部分数据，如果资源不够了，给topic增加partition，数据迁移，增加机器，就能提高吞吐量。
    • 考虑MQ的是不是要落地到磁盘，也就是持久化数据，顺序写，避免磁盘随机读写的寻址开销。磁盘顺序读写的性能很高
    • 考虑MQ的可用性，多副本-》leader》follower》重新选举leader
    • 支持数据零丢失

JMS vs AMQP

• JMS
  • java消息服务，是一个java规范，ActiveMQ就是基于JMS实现的
  • 两种消息模型
    • 点对点模型
      • 一条消息只能被一个消费者消费，未被消费的消息在队列中保留
    • 发布、订阅模型
      • 基于广播模式，发布一条消息，所有的订阅者都收到消息。
  • JMS五种不同的消息正文
    • StreamMessage----java原始值的数据流
    • MapMessage----一套名称--值对
    • TextMessage----一个字符串对象
    • ObjectMessage---序列化后的java对象
    • ByteMessage---一个字节的数据流
  • AMQP
    • 高级消息队列协议（二进制）
    • RabbitMQ基于AMQP实现
  • JMS vs AMQP

对比方向	JMS	AMQP
定义	Java API	协议
跨语言	否	是
跨平台	否	是
支持消息类型	提供两种消息模型：①Peer-2-Peer;②Pub/sub	提供了五种消息模型：①direct exchange；②fanout exchange；③topic change；④headers exchange；⑤system exchange。本质来讲，后四种和JMS的pub/sub模型没有太大差别，仅是在路由机制上做了更详细的划分；
支持消息类型	支持多种消息类型 ，我们在上面提到过	byte[]（二进制）