一、学习指南

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也是目前业界非常主流的一个消息中间件，这个也是我们模块里边重点要跟大家去讲的一种MQ。后面我会详细去说。
然后我们再去看刚才我们看到的这一款是RocketMQ它是之前是阿里巴巴开源的中间件，现在已经捐给了Apache，目前已经到了4.5.1这个版本，它已经支持了很多功能，丰富的消息拉取和消费机制，包括消息支付消费机制，它这个也是目前非常主流的一个开源的消息中间件，现在可能也支持了分布式的事务。
然后最后一个也是我们这一个大模块重点要讲的一种mq，这其实叫Kafka，它主要关注于我们的高吞吐量，还有海量的数据的一个转储工作。
这4种消息中间件目前是业界非常主流的，然后我们来看一看如何去进行技术选型，现在我们已经知道这4种消息中间件了，技术选型要从哪些点着手去考虑呢？

首先就是关注各个mq的性能优缺点以及相应的业务场景，在这里我简单说一说，像ActiveMQ，它是适合于这种传统行业中小型公司，并且它的并发或者说消息的承载能力不是那么特别的优秀，你比如说你想要去应对天猫双11大促这种场景，ActiveMQ就很明显是不满足需求，也就是说如果以后你们公司的业务如果是有高并发海量数据大流量的这么一个需求的话，那么如果想要去做服务的解耦，如果用ActiveMQ的话，这个明显不是说特别合适的。
但是说如果你是这种中小型的业务系统，或者是说互联网内部公司的一些边缘的系统，如果你想用ActiveMQ就最完全也是没问题。Ok它应对于不同的场景，然后我们接下来继续往下看，如果是RabbitMQ的话，那很明显是可以满足需求的。但是RabbitMQ它也有一瓶颈，比如说RabbitMQ我们后面要学习它集群模型，它有这种镜像队列，主要是满足这个数据不就是可靠性，高可用等等。但是RabbitMQ它的横向扩展能力不是特别好，所以说这里边我们到时候去学习的时候会想小伙伴们说。
然后我们继续往下去看，比如说集群架构模式，分布式、可扩展、高可用，可维护性，在这里我们对应着像ActiveMQ、RabbitMQ、RocketMQ以及Kafka，其实都有自己的集群架构模式以及分布式的实际的搭建，但是可扩展性还有可用性以及可维护性，后面这三点就要针对某些不同的mq它自己有自己的特点，我举个例子，像RabbitMQ它可能可扩展性不是那么特别好，需要你自己的去加一层中间的路由组件，但是它的可用性和可维护性都是业界首屈一指的，像我们的Kafka，或者是说刚才我说的RocketMQ，它的扩展性是非常强的，高可用性也是具备的，然后可维护性可能稍微有一点点麻烦。
继续往下去看，除了这些硬性的指标，你还要去考虑一些实际的情况，比如说结合综合的成本，还有集群的规模以及人员的成本，人员成本指的什么意思？比如说你们团队里他可能对mq认知不是那么特别的清楚，或者是说相对来讲有些mq应用的不是特别多，那么你就要看我们公司的技术栈，大家对哪一种mq比较熟悉，或者是说作为一个架构，你能hold住哪一种mq，然后并且能满足你的业务需求，那么你就可以去做一个最终的选型。
当然你也要考虑以后的各方面，比如说扩展性、扩容、伸缩性，还有可用性，数据丢了，磁盘坏了，怎么去做恢复，这个都是你需要综合去考虑的，刚才我说的就是说未来的方向规划和思考，这个都一定要有。
所以说针对于技术转型，其实不仅仅是mq本身上的优缺点，一定要结合的业务场景，以及对于集群搭建的一些分布式扩展性、可用性、可维护性的一些特性，以及再结合你实际的集群规模和人员成本，集群规模是什么意思？比如说我们如果说消息不是那么特别要求可靠性，对可靠性依赖不是特别高，我完全可以用Kafka。为什么？因为Kafka可以在很廉价的服务器上，然后有着非常高的性能和吞吐量的表现。
好了，这个就是我们这节课要跟大家讲的如何去进行选型，后面我们会详细的去针对于每一种mq做一些介绍。

四、rabbitmq集群架构模型与原理解析

这节课我们一起来介绍一下RabbitMQ的特性原理与集群架构模型的一个解析。首先我们来看一看RabbitMQ四种集群架构。
第一种叫做主备模式，这种主备模式它可以理解为我们的一个热备份，就是说我有一个master还有一个slave，在正常情况下，我们的master是对外提供主写的，而slave仅仅作为一个备份，当我们出现异常的时候，比如说master故障当机的时候会做一个切换，然后我们的slave节点会升级成一个master节点，这种方式也是非常经典的一种模型。
接下来我们再看一种远程模式，远程模式这个是RabbitMQ早期版本提供的一种多活的存储，主要是做数据的异地的容灾，异地的转移的，它也可以提升我们的性能。比如说当我们单节点就是单个集群处理不过来的时候，可以把消息转发到下游某一个集群中，那这种方式它的架构其实非常简单，但是它的配置说白了就非常的复杂，所以说后面也考虑一般都会用这种多活模式来替代这种远程演示，远程模式我们仅仅去了解一下就可以了。
接下来要介绍这种叫做镜像模式，这种镜像模式是业界使用最为广泛的一种RabbitMQ集群架构的模型，这种模型能够保障消息是非常可靠的，后面我们会详细去介绍。
最后一种就是多活模型了，多模型其实跟远程模型也差不太多，就是做一个异地的容灾或者是双活，或者是数据的一个转储功能，路由转发的功能。

好了，我们接下来首先来介绍一下我们的主备模式，主备模式也叫做兔子窝，通常就是一个主节点加一个备份节点，然后采用这种主备的方案当然是热备份，如果主节点由于某些故障挂掉的话，承接点可以继续的去提供服务，然后去做一个切换。
RabbitMQ它也是一种主备的机制，当我们RabbitMQ的master挂掉的话，它会利用Zookeeper去做一个切换，并且它的切换也是秒级的，也不会说太影响我们整个的mq集群服务，那也是做了一个热备份，只不过区别点就是在于RabbitMQ的主备模式，它采用的是haproxy去做的，而我们之前的ActiveMQ他采用的是Zookeeper去做的这种主备。
好了，接下来我们继续往下看。

首先我们来看一看主备模型，上面比如说是我们的consumer或者是provider生产消费者，总之我在这里的consumer注意指的不仅仅是消费者，他可以理解为是一个需求方，他通过haproxy去路由到默认是路由到主节点master，然后默认就是master去提供服务，当我们master出现故障的时候，下一次路由在我们haproxy里边配置了一些规则以后，它会帮我们去录入到备份节点，备份节点会升级为主节点。
当我们的主节点再次比如说修复好了之后，他也是加入到集群了，成为原来备份节点的一个备份节点。说白了就是主节点会进行一个漂移。Ok下面这就是我们的共享存储了。

好了，我们再往下看，对于主备模式，它的haproxy里边的一些核心配置有哪些？在这我跟小伙伴一起来简单看一看，有兴趣的小伙伴可以去自己课下去搭建一个主备模式。
其实很简单，对于haproxy第一个listener，你主备模型的一个集群名字，我这里叫做RabbitMQ_cluster，绑定的端口5672，接下来就是轮巡的模型，就是轮巡的model是TCP还是HTTP还是其他的协议，这个其实haproxy我其实在课程中也会稍微的去扩展一下其他的技术点，因为我们毕竟是一个架构的课程，我期望的小伙伴对于很多主流的中间件，前端包括存储层也好，都有一定的了解，这个时候你的阅历眼界不断的去丰富，你才有一个全方位的站在上层的角度去思考问题。
我说haproxy其实跟nginx也差不太多，nginx也提供了很多，包括tcp,http的这种协议，这种轮巡的模型，对于轮休模型，主流的轮训模型就是Robin就是轮训，还有什么？还有我们比如说最小连接数的一种balance策略，包括我们说的哈希算法帮我们去做哈希算法等等这种轮询策略。有很多，然后我们看一看haproxy主节点就是76，然后备份节点是下面的77，主节点它做一个check，当我们每5秒钟做一个check，如果两次失败的时候会帮我们去切换到什么？切换到下面比较长的配置里，这个就是我们的备用节点，它比上面唯一的区别就是多了一个backup配置。这个backup关键字ok，这个就是我们兔子窝的主备的这么一个配置，是不是非常简单。

然后接下来我们去介绍一下远程模式，它的概念就是进行远程的通信、复制，可以实现双活的一种简单的方式，简称Shovel，这种远程模式在现在来看它其实用的并不是特别多了，为什么？
因为它的可靠性可能还有待提高，并且它的配置也非常的麻烦。后面我跟小伙伴们说就可以了，所谓这种Shovel其实就是我们可以把消息进行不同中心的一个复制和转移的工作。当上游的mq比如说压力过大的时候，有些消息它处理不过来了，我们可以把它堆积到另外一个地方，然后让他两个集群进行一个互联，这么一个操作。

好了，我们接下来通过几幅图来看一看这种思路，就是我们的远程模式是如何去做的，这个也是官方的意思图了，比如说用户发消息通过website，然后到我们第一个RabbitMQ集群去做消费处理，然后这里边注意有一个Shovel叫做replicate的，是不是？就是说我们的消息可以被转发到下游的另外一个地点的mq中心集群，然后也可以去做一个消费的处理。
它不仅仅是能够做一个容灾，而且还可以提高我们的什么？提高我们的订单的速率消费速率，当然这里面有一个order对吧？好了，我们接下来再看，这是第一个mq的集群。

上面这是第二个mq集群，它可以帮我们去做一层路由的转换，也就是说当我们第一个集群消费不过来的时候，可以去转到第二个，当我们第一个集群出现问题的时候，也可以找到第二，这个是什么？一种多活的方式，ok为什么说现在用的不多，原因就是因为它的配置非常的复杂，它的配置我们在这里简单读一读就好了，因为实际工作中很少人去使用这种远程模式。

首先它要启动RabbitMQ的插件，RabbitMQ首先要启动它的amqp_client，为什么？因为这种远程模式，它们mq集群之间的通信是用到了Mq的amqp协议，然后去做通信的，然后你还要enable它的Shovel插件，这才可以这是仅仅是第一步。

Ok第二步还要对一些配置文件进行配置，比如说对配置文件叫做rabbitMQ.config做一个配置，你做法就是你要touch到一个配置文件，开始完了之后要对配置文件加一堆的配置，主要是我们的原与目的地的一个配置，当然这里说原和目的地使用相同的配置就可以了，我们来看一看配置有多复杂，在这里简单跟大家看一看。

大体上就是说你当前两个机群想要建立关联，有一个source就是圆，还有一个destination对吧？然后对于每一个broker它的地址你要配置一下，对于它的declaration就是你要声明什么队列，需要帮我去做路由，什么交换机，然后怎么去绑定规则，就是说你每次建一种exchange交换机，每次建一种队列的时候，可能都需要在里面去加一个配置，把路由去通过配置写上，如果以后你要加配置你怎么办？如果你要加队列，想要帮我去路由到下游的destination，你就在配置文件中还要去加，其实这个是非常不方便的，运营起来非常麻烦的这种方式，所以说老师不是那么特别推荐的，大家对Shovel模式进行太深入的学习，有兴趣的可以去参考一些资料，然后自己搭建一下。

当然其实最终我们业界目前使用RabbitMQ集群，最主流的还是我接下来要讲的这种模式，叫做Mirror镜像模式。镜像模式它也是一种非常经典的集群架构，它能够保障数据100%不流失，它是怎么去保证的？镜像的概念其实就是一个复制，我们来看一看，在实际的工作中使用非常的多，并且我们很多互联网大公司都是使用这种方式来搭建RabbitMQ集群的，镜像模式，其实说白了就是我们数据的一个备份，同学们其实可以想一想，像镜像模式，业界有哪些或者说你知道有哪些技术使用这种复制的概念，其实最主流的或者是说最显而易见的，大家如果对mongodb熟悉的话，它有一种模型就叫做复制机replicate的这种方式，这种其实跟他比较相像，或者是我们es中的一些replicate副本概念，当然它的缺点也会有。我们后面再说，这个就是RabbitMQ的镜像。

RabbitMQ镜像队列它能够保证哪几点，第一点就是可靠性数据不会丢，因为它的数据发过来，它要同步到对应的镜像集群内，所有的节点都会做一个数据的备份存储了，所以说即使是说你集群中有一个节点挂掉了，有一个节点磁盘坏了都没关系，我们通过镜像队列的一些恢复手段都可以做一些恢复。
然后它就是内部主要是做的数据同步，因为我们都知道RabbitMQ它的底层是Erlang写的，天然的这种交换机的方式，它有着跟原生socket一样低的颜值，所以说它的性能在做数据同步的时候，它的性能是非常好的，ok然后它还可以保证可靠性，保证可靠性，最好大家是奇数个节点，一般我们做集群都会选择奇数个节点，第一点防止脑裂，对吧？脑裂其实就是做选举的时候能够更快的把master去选出来了。

Ok接下来我们来看一看镜像队列，如何去搭建集群。这幅图其实就是一个完整的镜像队列集群的模型，先从最下面去看。最下面是三个节点的mq服务器，大家可以看到叫mirror queue，然后第二个也是mirror queue，第三个也是mirror queue，也就是说我们三个节点数据保存都是一致的，这个就有点像我们的复制机的概念了，mangodb的。
Ok再往上看就是我们上游的服务，这里边老师就直接写死了，叫做springBoot application，他去访问我们的镜像服务器，MQ服务器，他不是直联的，它是通过一层中间的代理层，中间代理层蓝色的用什么？其实还是用haproxy，但是我在这里又加了一个叫做KeepAlived，为什么？
因为当我们haproxy如果是单点的话，如果发生故障，就这台服务器如果挂掉了或者有问题了，那是不是你整个就提供不了服务了，所以说利用KeepAlived来做一个什么高可用，它会虚拟出来一个VIP，我们应用服务直接去通过VIP跟我们的两台haproxy方打交道，当然它只是路由到其中一台，然后由其中一台的haproxy帮我们去负载均衡到三个最下面的最底层，ok。这个就是一个镜像队列集群，后面我们也会详细的跟大家去说明镜像队列集群如何去搭建。
Ok，最后我们希望他们想一想，这种镜像对面有一种天然的缺陷是什么？其实一眼就看出了缺陷就是说它不能支持横向的扩展，因为它的数据存储是有限的。当我们的数据量尤其在高峰期的时候，如果一旦流量非常大的话，可能我们消费者他消费的速率没有那么快，那消息都会堆积到我们镜像队列上，横向扩容根本就没有意义。
因为什么？你横向再扩一份，它是增加了我们RabbitMQ集群的负担，因为4个节点4份数据要同步，肯定性能上吞吐量上一定是有所降低的，所以说其实官方也建议说，如果镜像队的集群三个就好了，三个其实能够保障一个可靠性奇数个节点，也就是说最小的基数个节点了。
如果说你现在想要横向扩容应该怎么办？在这里官方其实提供了一种叫做多活模式，Federation也就是下面我们要讲解的去解决这种镜像队列的一种无法横向扩容的一个缺点。

好了，我们来看一看多活模式，那多活模式这种模式其实也是实现了数据的异地的复制的这么一个主流的方式。
它其实相比于我们的这种远程模式就是Shovel，他其实肯定是有优点的，因为这种Shovel远程模式它的配置非常复杂，之前我们说了，所以说一般你想去做这种异地的集群、多活都会采用这种federation，就是我们现在要说的这种模式要依赖RabbitMQ的 federation插件去做，那也就是说你也需要安装一个插件，要federation插件，然后可以去实现我们mq可靠性的数据通信，并且也可以实现这种多活，我两个RabbitMQ集群中心，这样的话从宏观的角度来讲，让你整个的应用服务的更加的稳定一些。

好了，那么接下来我们继续来看，对于多活模式，RabbitMQ它其实采取了双中心或者多中心的概念了，两套或者多套数据中心，它各有一套mq集群，每个中心的集群除了正常的去提供自己所需的服务之外，还可以去做什么？对于一些关键的数据还可以去做数据的一些互通，一些共享，这也就是federation集群模型的最重要的这么一个特点。

接下来我们来看一看这个多活模型的一个架构图，也就是说我上面的Application是我的应用，然后我的对Lbs负载均衡器下面它负载到三个节点，然后这边也负载到三个节点看到吧？这个可能是一个镜像对内集群，这个可能也是一个镜像对内集群，但有一些数据你想保障不丢失，或者是想保障他们两个集群之间的异地互通，那中间就可以去使用我们的federation插件，去做消息的连接就可以了。
好了，那么我们接下来通过一段文字跟大家来简单描述一下federation插件。

对于federation他其实是一个不需要构建cluster的这种方式，其实本身自己的集群内部已经是镜像队列了，所以说你就没必要再搞一个什么federation集群了，你直接用它做一个插件，让两个集群之间做一个消息，相互之间的传输，做一个高性能的传输就可以了，federation插件可以在broker或者cluster之间进行消息传输，然后连接的双方可以使用不同的users和virtualhosts，就是说它不在意你的user权限以及virtual hosts，双方也可以使用不同版本的RabbitMQ和Erlang，也就说这两个东西你可以认为他们是完全独立的，它是怎么去做的，无非就是统一的一个协议对不对？
就是大家版本都不同，没关系，我们协议相同的就好了，所以说federation插件使用的协议就是我们RabbitMQ经典的amqp协议通信即可，可以接受不连续的数据的传输，这个是他的federation最优秀的地方，就是版本我要升级都没问题，可能就是有一些历史遗留原因，我一个中心的RabbitMQ集群，它可能搭建的比较早，另外一个我想用新的没关系是可以的，他们两个互通也可以，ok。

好了，federation本质上是什么？我们来看一看federation这里边本质上大家可以看到，它其实就是一个exchange，那可以看成downstream与从upstream主动拉取消息，那也就是说我们的下游从上游主动拉取消息对不对？但并不是拉取所有的消息。看见了，其实这个东西感觉就跟我们的什么呢？之前所说远程模式就是Shovel差不多，但是它解决了Shovel的弊端是什么？Shovel它需要在配置文件里去配，他没办法动态去做，就你想要去加一个什么加一个exchange，实际上它这两个集群多一个exchange做同步的时候，你必须要重启服务，然后在配置文件，你先配置好了之后，在起来这就非常麻烦，federation它的优点是什么，它的优点就是说你想去加哪几个exchange进行相互之间的通信和转发，可以，你直接可以通过控制台操作就好了。
所以说这个是可以可视化，而且是即时生效的，不需要写一些这种复杂的配置，也是支持这种热更新的，在这里必须是downstream上已经明确了绑定关系的exchange，也就是说你的downstream一定要有upstream上面的一个绑定，这样的话他才能够通过downstream自己的一个物理的队列去拉取upstream给我传过来的消息。
那么这里面也就是说amqp它实现的是中间两个集群的一个通信代理，downstream会将绑定关系组合在一起，绑定解除命令也可以去做，也就是说你说我配完了之后，我两个集群之间我不想去做通信了，可以直接通过控制台把exchange之间的连性的一个桥梁给它删掉就可以了，所以说这是非常方便的。

接下来我们来看一看federation的一幅图，这样大家就更好去理解了。刚才是完全的文字性的描述，这回我们看一看，这个是我们的upstream，左边的这块是我们的上游，下面肯定就是我们的downstream了，是不是，upstream跟downstream有什么区别呢？这里边注意它们两个之间有一个叫做upstreamlink，就是一个上游的连接，上游的连接一定要跟我们的什么？跟我们自己看，我们下游一定要绑定上上游的一个exchange，它们两个之间才能连上，上游消费完了之后，也可以把消息转发给我的下游，然后下游也可以做一个具体的处理，这就是一个federation，当然这里边自己他也可以去发消息处理，也就是说你可以认为是两个完全独立的镜像队列集群，只不过我们可以利用federation插件，实现上下游的一个灵活的消息的这种转储转发功能。
好了，这就是我们想要跟大家介绍的一个federation，这也是我们整个RabbitMQ它的一个核心架构的讲解。后面老师会带着小伙伴们一起去把这些集群架构模型就比较关键的都会跟大家讲到，现在在这节课有一个认知就可以了。

五、kafka介绍与高性能原因分析

那么这节课我们一起来看一看对于Kafka的一些相关的内容。首先我们来对Kafka进行一个简要的介绍，希望小伙伴们对Kafka有一个认知。Kafka它是LinkedIn开源的组织，做的一个开源的消息的分布式系统，它目前也是属于Apache的顶级项目，也是非常的有名气。
Kafka它主要的特点是基于pull的模式来做消息的处理了，也就是说做一个拉模式的消息处理，然后他追求高吞吐量，然后整个一开始项目的目的就是为了做日志收集和传输的，然后对于Kafka他也有很多版本，比如说0.8版本以后，他就开始支持复制，但是它不支持这个事务，因为它追求高性能，他肯定不能去加是加事务的，毕竟会损耗它的性能。
对于消息的一些重复消费丢失还有错误，他并没有严格的要求，因为它本身来讲做收集日志的几百万几千万上亿条几十亿条数据里丢个两三条，这是没有什么所谓的。它适合在生产大量数据的互联网服务中去做业务数据的一个收集。如果说你想要去做消息一条不丢，那Kafka能不能实现呢？有好多同学以前都会问老师这个问题，其实答案是肯定的，是可以实现的，但是实现的话它的性能就会降的比较多了。
所以说正常来讲，我们去选择Kafka一般都会容忍他有一些极少量的消息的丢失。我们继续来看还有哪些特点，这个是我们这节课一定要跟小伙伴们把它的特点还有它的优势说清楚的。其实在面试消息中间件有哪些优缺点，你是什么看法的时候，经常会问到一些mq之间的一个对比。

Kafka首先它具有分布式的特性，也就是说他支持消息的一个分区的概念。
Kafka里面非常核心的一个概念就是我们的partition，一个topic下面可以有好多个partition，然后Partition跟我们对应的consumer也是一定要一一对应上的。比如说你一共就4个partition，然后你十几个consumer的话，其实很多consumer只是浪费的，没有意义的。
其实跟我们很多mq它的初衷都是类似都是相像的，然后它具有跨平台的特性，它支持不同语言的客户端，比如说我们的Java、php或者是我们的Python都支持，所以说它使用起来也是非常的友好，对于一些异构的系统，然后它的实时性是非常强的，它的数据支持这种实时处理和离线处理，即使你的Kafka数据堆积了上亿几十亿的数据，只要你的存储是ok的，它不会影响Kafka的性能。
其实在老师以前真正的工作中也有遇到过，因为我们之前以前是用Kafka做日志收集，然后我们的瓶颈点后面是我们的日志收集的地方，就是我们的elasticsearch，es它的集群的磁盘满了，然后导致es已经做限流了。
然后我们所有的消息都堆积到Kafka，堆积了将近能有个七八个小时，我们之前的工作数据量是非常大的，七八个小时就能堆积了几十t的数据，数据的量差不多是几十亿，都存到Kafka，但是它并不影响Kafka的消息的接收和发送能力，所以这也说明了Kafka他的消息堆积能力也是非常强的，绝对是上亿级的消息堆积能力，然后它的伸缩性也是非常强的，支持这种水平的扩展。
这个就是我们跟大家来介绍Kafka它最关键的4点。在面试的时候你经常其实一定要谈到它4点，有同学说老师这4点我需要背下来吗？其实你不需要背，你作为一个架构设计者，当你学这门课程的时候，你就要从一个架构设计的角度去出发去考虑。
如果你的系统是异构系统的话，毕竟是多语言，无论是Java、Python还是其他的等等，你就要知道你就要支持这种异构的，首选，你应该选择哪些中间件能够支持异构，然后包括第二点是不是分布式，第三点是不是说它的实时性，还有离线处理，还有这个消息堆积能力是不是足够强，他支不支持扩展ok。
这个就是你作为一个架构选型最开始的时候要关注的这几点。

然后接下来我们继续往下看Kafka高性能的原因，它为什么性能这么高？这个是我在这节课重点要跟小伙伴们去详细的探讨的，这个也是一个面试的高频的问题。我希望通过这一小节的学习，小伙伴们课下能够自己耐心的把老师这节课所讲的内容充分的消化和理解，然后最好是形成自己的笔记，然后去回复。
首先第一点就是Kafka的顺序写，以及Page Cache。Page Cache具有一个特点，就是空中接力、高效读写。在这里我们简单来说一说顺序写，什么是顺序写？其实在这里就是一个顺序写盘，顺序写盘的过程，其实它可以去提高我们磁盘的利用率。你比如说我们的consumer通过offset顺序的去消费这些数据，而不删除已经消费过的数据，从而避免什么？避免我们磁盘的一个随机写随机写的过程。
但我不知道通过刚才我说的这句话，你自己脑海里有什么概念呢？我们回想一下业界主流的一些种种mq其实RocketMQ就是Apache的RocketMQ他也是借鉴了Kafka很多的特性，在自己业务的基础上去做了一个扩展。如果你要做一个MQ，你怎么去设计MQ的存储？很显而易见的就是你要做到顺序写，什么意思？就是说mq里的数据，我的生产者把消息发送到了mq的broker，然后我要存到磁盘的某一个点，我一定要记录一个位置，这个位置就是offset，然后这个offset肯定会被我们的consumer去消费，他消费的时候肯定会记录一下他当前消费的位置是在哪儿，他要记录一下他消费的offset，然后他基于offset之后再继续去往下去找下一个offset，然后去消费，只有这么一过程才能去充分的去利用我们磁盘的利用率，因为这才是顺序写一个的写，而不是说随机写。
为什么不是随心写？如果说你消费完了这个消息，然后你把这个消息从这个文件中的某一点去给它删掉，你想想它整个的文件，它的offset是不是就会变化？它是不是就会产生一个偏移？所以说一般mq的设计都会去不允许删除消息，这是重点。其实有时小伙伴有疑问，如果你用过一些云服务的话，比如说阿里云上的消息中间件mq，你会发现它阿里云上的消息文件，它支持能够删除某一条消息，他怎么去做到的，我希望小伙伴课下自己去想一想，他肯定不是说直接把文件中的某一个offset，这对应的消息删除的，而可能是做了一层转储，然后去打标记去做的。
相对来讲它的删除可能就不是物理删除，而是一些逻辑上的让你不可见。
好了，废话不多说了，接下来我们再看Page Cache又是什么鬼。我期望小伙伴对于一些操作系统os级别的基础应该有一定的认知，即使说以前你没有认知，我希望什么？通过我们这节课的学习，你应该有一定的认知了。
Kafka第一点高效的读写，它其实是利用了这种Page Cache的空中接力的方式，还有用Page Cache的清理，还有等等很多，比如说后台一些flush策略，还有里面有好多scheduler，然后主动地flush策略，包括一些预读的策略，IO的调度的一些策略有很多，它内部其实实现是比较复杂的，不过我们找准一点就好了，我们来看一看Page Cache，空中接力，Page Cache这个东西它能够做什么？
就是说我可以在廉价的服务器上，我都能支持单机每秒100k一条，100k一条，后面你自己想加三个0就好了。以上的这种吞吐量。
所以说Kafka说你不要害怕文件系统，Kafka它的高效读写就是简简单单的去做顺序的，去读普通的文件，然后建立于我们Linux内核的一个Page Cache，不显示的去用内存而胜似用内存，就是这个概念。我们继续我先往下走，高性能高吞吐，好像这是Kafka它的初衷了，做日志收集的肯定是具备条件的。
然后还有哪些高性能的原因，刚才我说的他有一些好多异步的这种IO级别的Schedule了，他能做什么？会将连续的小块组成一个大块的物理的这么一个文件，然后从而提高它的性能。Schedule可能会尝试着去将一些操作重新按照顺序去排好，然后从而减少什么？减少磁盘移动的时间，然后充分的去利用后闲的一些内存。
当然空闲内存肯定是非gvm识别内存的，然后Kafka它的读写基本上都是在Page Cache进行了，如果你的生产者跟消费者速度差不多相当，它甚至都不需要通过物理级别的这种磁盘去做数据交换，直接就读Page Cache了，Ok即使是你重启你自己的Kafka，其实Page Cache永远是可用的。
操作系统级别的Page Cache即使你服务器重启它是存在的，但是os级别的就不行了。 gvm的内存，然后你说你 tomcat重启了肯定都丢了，你要重新去加载。好了，我们继续往下，还有哪些就是我们说的这些IO的一些预读策略等等，这就是Kafka高性能的原因。

六、kafka高性能核心pagecache与zerocopy原理解析

接下来我们来一起来看一看pagecache。首先我们先把pagecache的概念跟大家来解释清楚，之后我们再通过一个小的示例来分析一下整个的pagecache的过程，或者是说一个操作系统级别的这么一个过程，这个也是实际在面试中经常会去问的，我希望小伙伴们来认真的去跟老师一起学习。首先第一点我们来说一说什么是pagecache，也就是页面缓存。pagecache是操作系统实现的一种主要的磁盘缓存，在这里要记住是操作系统主要实现的一种磁盘缓存的这种机制或者说策略，它的目的就是以此来减少对磁盘io的操作。
因为我们知道对于磁盘io他访问如果特别频繁的话，会影响我们整个操作系统性能，具体来说其实就是把磁盘中的数据缓存到内存中，然后把对磁盘的访问变成为对内存的访问，就是这么一个事情。
其实目前业界很多主流的框架或者是架构设计，或者是现代的操作系统，它其实为了弥补性能上的差异，它都是直接将内存作为磁盘去做缓存的。
当然磁盘缓存要加引号的，甚至说可能会将所有的内存就当做磁盘去用，这样也是想要充分的提高对于我们操作系统也好，或者是某个技术框架也好，就要提高它的性能，统一的去对把所有的io，原来对io的操作都会从内存中读取。
我相信很多做过一些高并发的项目的小伙伴都要知道，开始我们最早期的时候，可能大家会读这种管理型数据库，对不对？管理型数据库压力一旦大了怎么办？大家可能想到的策略去做分库分表，分不分表，它可能也有一天会满足不了我们的需求，你有可能会用一些非官方数据库，或者是用我们的remotecash，比如说远程存储缓存，像redis对不对？
当然像一些入口级别流量非常高，访问量非常巨大的一些入口上去扛住了，可能你redis都会扛不住，这个时候可能会借力于我们的内存，对不对？
当然我们都知道你把所有的数据都存到Java jvm的内存中，它也会非常影响我们Java的这个程序的性能，从而又有人说我们来把一些数据放到堆外内存中，我们这话不多说，最后老师给大家说一点pagecache，本质上就是把应该从磁盘中读取的数据转换成从内存中去读取，把对磁盘的访问变成对内存的访问即可。

接下来我们来看这幅图，这幅图说的是一个什么事情呢？这幅图主要就是对于磁盘文件的一个读写操作了，那映射我们Java，比如说在我们的d盘中有一个文件叫inner.txt，我们想把它读到我们的应用程序里，对于os级别、操作系统级别他都做了哪些事情？
我们可以想一想，其实当一个进程准备去读取磁盘上的文件内容的时候，操作系统它首先不是说直接去读磁盘文件了，它首先做的事情是什么呢？他首先肯定会做检查，先check，会去将待读取的数据所在的页来看一看这个页儿在pagecache中是否存在，如果存在就相当于命中了，那就直接把数据返回来就可以了，从而避免了什么？对物理磁盘的一些个IO操作。
如果没有命中，这个时候我们的操作系统会真正的向磁盘发起一次io请求，并且将读取的数据它不是直接返回给进程，它直接是先把我们的读取出来的数据先加入到缓存页中，去做一个缓存，然后再把数据返回给进程，他是这么去做的。
Ok这个也可以理解为就是一个空间换时间。其实你回想一下，我们其实有很多这种操作都是借力于这种机制，比如说我们数据库，当你去通过一些一个select的查询的时候，你第一次去执行这个查询语句，它的性能可能会稍微慢一点，对不对？可能会花费一两秒钟甚至更长，当然数据多可能会影响了，对吧？那么当你第二次重复的去再执行这条语句的时候，你会发现这条语句跑得飞快，可能把零点零几秒搞定了就返回了。
这个也是数据库，它也是帮你做了一层cache操作。
同理，其实现在越来越多的架构设计或者是底层存储都是使用cache去做的。
好了，反过来同学们想一想，现在是读是这么去做的，如果变成写，我说有一个文件我想写到磁盘中，同样那操作系统会怎么做呢？首先也会检查这个数据对应的页是否存在缓存页中，如果说不存在怎么办？他会在缓存页中去添加相应的页儿，然后把数据去写到页儿里面，然后被修改的过了一页，其实就变成了我们的脏页，操作系统会在合适的时机，这是他自己调度的事情。把脏页中的数据去刷到磁盘里，以保证数据的一致性，ok。
这就是一个最简单的文件读写的一个过程。
接下来我们看一看这幅图，如果说现在我们想把磁盘文件读到内存里，读到内存里之后，就读到我们应用程序里，然后我们通过应用程序再给他写回到或者在写到另外的一个应用程序，他经历过哪些过程呢？我们来看一看这幅图，首先第一个大家看到最右侧的这个是我们的磁盘文件，他经历第一步骤是什么？就是物理磁盘文件，操作系统会把物理的磁盘里的内容先写到内核读取的缓冲区，这是操作系统级别的看叫做内核空间上下文。
然后左边的这块完全就是我们应用程序的上下文就是你Java服务的上下文。
第二步他做什么事情，第二步他是通过从用户缓冲区去读取操作系统os级别的内核缓冲区的东西，就是说把用户缓存区，再次读取一下我们的内核空间的缓冲区，把数据再转过来，转到用户缓冲区域。这个时候应用程序里就有了，然后我们再去读什么，把它打印一下什么的，在你的程序里就能看到这个数据了。
假设说我们说这个数据，我想给它远程的给它传到另外的一个应用程序怎么办？
还是操作它现在数据在应用的缓存中，应用程序的环境中，他肯定要把数据再写入我们操作系统级别的os的缓冲区域内，然后内核空间缓冲区就是我们操作系统的os系统的缓冲区，然后再把OS缓冲区把数据再传到我们socket缓冲区，然后socket缓冲区再到达实际的物理网口，然后通过网络传给对应的另一端的消费者，这个就是我们正常的一个文件读取，然后写给另外一端的一个过程，他会经历过好几次copy，第一次copy是copy到我们的内核中了，第二次copy是录入缓冲区中又copy了1次，3次copy对不对？其实在这里一共有4次copy，因为我这块这个图已经画出来了，这边文件磁盘文件到我们的内核缓冲区就是第一次拷贝，第二次copy是我们的用户空间，从我们内核空间去copy了。第三次copy用户空间再copy到应用系统，就是操作系统级别的内核空间缓存。然后第4次copy是从内核空间的缓存copy到socket缓存区，然后写到网卡，他经历过4次的copy，这是我们传统的一个文件读写。但其实现在很多的应用都是使用什么叫做zero拷零拷贝。其实我们Kafka主要就是用zerocopy，他接手了这4次copy，它其实就是一次copy。
Ok，我们后面来看一看Kafka对一个文件它是怎么去做的。接下来我们继续往下看，这幅图其实就是利用了所谓的zerocopy，在Kafka中他经常会大量的去使用一些pagecache的一些技术，包括zerocopy的一些技术，用来提升我们的性能，提升我们的系统的吞吐量。
举个例子，比如说我们Kafka可能有一个生产者，有个消费者对不对？我们的消费者因为我们Kafka他都是pull的机制，就是拉取的机制。
消费者在读取服务端的数据的时候，就是他向broker去拉取数据的时候，肯定是需要将服务端的磁盘文件里的数据去读出来，对不对？比如说磁盘文件它可能通过网络发送到消费者的进程，然后通常情况下我们的Kafka消息它肯定会有多个订阅者，生产者发布的消息会被不同的消费者多次消费。为了优化这个流程Kafka，它其实内部就使用了zerocopy。Kafka中其实大量的使用的缓存页，包括zerocopy，这是Kafka实现它高性能高吞吐的一个非常至关重要的一个原因。

虽然消息都是被写到缓存页的，然后我们由操作系统去负责具体的一些具体的刷盘策略刷盘任务。我们看这幅图看这幅图，这幅图就是一个经典的zerocopy技术了，它跟应用程序是完全没有关联的，我们右边的应用程序完全不做任何copy，它就是做什么？磁盘文件直接是在用户内核的空间的上下文做一次copy，对不对？文件描述符，这个叫内核读写缓冲区，然后直接写到网卡给消费者，这个过程就是一个 zero copy。
那也就是说我们的zerocopy就是零拷贝技术，它只是将我们磁盘文件的数据复制到了页面缓存中，注意这一点，然后将数据从页面缓存直接发送到网卡中，就是说发送给不同的订阅者的时候，都可以去使用同一个页面缓存，而避免了重复复制的这么一个操作。这个就是一个 zero copy。
其实通过这个图我们设想一下，我如果说现在有10个甚至20个消费者，甚至更多的消费者，现在如果你有10个消费者在传统的数据copy的这种模式下，你至少要经历10×40次数，为什么？因为刚才我们看到这幅图了，是不是？如果说你现在有10个消费者，你想把磁盘文件中的数据想发给这10个消费者，是不是要经历40次？因为你每一次就是4次，而我们的 zero copy它需要多少次？同学们想一想，他只需要11次。为什么？第一次，他把磁盘文件copy到我们的pagecache中，然后接下来发10次就好了，是不是发给10个人，是不是把pagecache中的内容发给10个对应的消费者？对接到10个网络的IP和端口就可以了。这个就是Kafka它提升性能的一个非常重要的点，也就是说zero copy和pagecache。我希望小伙伴们通过这节课完全的把这两个概念理解清楚。其实在很多时候面试的时候都会去问关于pagecache和zerocopy的概念，我希望小伙伴牢牢的把这个东西记住掌握好。

七、kafka集群模型讲解

接下来我们来一起说一说Kafka一个集群模式，其实对于Kafka消息中间件，它的整个的设计和高性能以及它的一些优点，我们都通过上面的几节课跟小伙伴们介绍好了。接下来我们就简单来看一看它的集群模型。下面的绿色的就是表示Kafka的一个的节点，然后它其实是采用了Zookeeper去做了一个协调，那也就是说我们Kafka里边同学们想一想它有没有实际的物理存储也是有，但是它大部分的时间都是做的内存级别的，replicate副本级。
那也就是说之前老师所说的，当你Kafka的生产者跟消费者速率相当的时候，他甚至完全都不需要去用到磁盘，他磁盘就是一个异步的做一个备份而已，那就是说所有Kafka生产者进来的数据在内存中是不是我消费者直接从内存中从配置开始就拿走就好了，这个性能是非常高的。
有些小伙伴会有疑问说，如果说那Kafka怎么去保证数据的可靠性，它可能不会保证100%可靠性，但是他一定会有可靠性的考量，在Kafka老师也说了，我们利用的就是replicate内存级别的副本，就是说相同的一条消息，我在内存里存了一份两份三份。当然下面就有三个节点了，当我们一个节点挂掉的时候，我们另外的两个节点还有内存pagecache就是内存中的数据，我的消费者同样能从另外的两个节点去获取这个消息，除非你整个集群都挂掉了，这个可能会造成一些数据的丢失，当然其实Kafka里面也可以做一些相关的配置保障数据不丢失，这些其实也都可以做到，后面我们再详细的去讲Kafka的时候会跟小伙伴们详细的去做Kafka的一个集群搭建，一些API详细的设置怎么去保证Kafka的消息不丢，当然如果你想保证Kafka消息不丢，并且它的一些策略都可以设置的Kafka它的性能可能会有所降低。那么整个这一块对于Kafka的介绍就到这里，感谢小伙伴们去看。