消息中间件

ITfeib

已于 2024-03-09 20:23:31 修改

阅读量429

点赞数 7

分类专栏：面试总结文章标签：消息中间件

于 2023-12-27 16:23:29 首次发布

本文链接：https://blog.csdn.net/qq_51240148/article/details/135243693

版权

面试总结专栏收录该内容

10 篇文章 0 订阅

订阅专栏

文章目录

1. 消息不丢失
2. 消息重复消费
3. 死信交换机实现延时队列
4. 消息堆积问题
5. rabbitMQ高可用机制
6. Kafka是如何保证消息不丢失的
7. 消息的顺序消费
8. Kafka高可用机制
9. kafka数据清理机制
10. kafka中实现高性能的设计

1. 消息不丢失

在这里插入图片描述

2. 消息重复消费

在这里插入图片描述

3. 死信交换机实现延时队列

延时队列 = 死信交换机 + TTL
延时队列用在有时间限制的消息的消费问题，可以对消息设置超时时间，当消息超时后就会转发到死信交换机，它也绑定了队列，比如说一个订单，时间到了之后就会由死信交换机路由到队列，拿到这个消息后判断是不是已经支付成功，没有支付成功的话就取消订单。
在这里插入图片描述

4. 消息堆积问题

在这里插入图片描述

5. rabbitMQ高可用机制

镜像队列和仲裁队列
在这里插入图片描述

6. Kafka是如何保证消息不丢失的

在这里插入图片描述

7. 消息的顺序消费

在这里插入图片描述

8. Kafka高可用机制

kafka的高可用其实是基于分区备份机制实现的，一个分区的消息会保存在不同的broker中，当这个分区的leader对应的broker宕机后，其他的broker中也会有这个分区的备份数据，分区的leader是负责读写数据的，那从这个分区的副本中可以选择一个作为分区的leader，也就实现的高可用。
在这里插入图片描述

在这里插入图片描述

9. kafka数据清理机制

kafka文件存储机制：在这里插入图片描述

10. kafka中实现高性能的设计

口述：高性能的设计无非是从两个维度来进行考虑，计算和IO，其实像kafka啊MQ啊，还是说其他的消息队列，都是一个 IO 密集型应用，从IO的角度来看，其实它涉及都两种IO磁盘IO与网络IO，对于网络IO，Kafka采用了批量消息的发送方式减少了网络的开销，包括像消息压缩啊，就减少了数据量，提高了网络的传输率，并且kafka也采用了IO多路复用技术，它采用的是典型的Reactor 网络通信模型， 1个 Acceptor 线程，负责监听新的连接，然后将新连接交给 Processor 线程处理，N 个 Processor 线程，每个 Processor 都有自己的 selector，负责从 socket 中读写数据， M 个业务处理线程负责业务处理，它可以复用一个线程去处理大量的 Socket 连接，从而保证高性能。对于磁盘IO的话，kafka采用了顺序IO的方式，将消息追加到文件中，所以性能也比较高，并且kafka还使用了页缓存技术，磁盘顺序写加上页缓存更好地解决了日志文件的高性能读写问题，为了同时去读写这些文件，kafka使用了分区分段的设计，将一个topic数据分区存储，那分区在不同的borker上不同的服务器上，那就提高了并发度。
这些都是kafka高性能的体现，其实kafka中也有线程池的这种思想，它采用了内存池的复用机制，其实和线程池的本质是一样的都是为了提高复用，减少频繁的创建和释放，只不过kafka其实它复用的是内存，是batch为单位的内存，其实就是当这个batch中数据发送完了，那这块内存就要释放了，其实JVM在GC的过程是会STW的，kafka采用了内存的复用技术，当需要用的时候直接从内存池中去取，不用了就放回内存池等待复用，不会涉及到GC，这其实也是高性能的体现吧。

redis为什么这么快：
无非就是两个方面，计算和IO，那针对计算的话，redis它是内存级别的，本身计算就很快，而且redis还采用了非常高效的存储结构，像hash表啊跳表啊，非常高效，所以计算问题不是redis的性能瓶颈，IO才是redis的性能瓶颈，针对IO来说的话，IO其实也分为了磁盘IO和网络IO，像磁盘IO的话，其实就比较中规中矩了，比如说生成RDB快照，也是为了提高性能它会fork子进程去完成，以及AOF刷盘策略啊，redis也是提供了不同的策略吧，可以去选择，也是为了能尽可能提高性能吧，当然性能好的话安全性也就下降了，这个的话可以去衡量选择的，这些都是涉及磁盘的IO，redis这么快其实取决于它的网络IO模型，Redis采用epoll的多路复用模型，epoll其实底层是用红黑树加链表实现的，redis服务端启动时，就会创建epoll实例，其实就是创建了红黑树和链表，服务端的socket会注册到红黑树上，当事件准备就绪后就会触发回调将红黑树上的文件描述符记录到链表中，链表中记录的就是所有准备就绪的事件，根据不同的事件再进行处理，其实也就三种事件，服务端读事件、客户端读事件和客户端写事件，在redis中它会根据不同的事件去不同的处理器去执行，像连接应答处理器它处理的就是服务端的读事件，也就是处理连接请求，以及像命令请求处理器它处理的就是客户端的读事件其实就是redis命令读进来，命令回复处理器的话它处理的就是客户端的写事件将命令结果返回给客户端，对于命令请求处理器与命令回复处理器在redis6.0采用了多线程的方式，也提高了命令的处理速度。总结下来的话，redis这么快就是因为它采用了epoll这样的io多路复用模型，虽然说它是单线程的，但是它只有当对应的文件描述符有准备就绪的事件时，才会去处理它，处理的都是有用的，非常高效，并且在命令请求和命令回复处理器上，也是开了多线程来加速处理，所有redis非常的高效快。
在这里插入图片描述