优秀的程序员，你的技术栈中不能只有“增删改查”
底层技术知识，给你深入解决业务问题的能力
你可能会问，我是普通程序员， 工作中只会使用消息队列等“轮子”来实现业务，并没有机会参与到“轮子”的开发，那么学习这些底层的技术知识对我有用吗？当然有用。
消息队列几乎是每个后端程序员都会用到的中间件，它在你的技术栈中重要程度不言而喻。消息队列的功能很简单，就是收发消息，你肯定可以看一下文档，几分钟就写出一个用消息队列收发消息的 Demo。但是，把消息队列真正应用到生产系统中，就没那么简单了。在使用消息队列的过程中，你会遇到很多问题，比如选择哪款消息队列更适合你的业务系统？如何保证系统的高可靠、高可用和高性能？如何保证消息不重复、不丢失？如何做到水平扩展？诸如此类的问题，每一个问题想要解决好，都不太容易。
比如说面对消息丢失这个问题，你会怎么解决呢？如果你对消息队列不熟悉，常规的做法可能是去搜索引擎上查看一下错误信息，然后照着别人的解决方案尝试下，能不能解决取决于运气。如果你有一些消息队列使用经验，对于常见的问题，可以根据经验来判断问题所在，而对于一些没见过的问题，那就无能为力了。但如果你掌握了消息队列的实现原理，无论你使用任何一种消息队列，遇到任何问题，都可以从原理层面来分析它的原因，再简单看一下它的 API 和相关配置项，就能很快知道该如何配置消息队列，写出高性能并且可靠的程序。
当然，从职业发展，保持市场竞争力的角度来看，掌握一些底层技术，深耕个人技术栈的深度，实现从“用轮子”到“造轮子”的技术提升，也是一个非常明智的选择。为什么这么说呢？可以看到，技术圈的风向一直在变，大数据、云的热度已经在慢慢消退，现在当红的是 AI 和 IoT。这些火热的概念，它最终要从论文和 PPT 落地，变成真正能解决问题的系统，否则就是一个空中楼阁。那不变的是什么？无论 AI 还是 IoT，都是一个分布式系统，都要处理海量的数据，都要应对海量并发，它们需要解决的底层问题是一样的。
所以，不管技术圈的风向如何变化，那些掌握这些底层技术的程序员，永远都是最受欢迎的人。消息队列也确实是非常适合拿来展开做源码分析的技术。不难发现，消息队列作为使用最广泛、生命力最旺盛的中间件，无论技术如何发展，都离不开分布式系统的最基本需求：通信。它涉及的底层技术是非常全面的，比如：高性能通信、海量数据存储、高并发等。并且，消息队列具有功能简洁、结构清晰的特点，入门简单但具有足够的深度，适合用来进行深入地分析和学习。从“上古”的 ActiveMQ，如今被广泛使用的 RocketMQ、Kafka，直到最近推出的 Pulsar，伴随着技术的持续发展，一代又一代的消息队列不断推陈出新，性能越来越强大，功能也日臻丰富完善。
希望大家不仅仅是学会并精通消息队列的使用和原理，将你的技术深度和代码能力再提升一个层次
成为消息队列领域的“技术高手”；
掌握从源码分析、解决问题的方法；
将你的综合技术能力提升到一个新的高度，具备成为开源软件项目开发者的能力。
如果愿意的话，考虑参与某个开源软件项目，成为它的贡献者。
为什么需要消息队列
消息队列是最古老的中间件之一，从系统之间有通信需求开始，就自然产生了消息队列。但是给消息队列下一个准确的定义却不太容易。我们知道，消息队列的主要功能就是收发消息，但是它的作用不仅仅只是解决应用之间的通信问题这么简单。
我们举个例子说明一下消息队列的作用。话说小袁是一家巧克力作坊的老板，生产出美味的巧克力需要三道工序：首先将可可豆磨成可可粉，然后将可可粉加热并加入糖变成巧克力浆，最后将巧克力浆灌入模具，撒上坚果碎，冷却后就是成品巧克力了。
最开始的时候，每次研磨出一桶可可粉后，工人就会把这桶可可粉送到加工巧克力浆的工人手上，然后再回来加工下一桶可可粉。小袁很快就发现，其实工人可以不用自己运送半成品，于是他在每道工序之间都增加了一组传送带，研磨工人只要把研磨好的可可粉放到传送带上，就可以去加工下一桶可可粉了。 传送带解决了上下游工序之间的“通信”问题。
传送带上线后确实提高了生产效率，但也带来了新的问题：每道工序的生产速度并不相同。在巧克力浆车间，一桶可可粉传送过来时，工人可能正在加工上一批可可粉，没有时间接收。不同工序的工人们必须协调好什么时间往传送带上放置半成品，如果出现上下游工序加工速度不一致的情况，上下游工人之间必须互相等待，确保不会出现传送带上的半成品无人接收的情况。
为了解决这个问题，小袁在每组传送的下游带配备了一个暂存半成品的仓库，这样上游工人就不用等待下游工人有空，任何时间都可以把加工完成的半成品丢到传送带上，无法接收的货物被暂存在仓库中，下游工人可以随时来取。传送带配备的仓库实际上起到了“通信”过程中“缓存”的作用。
样例
传送带解决了半成品运输问题，仓库可以暂存一些半成品，解决了上下游生产速度不一致的问题，小袁在不知不觉中实现了一个巧克力工厂版的消息队列。
消息队列最常被使用的三种场景：异步处理、流量控制和服务解耦。当然，消息队列的适用范围不仅仅局限于这些场景，还有包括：
作为发布 / 订阅系统实现一个微服务级系统间的观察者模式；
连接流计算任务和数据；
用于将消息广播给大量接收者。
简单的说，我们在单体应用里面需要用队列解决的问题，在分布式系统中大多都可以用消息队列来解决。
同时我们也要认识到，消息队列也有它自身的一些问题和局限性，包括：
引入消息队列带来的延迟问题；增加了系统的复杂度；
可能产生数据不一致的问题。根据目标业务的特点和自身条件选择合适的架构，才是体现一个架构师功力的地方。
该如何选择消息队列？
作为一个程序员，相信你一定听过“没有银弹”这个说法，这里面的银弹是指能轻松杀死狼人、用白银做的子弹，什么意思呢？我对这句话的理解是说，在软件工程中，不存在像“银弹”这样可以解决一切问题的设计、架构或软件，每一个软件系统，它都是独一无二的，你不可能用一套方法去解决所有的问题。
在消息队列的技术选型这个问题上，也是同样的道理。并不存在说，哪个消息队列就是“最好的”。常用的这几个消息队列，每一个产品都有自己的优势和劣势，你需要根据现有系统的情况，选择最适合你的那款产品。
选择消息队列产品的基本标准
虽然这些消息队列产品在功能和特性方面各有优劣，但我们在选择的时候要有一个最低标准，保证入选的产品至少是及格的。
接下来我们先说一下这及格的标准是什么样的。
首先，必须是开源的产品，这个非常重要。开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug，你至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统火烧眉毛的问题，而不是束手无策地等待开发者不一定什么时候发布的下一个版本来解决。其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品。流行的好处是，只要你的使用场景不太冷门，你遇到 Bug 的概率会非常低，因为大部分你可能遇到的 Bug，其他人早就遇到并且修复了。你在使用过程中遇到的一些问题，也比较容易在网上搜索到类似的问题，然后很快的找到解决方案。
还有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容，比如，Kafka 和 Flink 就有比较好的兼容性，Flink 内置了 Kafka 的 Data Source，使用 Kafka 就很容易作为 Flink 的数据源开发流计算应用，如果你用一个比较小众的消息队列产品，在进行流计算的时候，你就不得不自己开发一个 Flink 的 Data Source。
最后，作为一款及格的消息队列产品，必须具备的几个特性包括：消息的可靠传递：确保不丢消息；Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息；性能：具备足够好的性能，能满足绝大多数场景的性能要求。
接下来我们一起看一下有哪些符合上面这些条件，可供选择的开源消息队列产品。
1. RabbitMQ
首先，我们说一下老牌儿消息队列 RabbitMQ，俗称兔子 MQ。RabbitMQ 是使用一种比较小众的编程语言：Erlang 语言编写的，它最早是为电信行业系统之间的可靠通信设计的，也是少数几个支持 AMQP 协议的消息队列之一。
RabbitMQ 就像它的名字中的兔子一样：轻量级、迅捷，它的 Slogan，也就是宣传口号，也很明确地表明了 RabbitMQ 的特点：Messaging that just works，“开箱即用的消息队列”。也就是说，RabbitMQ 是一个相当轻量级的消息队列，非常容易部署和使用。
另外 RabbitMQ 还号称是世界上使用最广泛的开源消息队列，是不是真的使用率世界第一，我们没有办法统计，但至少是“最流行的消息中间之一”，这是没有问题的。
RabbitMQ 一个比较有特色的功能是支持非常灵活的路由配置，和其他消息队列不同的是，它在生产者（Producer）和队列（Queue）之间增加了一个 Exchange 模块，你可以理解为交换机。
这个 Exchange 模块的作用和交换机也非常相似，根据配置的路由规则将生产者发出的消息分发到不同的队列中。路由的规则也非常灵活，甚至你可以自己来实现路由规则。基于这个 Exchange，可以产生很多的玩儿法，如果你正好需要这个功能，RabbitMQ 是个不错的选择。
RabbitMQ 的客户端支持的编程语言大概是所有消息队列中最多的，如果你的系统是用某种冷门语言开发的，那你多半可以找到对应的 RabbitMQ 客户端。
接下来说下 RabbitMQ 的几个问题。
第一个问题是，RabbitMQ 对消息堆积的支持并不好，在它的设计理念里面，消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量去避免。当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。
第二个问题是，RabbitMQ 的性能是我们介绍的这几个消息队列中最差的，根据官方给出的测试数据综合我们日常使用的经验，依据硬件配置的不同，它大概每秒钟可以处理几万到十几万条消息。其实，这个性能也足够支撑绝大多数的应用场景了，不过，如果你的应用对消息队列的性能要求非常高，那不要选择 RabbitMQ。
最后一个问题是 RabbitMQ 使用的编程语言 Erlang，这个编程语言不仅是非常小众的语言，更麻烦的是，这个语言的学习曲线非常陡峭。大多数流行的编程语言，比如 Java、C/C++、Python 和 JavaScript，虽然语法、特性有很多的不同，但它们基本的体系结构都是一样的，你只精通一种语言，也很容易学习其他的语言，短时间内即使做不到精通，但至少能达到“会用”的水平。
就像一个以英语为母语的人，学习法语、德语都很容易，但是你要是让他去学汉语，那基本上和学习其他这些语言不是一个难度级别的。很不幸的是，Erlang 就是编程语言中的“汉语”。所以如果你想基于 RabbitMQ 做一些扩展和二次开发什么的，建议你慎重考虑一下可持续维护的问题。
2. RocketMQ
RocketMQ 是阿里巴巴在 2012 年开源的消息队列产品，后来捐赠给 Apache 软件基金会，2017 正式毕业，成为 Apache 的顶级项目。阿里内部也是使用 RocketMQ 作为支撑其业务的消息队列，经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的。作为优秀的国产消息队列，近年来越来越多的被国内众多大厂使用。
总结 RocketMQ 的特点时，发现很难找出 RocketMQ 有什么特别深刻的特点，也很难找到它有什么缺点。
RocketMQ 就像一个品学兼优的好学生，有着不错的性能，稳定性和可靠性，具备一个现代的消息队列应该有的几乎全部功能和特性，并且它还在持续的成长中。
RocketMQ 有非常活跃的中文社区，大多数问题你都可以找到中文的答案，也许会成为你选择它的一个原因。另外，RocketMQ 使用 Java 语言开发，它的贡献者大多数都是中国人，源代码相对也比较容易读懂，你很容易对 RocketMQ 进行扩展或者二次开发。
RocketMQ 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，如果你的应用场景很在意响应时延，那应该选择使用 RocketMQ。RocketMQ 的性能比 RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息。RocketMQ 的一个劣势是，作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹。
3. Kafka
最后我们聊一聊 Kafka。Kafka 最早是由 LinkedIn 开发，目前也是 Apache 的顶级项目。Kafka 最初的设计目的是用于处理海量的日志。
在早期的版本中，为了获得极致的性能，在设计方面做了很多的牺牲，比如不保证消息的可靠性，可能会丢失消息，也不支持集群，功能上也比较简陋，这些牺牲对于处理海量日志这个特定的场景都是可以接受的。这个时期的 Kafka 甚至不能称之为一个合格的消息队列。
但是，请注意，重点一般都在后面。随后的几年 Kafka 逐步补齐了这些短板，你在网上搜到的很多消息队列的对比文章还在说 Kafka 不可靠，其实这种说法早已经过时了。当下的 Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。
Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。
Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。我曾经使用配置比较好的服务器对 Kafka 进行过压测，在有足够的客户端并发进行异步批量发送，并且开启压缩的情况下，Kafka 的极限处理能力可以超过每秒 2000 万条消息。
但是 Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。
第二梯队的消息队列
除了上面给你介绍的三大消息队列之外，还有几个第二梯队的产品，这些产品之所以没那么流行，或多或少都有着比较明显的短板，不推荐使用。
在这儿呢，简单介绍一下，纯当丰富你的知识广度。先说 ActiveMQ，ActiveMQ 是最老牌的开源消息队列，是十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。无论是功能还是性能方面，ActiveMQ 都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容那些还在用的爷爷辈儿的系统。
接下来说说 ZeroMQ，严格来说 ZeroMQ 并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用 ZeroMQ。
最后说一下 Pulsar，很多人可能都没听说过这个产品，Pulsar 是一个新兴的开源消息队列产品，最早是由 Yahoo 开发，目前处于成长期，流行度和成熟度相对没有那么高。与其他消息队列最大的不同是，Pulsar 采用存储和计算分离的设计，它有可能会引领未来消息队列的一个发展方向，建议持续关注这个项目。
最后
如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。
如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。
如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。
如果这些场景和你的场景都不符合，还是不知道如何选择，那就选你最熟悉的吧，毕竟这些产品都能满足大多数应用场景，使用熟悉的产品还可以快速上手。
总结：需要发下今天学习总结