消息队列概览

为什么要消息队列

应用场景很多，典型的就是生产者和消费者。比如需要异步处理的时候，或者需要对队列进行流量控制的时候，以及服务解耦等，这些地方都可以用到消息队列。

消息队列有很多好处，比如某些场景可以对消息队列组件临时横向扩容，来抵御抵御大流量，达到削峰填谷的效果；生产消费者的队列，来实现两边速率不一致的问题；还可以是其他的：添加流计算处理；作为发布 / 订阅系统实现一个微服务级系统间的观察者模式；用于将消息广播给大量接收者。总之作用很多，应用场景也很多。

但是消息队列不是完成的，要根据实际情况来确定，根据各种消息队列的特点来选择使用。

该如何选择消息队列

以下几个指标可以作为一个参考

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

上边三点是工作中比较常关注的点，实际工作中经常遇到，不过也有一些其他的因素，只是一个参考罢了

那么常见的消息队列都有哪些呢

1. RabbitMQ
2. RocketMQ
3. Kafka

以上就是常见的消息队列了，其中redis可以说算不上消息队列，但主要是redis使用的太多了，大家都比较手熟，所以也放到了这里。他们分别出现在不同的时期，解决不同时间的问题。

首先RabbitMQ，算是一个老牌的消息队列了，出现的背景为了解决电信系统之间可靠通信。

• 他的消息队列的能力大概是每秒钟几万到几十万条数据，特点是轻量级迅捷，这也是他的slogan。
• 而且他也是使用非常多的一个消息中间件。
• 他有一个非常有特色的功能，就是在生产者和队列之间，他提供了一个Exchange模块，这个模块可以让你来决定消息该放到哪一个队列里边去，而且规则非常灵活。
• 最后这个中间件还支持很多种语言，可以说是最丰富的几个之一

他的也有缺点，而且比较头疼

• RabbitMQ 对消息堆积的支持并不好，在它的设计理念里面，消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量去避免。有时候这种堆积不是你主动造成的，比如其他人的代码抢占了你的消费者的计算资源，你往往很难预料到
• RabbitMQ 的性能是我们介绍的这几个消息队列中最差的，虽然也够日常使用了
• 他要命的编程语言，elang确实是个大坑，不是很推荐。

其次是RocketMQ

这是一个号称拥有金融机稳定性的中间件，各方面都不错，性能、稳定性和可靠性都是值得信赖的。作为一个国产产品，好处是中文文档比较全，缺点是使用的人不是多，生态跟其它的比较还是逊色了些。

最后是kafka，大名鼎鼎

Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。

但是他的批量发送的逻辑，让实时性不是太好，对于某些实时性较高的场景他不是很合适。但是除了这点外，大型互联里边就很经常用到它了。

消息队列的使用

消息队列中使用的常见痛点

1. 丢消息

   丢消息是一件严重的问题。绝大多数的丢消息，都是由于开发者不了解他的特点导致的。为了避免丢了消息还不知道，可以在消息中添加连续递增的序号，来判断消息是否有丢失，丢失的是哪个。

   但是在分布式中有以下问题，比如kafka不保证整个集群是连续的，只能保证单个实例是连续的。所以一般是保证分区数据一直性。

2. 确保消息可靠传递

   1. 生产节点

      要确保发送成功了，有异常要及时捕获

   2. 存储阶段

      合理配置，保证数据存写到磁盘中；如果是集群，请确保消息是发送到了多个broker上的

   3. 消费消息后，尽量保证消息正确消费后再告诉队列这个消息被消费了

3. 重复消息

   1. 消息队列有几种精度，At most once、At least once、Exactly once。一般中间件提供的精度也就是al least once。 kafka也一样

   2. 所以做法是在消费端做幂等操作。但是有些操作也不是天然可以做成幂等的，所以有一些常见的方法操作来设置幂等性

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

   3. 处理消息积压

      1. 生产者太快了，降低生产者这边的消费速度；
      2. 消费者太慢了，提高消费者的消费速率，一般来说合理的设计是消费者效率高于生产者的效率才行；
      3. 是否消费端存在异常；