慕课网笔记-阶段3-分布式消息队列-RabbitMQ-分布式消息队列（MQ）认知提升

一、学习指南

Hello，小伙伴们大家好。从今天开始，我们一起来进入下一个大模块的知识点学习，这个大模块我们来一起学习一下分布式消息队列，也就是mq的设计与落地。在大模块中，我们其实主要围绕这两个业界非常主流的开源消息中间件为主，第一个就是我们的RabbitMQ，也就是兔子，第二个就是我们的apache的kafka，这两个mq也是业界非常主流的mq，当然在课程学习过程中还会涉及到比如说像activeMQ或者是RocketMQ这些都作为一些课外的扩展知识，会跟小伙伴们去提一下，如果有兴趣的话，以后小伙伴可以跟我去交流。
在慕课网上也有一个专门针对RabbitMQ的一个教程，欢迎小伙伴们去收看。好了，我们废话不多说，直接进入这个模块的学习。首先我们来看一看这个大模块，既然围绕着RabbitMQ跟kafka，主要要学习哪些内容？

首先我们第一点肯定是要对分布式消息队列做一个提升性的认知，会教会小伙伴们如何去做技术选型，mq之间的特点都有哪些，适用于什么场景，适用于什么样的解决方案，这个会最开始分享我们把整个的知识点进行一个普及，然后我们就进入我们第一个主流的mq了，也就是RabbitMQ。首先我们针对于RabbitMQ的实战慢慢进行一个讲解，然后我们要做一个庞大的可能需要花几个小时的这么一个RabbitMQ可靠性的基础组件封装。在基础组件封装中，老师会从0~1手把手的带着小伙伴们去把它一点一点的完善好。

好了，接下来我们继续看我们第二一个mq讲的就是Kafka，相信小伙伴们对于Kafka如果你没用过的话，起码你肯定听过，是不是在海量数据存储的这么一种模式下，比如说我们的一些日志收集，还有一些用户的行为分析等等，都可能会借助于Kafka来做一层中间层的传输与传输，这个也是业界非常有名的信息中间件，Kafka为什么性能这么高，为什么它的吞吐量这么好，其原因其实也是Kafka在内部做了很多针对于OS级别就是操作系统级别的一些特性。
好了，我们应对于卡卡实战之后，我们就跟大家从0~1去搭建一个Kafka高吞吐量的日志收集实战。在这里我们可能要学习我们的前面所讲的一些elk的知识，比如说Elasticsearch做存储对吧？还有我们的Logstash，包括我们的Kibana展示等等。
那么接下来我们会做一个架构思考，比如说分布式日志追踪，报警以及分析的这么一个平台，跟大家去把这个平台说清楚，整个这一个大模块也是非常有技术含量的，那么我希望小伙伴们通过我们这一个课程的导航，能够知道我们接下来要学习哪些内容。两个组件，一个是RabbitMQ，就一个是Kafka，针对于它们不同的特性，我们去来做逐一的讲解。

好了，我们快速的去进入我们分布式消息队列的认知提升这一小章节。首先我们来看一看这个课程的导航，在这一小章节中我们要学习哪些内容，首先我们要对有业界非常主流的分布式消息队列做一个介绍以及相应的技术选型，然后接下来是要对于我们的ActiveMQ的特性和原理以及它的执行架构做一个说明。
当然ActiveMQ它不是我们课程的重点，所以说老师提供了一些文图的资料，还有我们对应的代码，希望课下小伙伴们有兴趣的可以来学习学习，也欢迎小伙伴们跟我一起去交流。
在这里我相信大家都知道了，我们的课程是有一小部分的文图内容，还有一大部分视频课程。
接下来我们就是要进入到正式环节了，我们要学习RabbitMQ的一些特性和原理以及集群架构的解析。当然在这里边我们其实也是采用文图的方式跟大家去详细说明的。

接下来我们继续往下去看，接下来我们要针对于我们的RabbitMQ的特性、原理以及集群架构进行一个分析和学习。然后我们要对Kafka，也就是说我们第二个非常主流的中间件做一个特性原理分析，以及我们的集群架构的解析，这个就是我们这一章节的一个课程导航。

二、mq的应用场景与mq性能衡量指标

这节课我们来进入业界的主流的分布式消息队列与技术选型。如果你作为一个技术类的，或者是作为一个技术的负责人架构，以后再去做技术选型的时候，是不是首先第一点，你要对比较主流的类似的技术一定的认知，甚至说真正的生产环境下的实践经验才可以去做技术选型，要不然的话我觉得不太合适。
好了，我们在接触mq和技术选型之前，我们首先要知道mq能为我们做什么。首先分布式场景有哪些？我们来看一看。

比如说系统之间如何去做解偶，我们的服务之间如何去做一个合理的拆分和隔离，这个是非常有必要的。当然服务的拆分和隔离这个是业务层面上的一个划分，既然拆分和隔离之后，我们怎么去通信？
要看你的服务依赖性到底是强依赖还是弱依赖，这个其实就是微服务的这么一个技术手段了，如果是强依赖的话，我们可能采用的一些直连的方式，比如说我们同步的doubble调用，同步的HTTP，如果是弱依赖，我们就可以去选用这个消息中间件帮我们去做消息的解耦，当然如果是这种弱依赖不代表着说就是我可以失败。如果说弱依赖不能失败，比如说我们上游的服务去做了一次这个消息的发送了mq，然后下游的服务一定要收到这条消息，然后并做一个相应的消费处理，这个时候可能就需要上游服务做一个可靠性的投递了，这个是后面的事情。我们到时候给小伙伴们去聊。
除了我们的服务解耦以外，比如说我们在生产环境中，如果你有一些即使是很高或者是说流量很大的这么一些应用场景，比如说秒杀或者是一些大促的这么一个业务场景下，你如何去对我们的应用服务做一个抗压，这个就需要做一个mq的削峰和填补。削峰和填谷的意思就是说把流量的高峰和低谷的速率做一个均衡。我们的mq它本质上最早期做的就是这件事情，MQ他做的事情就是说，当我的下游服务处理不过来之后，我可以把消息缓存到一个地方，然后慢速去消费，这个就是一个削峰对吧？当然我们的大促它不可能持续的时间很长，你比如说双11的大促，他可能持续了半小时一小时，后面相对而言就会比较平稳了。我们可以把开始的大促的消息，我们把它积压到囤积到我们的Mq中去，然后慢慢的去做一个消费，这也是可以的。
除了做削峰和填补以外，它其实还可以做什么，还可以做异步化的一些缓冲异步化的一些处理。有些业务逻辑我们可以允许一些异步的操作，我们只需要做到一个叫做最终一致性即可。你不需要做一个实时的强一致性，我们只需要做一个最终的强一致性即可。类似于这种柔性的事物，基本上就是我们消息中间件实际的应用场景，我希望小伙伴们要把这三大类去记忆清楚，在以后你的业务上，你如果说遇到了这三种业务场景的话，就可以选择mq去做实际的解决方案了。

接下来我们继续往下看，分布式消息队列应用的一个思考点，什么意思？就是说分布式消息队列我们在使用的时候，既然你已经选择了mq去做这件事情，那么你要思考哪些问题，能够保障你的消息，比如说我们消息要可靠性或者是怎么样的，对不对？你要考虑哪些你非常关注的点，对吧？首先第一个就是我们生产端的可靠性投递，如果你是金融领域相关的，这个消息一定不能丢失，你一定要做到生产端的100%可靠性投递。我这条消息发出去了，跟我的数据库一定要保障一个原子性才行。
通常我们怎么去解决？其实后面的老师会详细的跟大家去慢慢的去解释，慢慢的去进行讲解。
然后就是我们的消费端的幂等，生产端想做到可靠性投递，可能会有重复的消息，如果重复的消息，我消费端消费了两次或者多次，这个数据肯定就不一致了。所以说我们消费端一定要做一个幂等性的验证，不能让这个消息消费多次，也就是说消息只能消费一次。
然后我们的mq还需要考虑到哪些点呢？剩下的可能是一些mq本身的特性，比如说mq的高可用性，如果说我们的应用服务，其中有一个mq的brocker节点挂掉了，宕机了，磁盘不可用了，我们怎么去能够保障它的一个高可用？
接下来就是mq的低延迟，在巨量的峰值，我们的流量非常大的冲压冲过来的时候如何你能保证一个低延迟以及消息的可靠性？就是说我们的消息落到MQ，我是否能够保障它肯定不会丢失。如果说磁盘发生损坏，我们是不是可以有一个相应的一些解决手段，我觉得小伙伴们应该有一定的认知。
比如说我们的高可用，就是我们的HA？可靠性其实说白了，我们现在业界主流的技术框架是怎么去解决的呢？无非就是我们的replicate的方式，就是副本的方式，比如说Kafka，甚至说我们的es(ElasticSearch)它都会有一些分片和副本的一些概念，以及我们的消息的堆积能力，应对于你的业务场景下，你到底有多少个数据，多少的数据量，然后我们大体预估一下我的消息在高峰期能够堆积到什么程度，这也是非常有必要去考量的。
后面再去做技术选型的时候，你一定要去衡量这种mq能不能扛住你们目前的业务场景下的冲击，如果扛不住，那是不是就有问题对吧？有问题是不是就不能选择？这是第一点。
第二点就是说如果他做不到高可用，会不会有问题？他做不到可靠性，做不到低延迟，会不会给我们的业务带来一些瓶颈，会不会给我们业务带来一些麻烦，这些都是作为一个架构需要去认真思考的一些点。
再往下看，包括我们mq的一些可扩展性，比如说你的消息队列能否支持天然的无感知的这种横向扩容，这个其实也是相对来讲需要考虑的一些问题，还有一些其他的可能在这里老师就不过多赘述了。
好了，我们带着这几个问题，也就是说生产端的可靠性投递消费端的幂等以及高可用、低延迟、可靠性、扩展性、消息的堆积能力等等，去来针对于下面业界主流的分布式消息队列，进行一个详细的一些介绍讲解和说明。

三、mq的技术选型关注点

这节课我们来看一看主流的分布式消息队列都有哪些？首先我们来看一下主流的分布式消息队列，第一个ActiveMQ，它是我们一个非常经典的比较古老的这么一个MQ，它的功能其实是非常强大的，也是Apache的一个顶级的开源的消息中间件。在以前在一些中小型的企业或者是说一些企业级的管理系统应用非常的广泛，就是ActiveMQ。
然后我们接下来要说的RabbitMQ，它其实跟ActiveMQ就差不多，RabbitMQ也是目前业界非常主流的一个消息中间件，这个也是