qq_21277357的博客

1.直连交换机，通过Routing Key精确匹配队列，就是生产者发送消息的时候，必须传入Routing Key，然后通过Routing Key匹配到(队列和交换机绑定的Routing Key)，消费者有这个匹配到的队列，才能收到消息。3.主题交换机, 就是生产者绑定队列，并设置路由规则，设置*或者#，只要消费者队列在这个范围内能匹配到的，就能收到消息。4.默认交换机，生产者可以不用创建队列名称，通过路由键的名字来当做队列名称，1个生产者对应1个消费者。

2.如果不支持更改生产者的代码，必须立马就要解决，那么启用备份的队列，把这些消息转移到备份的队列中，并且设置监控报警，通知程序员，去进行手动解决。1.现在可以改生产者的代码吗？如果可以，那么可以设置限流，或者批量发送。3.如果允许丢弃，那么丢弃一些没有必要的消息。4.使用多线程 进行处理。

3.然后使用策略模式+工厂模式，调用对应的消费厂家的实现类。1.在发送消息的时候，设置一个厂家id。2.在消费消息的时候，解析这个消息id。

6.也可以通过普通队列的过期时间+死信队列来实现延迟队列。2.在配置类配置交换机，队列，绑定，路由键等信息。4.在消费者类设置监听的注解，来消费消息。3.在生产者调用send方法发送消息。5.延迟队列可以通过一个插件来实现。1.在pom.xml引入对应的包。

2.但是rabbitmq开启事物之后,会降低rabbitmq的吞吐量，影响rabbitmq的性能。1.rabbitmq是支持事物的，可以使用命令来开启事物，提交事物，回滚事物。

2.在流量高峰的时候，把消息放入队列，进行排队，防止系统出现崩溃。1.mq是消息队列，生产者把消息放入队列，消费者去消费这条消息。3.mq是异步的场景，不需要等待对方消费完毕就直接结束。4.mq的消息不会丢失，支持持久化和消息重试。

那么我们可以增加磁盘的容量，清理不重要的数据，使用mq集群。消息是一值持久化到磁盘上的，如果磁盘不够了。

1.检查网络和硬件设备，确保能够正常工作。4.增加消费者的数量，加快消息的处理速度。5.当主交换机发送超时，使用备份交换机。2.减少发送消息的频率。

kafka会检查这个id有没有消费topic。如果已经存在，那么就不会再发送消息给消费者。kafka每一个消费者都有一个唯一的id。

把topic的分区设置成1个或者在发送消息的时候，指定Partition Key（分区key）Kafka会对这个分区key进行哈希计算，把消息放入对应的分区。

消息重试，队列重试，yml文件配置retry 设置重试次数和间隔时间。

如果生产者发送消息失败，那么使用重试，如果重试3次之后，还不行，那么把消息发送到备份交换机，由备份交换机发送消息，如果备份交换机也发送失败，那么设置监控报警，通知程序员去解决这个问题。如果是消费者消费失败，那么使用重试，如果重试3次之后还不行，那么把消息放入死信队列中，并设置监控报警，通知程序员去解决这个问题。

生产者发送消息到交换机，并且设置过期时间，到了时间之后，在从交换机上把消息。

如果使用http的话，需要等待对方落库成功之后，才能往下走，需要点时间。B系统添加失败，只需要处理自己的业务逻辑问题，然后再进行重试消费。并且mq还会进行排队，大量的请求打进来，不会造成系统崩溃。如果调用B系统的接口添加失败，也会导致A系统无法往下走。但是使用mq的话，他是异步的，不需要等待，提高系统性能。我们的A系统，在商户模块进行添加，修改,删除了的时候。都会发送一个消息到B系统，B系统根据传过来的类型。进行落库到自己的商户表中，做一个数据同步的功能。A系统添加成功后，不需要管B系统是否添加成功，

kafka会创建一个主题-分区.log命名的日志文件，记录消息。kafka使用多副本机制实现消息持久化。默认保存7天，可以通过配置进行修改。

生产者发送消息的时候，需要指定一个路由键，交换机会根据路由键把消息发送到对应的队列中。: 存储消息的容器，消费者从队列中获取消息并处理。: 接收生产者发送的消息，将消息发送到队列中。：交换机和队列进行绑定，定义消息的路由规则。：发送mq消息到消息队列中。: 消费mq消息队列的消息。：生产者发送的消息内容。

生产者开启confirm模式，消息持久化，消费者手动ACK。

发送有序，消费有序 就能保证消息的顺序性。

简单模式，工作模式，发布订阅模式，主题模式，路由模式。

高并发点赞与mysql和redis缓存最终一致性

1.扩容机器2.如果没有可以扩容的机器，那么把积压的消息，重试3次都失败了，放入一个新的队列中，保障正常的队列能够继续运行，然后把新的队列的数据从平台上手动提取，然后紧急处理，解决完毕后，把新的队列的数据删除掉，然后更新版本，这样就解决了消息积压

kafka3.x入门教程（五）

阿诗丹顿。

如果下面的没有显示3，那么把所有节点的kafka都停掉，重新启动。可以看到当前副本还是在0 1 2,并没有显示我们的3。创建一个执行计划，我们这里就是只写0,1,2 不要3。创建副本存储计划，之前的数据删除掉，换成新的内容。我们要查看zookeeper的更好看的界面。我们把第三个kafka节点停掉，看下效果。创建一个要均衡的主题，我们上面已经创建了。我们在开启一台新的节点，上传kafka。我们在把第四台节点的kafka停止掉。接下来我们在看下，节点的服役和退役。可以看到0,1,2,3在副本都有了。

消费者没有收到消息，这是因为当前使用的命令是只接收当前运行中发送的消息，历史消息不会接收。如果没有指定分区，但是设置了key,那么按照key的hash取余放入不同的分区；比如有100T的数据，直接发送太多了，我们就把主题分成多个区，每个区发送一部分。如果没有指定key和分区，只写了value,那么会随机选择一个分区，一直使用，等到该分区batch满了或者已完成，kafka在随机选择一个新的分区进行使用。至于使用历史的还是当前的，根据你的业务场景来使用；合理的控制分区的任务，可以实现负载均衡的效果。

发布订阅模式：生产者发送到不同的主题中，不同的消费者 订阅不同的主题，1个主题可以对应多个消费者；点对点模式：生产者发送消息到队列，消费者消费消息，队列把消息删除；在项目中常用的就是发布订阅模式；

如果存在redis,判断是否进行业务处理，如果已经处理过，那么停止；解决方案就是，使用全局消息id+redis的setnx,来判断；消息幂等就是消费者在手动应答的时候，出现了故障，导致宕机；如果不存在redis,存入redis,并进行消费，业务处理。再次启动消费者的时候，发现又消费了一次，这就是消息幂等；

在生产者开启队列的持久化，消息的持久化，发布确认，在消费者手动应答；

遇到mq的消息堆积，可以先把消费者的预取值设置为1，不公平分发，这样一个消费者堆积消息，在开启一个新的消费者来消费消息，这样控制台最终会剩下1条消息没有被消费，这时候在控制台点击get message获取消息，手动处理，然后把这条队列删除掉，这样就可以解决消息堆积。

队列持久化：mq宕机后，如果不开启持久化，那么队列就会丢失，如果开启持久化Features就会显示一个大写的D。消息持久化：当mq宕机后，消息保存在磁盘中，mq启动后，消息恢复。

手动应答：消费者接收消息，代码处理完之后，成功消费消息，不会存在消息丢失的问题,在工作中，尽量使用手动应答；消费者消费消息的时候，消费者挂掉了，这时候，可能存在消息丢失的问题，rabbitmq引入了消息应答的机制；自动应答：消息者接收消息，就会删除消息,但是在代码还没有处理完，可能会存在消息丢失；消息应答：当消费者成功消费消息后，rabbitmq才把这条消息删除掉。

遇到mq的消息堆积，可以先把消费者的预取值设置为1，不公平分发，这样一个消费者堆积消息，在开启一个新的消费者来消费消息，这样控制台最终会剩下1条消息没有被消费，这时候在控制台点击get message获取消息，手动处理，然后把这条队列删除掉，这样就可以解决。如果有一个消费者消费快,一个消费者消费慢，那么这时候我想要消费快的那个多干点活，这时候，我们把消费者2宕机，可以看到，消费者1接收到了消息，这就是手动应答。接下来我们在重启mq,可以看到消息也恢复了，这就是消息的持久化。

这个时候我们使用mq,A服务调用B服务，B服务先返回一个成功给A，A不需要在继续等待，B继续处理任务，处理成功把数据发送给mq,然后mq再发送给A服务，这就是mq的。A服务调用B服务的时候，等待处理特别耗时间，

有一个子系统出现故障，中单用户是无感知的，用户可以正常完成订单，mq会监督子系统的修复，这就是mq的。当订单系统使用mq的时候，订单系统完成之后，发送到mq,mq再去监督库存系统，和支付系统，订单系统在调用，库存系统，支付系统的时候，任何一个系统发送了故障都会导致下单失败，

这时候我们使用mq,用户先访问mq,mq在去访问订单系统，mq内部自带排队，这样就可以解决订单系统崩溃的问题，在用户请求订单系统的时候，订单系统的上限设置了10万个请求，如果超过了这个请求，那么订单系统可能会崩溃，