共计 1761 个字符，预计需要花费 5 分钟才能阅读完成。
为什么要音讯队列
利用场景很多，典型的就是生产者和消费者。比方须要异步解决的时候，或者须要对队列进行流量管制的时候，以及服务解耦等，这些中央都能够用到音讯队列。
音讯队列有很多益处，比方某些场景能够对音讯队列组件长期横向扩容，来抵挡抵挡大流量，达到削峰填谷的成果；生产消费者的队列，来实现两边速率不统一的问题；还能够是其余的：增加流计算解决；作为公布 / 订阅零碎实现一个微服务级零碎间的观察者模式；用于将音讯播送给大量接收者。总之作用很多，利用场景也很多。
然而音讯队列不是实现的，要依据理论状况来确定，依据各种音讯队列的特点来抉择应用。
该如何抉择音讯队列
以下几个指标能够作为一个参考
- 音讯的牢靠传递：确保不丢音讯
- Cluster：反对集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢音讯；
- 性能：具备足够好的性能，能满足绝大多数场景的性能要求。
上边三点是工作中比拟常关注的点，理论工作中常常遇到，不过也有一些其余的因素，只是一个参考罢了
那么常见的音讯队列都有哪些呢
- RabbitMQ
- RocketMQ
- Kafka
以上就是常见的音讯队列了，其中 redis 能够说算不上音讯队列，但次要是 redis 应用的太多了，大家都比拟手熟，所以也放到了这里。他们别离呈现在不同的期间，解决不同工夫的问题。
首先 RabbitMQ，算是一个老牌的音讯队列了，呈现的背景为了解决电信零碎之间牢靠通信。
- 他的音讯队列的能力大略是每秒钟几万到几十万条数据，特点是轻量级迅捷，这也是他的 slogan。
- 而且他也是应用十分多的一个消息中间件。
- 他有一个十分有特色的性能，就是在生产者和队列之间，他提供了一个 Exchange 模块，这个模块能够让你来决定音讯该放到哪一个队列里边去，而且规定非常灵活。
- 最初这个中间件还反对很多种语言，能够说是最丰盛的几个之一
他的也有毛病，而且比拟头疼
- RabbitMQ 对音讯沉积的反对并不好，在它的设计理念外面，音讯队列是一个管道，大量的音讯积压是一种不失常的状况，该当尽量去防止。有时候这种沉积不是你被动造成的，比方其他人的代码抢占了你的消费者的计算资源，你往往很难预料到
- RabbitMQ 的性能是咱们介绍的这几个音讯队列中最差的，尽管也够日常应用了
- 他要命的编程语言，elang 的确是个大坑，不是很举荐。
其次是 RocketMQ
这是一个号称领有金融机稳定性的中间件，各方面都不错，性能、稳定性和可靠性都是值得信赖的。作为一个国产产品，益处是中文文档比拟全，毛病是应用的人不是多，生态跟其它的比拟还是逊色了些。
最初是 kafka，赫赫有名
Kafka 应用 Scala 和 Java 语言开发，设计上大量应用了批量和异步的思维，这种设计使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差别，大概每秒钟能够解决几十万条音讯。
然而他的批量发送的逻辑，让实时性不是太好，对于某些实时性较高的场景他不是很适合。然而除了这点外，大型互联里边就很常常用到它了。
音讯队列的应用
音讯队列中应用的常见痛点
- 丢音讯
丢音讯是一件重大的问题。绝大多数的丢音讯，都是因为开发者不理解他的特点导致的。为了防止丢了音讯还不晓得，能够在音讯中增加间断递增的序号，来判断音讯是否有失落，失落的是哪个。
然而在分布式中有以下问题，比方 kafka 不保障整个集群是间断的，只能保障单个实例是间断的。所以个别是保障分区数据始终性。
确保音讯牢靠传递
- 生产节点
要确保发送胜利了，有异样要及时捕捉
- 存储阶段
合理配置，保证数据存写到磁盘中；如果是集群，请确保音讯是发送到了多个 broker 上的
- 生产音讯后，尽量保障音讯正确生产后再通知队列这个音讯被生产了
- 生产节点
反复音讯
- 音讯队列有几种精度，At most once、At least once、Exactly once。个别中间件提供的精度也就是 al least once。kafka 也一样
所以做法是在生产端做幂等操作。然而有些操作也不是人造能够做成幂等的，所以有一些常见的办法操作来设置幂等性
- 利用数据库的惟一束缚实现幂等
- 为更新的数据设置前置条件
- 记录并查看操作
解决音讯积压
- 生产者太快了，升高生产者这边的生产速度；
- 消费者太慢了，进步消费者的生产速率，一般来说正当的设计是消费者效率高于生产者的效率才行；
- 是否生产端存在异样；
