八股文11：消息中间件（kafka+RabbitMQ）(针对项目)_消息中间件kafka,rabbitmq-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_39227541/article/details/125082919

文章目录

Spring整合kafka（项目：论坛项目）
Spring整合RabbitMQ(项目：商城)

Spring整合kafka（项目：论坛项目）

Apache Kafka 是⼀款开源的消息引擎系统

消息模型（kafka支持两种）

在这里插入图片描述

不同的groupID之间的用户属于发布订阅模式（不同的group之间消费主题是相互独立的，非竞争关系），属于同一个group内部的用户之间是竞争的模式----实际不会出现这种情况—只会出现闲散的消费者（消息队列模式）
在这里插入图片描述

消费者组的重平衡（同一个Group）

在这里插入图片描述

kafka的几个重要术语

在这里插入图片描述

Kafka 的多分区、多副本机制了解吗？带来了什么好处？

在这里插入图片描述

Zookeeper 在 Kafka 中的作用知道吗？（有多个Broker的kafka实例）

在这里插入图片描述

什么是zookeeper(分布式协调服务)??

在这里插入图片描述

什么是RPC（远程过程调用）

在这里插入图片描述

Kafka 如何保证消息的消费顺序？（单个partition内的消息有序）

在这里插入图片描述

位移主题（保存位移至一个消息的主题）

在这里插入图片描述

Kafka 如何保证消息不丢失

生产者丢失消息的情况（使用重发机制）

在这里插入图片描述
利用future接口来实现获取操作的结果

在这里插入图片描述

消费者丢失消息的情况（放弃–了解–防止offset偏移量自动提交）

在这里插入图片描述

Kafka 弄丢了消息（重要：leader副本与follower副本之间）

在这里插入图片描述

总结一下

在这里插入图片描述

Kafka 如何保证消息不重复消费（幂等校验）

在这里插入图片描述

什么是幂等性（多次提交是相同的）

例如生产者发送消息到kafka的消息队列时，在redis创建一个对应的消息的token,第一次消费成功，就将消息键删除，第二次重复消费发现redis不存在这个键的时候，就会发现重复消费了
在这里插入图片描述

为什么kafka这么快

链接传送门

*我的项目：事件触发生产+消费者消费事件

生产者+封装的事件Event+消费者
注意这个event对象的通用设计：topic+触发事件者的信息+被触发者的信息

1.系统的通知（评论+点赞+关注触发）

在这里插入图片描述
一旦”评论点赞关注“后就会触发–系统通知，然后立即封装event对象，并设置好主题，然后由生产者放到
topic对应的分区，之后消费者进行消费事件，将一个个的情况存入message（系统通知+私信）中，然后存入数据库中

2.发帖+删帖的topic

由于利用了搜索引擎ES，所以搜索引擎中的帖子
的数据必须和数据库中一致，一旦任何对帖子的修改都会触发这个事件，然后生产者放到对应topic的分区，消费消费事件时，对应的更新ES中的帖子内容

消费者@KafkaListener（）监听消费topic

在这里插入图片描述

Spring整合RabbitMQ(项目：商城)

RM的核心概念

基于AMQP(高级消息队列协议—属于网络层协议)
在这里插入图片描述

在这里插入图片描述

利用channel的思想，复用同一个TCP的长连接

在这里插入图片描述

Exchange类型(交换机类型)

在这里插入图片描述

工作模式（2+3按照交换机的类型）

在这里插入图片描述

参考一下

在这里插入图片描述

1.工作队列模式属于一个队列有多个消费者之间竞争消费；
2.发布订阅模式：每个消费者监听自己的队列，相当于避免了竞争（交换机可以使用扇出交换机实现广播消息到各个队列的机制）；
3.路由模式：属于直接交换机，完全按照路由键进行交换机分发消息至对应的绑定队列的（交换机与队列使用路由键进行绑定）；
4.主题模式：按照路由键的具体的内容进行匹配分发！！！

消息的可靠抵达（生产者与消费者）

在这里插入图片描述

publisher端确认消息的抵达和回退的操作

在这里插入图片描述

消费者端确认消息的成功消费，手动确认

在这里插入图片描述

如果消息被成功消费（正确的处理业务，此时消费者进行ACK，否则NACK—消息重新入队）
在这里插入图片描述

注意:1. 消费方如果不ACK这条消息，是不会收到下一条消息的，这就达到了限流的作用；
2. RM没有给长时间未ACK的消息设置超时时间----原因:可能消费者处理这条消息的时间本来就很长，保证消息的消费的最终一致性（只有消费者断开连接并且消息未ACK时，才会将消息给别的消费者消费）
在这里插入图片描述