MQ高级 可靠性-兜底-延迟消息

最新推荐文章于 2024-08-26 16:58:48 发布
最新推荐文章于 2024-08-26 16:58:48 发布
阅读量391 收藏 3
点赞数 3
分类专栏： 微服务 文章标签： 微服务
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_48362854/article/details/140702356
版权

MQ高级 有点累了 没有具体操作 只是大概的写一下自己的理解

具体文档day07-MQ高级

可靠性

如果要实现消息队列的可靠性 那么就得保证这三个 生产者 消息队列 消费者各自可靠

很简单的概念就没解释

LazyQueue 懒队列 就是不加载到内存 直接写入磁盘 更稳定 有点类似于在word里边自动保存 如果写入内存 就像写word 没保存但是突然卡退了 就会导致不可靠 感觉就像是解决这种问题的

消费者失败重试到最大次数后 会进行失败处理策略

                 1.直接丢了

                 2 重新入队

                 3 转给专人处理

所谓幂等性 就是x平方=x 就是多次执行结果不变 比如 查询 但是更新 显然不满足幂等性

解决幂等性（不让这个业务重复执行）有俩解决办法

                 一个就是写入唯一的消息id 但是这个不好 会改数据库

                另一个就是自己写业务逻辑（代码判断）

兜底方案

简单 就是用定时器 定时查询状态 防止出现异常

延迟消息

死信交换机：收集无效消息

利用死信交换机完成延迟消息：就是比如我要延时5分钟 我就把消息设置5分钟的TTL 然后过了时间就会转入死信交换机 通过交换机在转给消费者

        缺点就是 很明显 无法控制时间 通过死信交换机在转发的时间没法控制

DelayExchange：RabbitMQ社区提供了一个延迟消息插件来实现相同的效果。就是为了解决上边完成延迟消息缺点的更优解。

超时订单 就是利用mq 发延时消息15分钟 然后设置监听

遇上彩虹pkq
关注
  • 3
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MQ - RabbitMQ - 消息的可靠性 --学习笔记
m0_71386740的博客
07-18 942
消息队列（MQ）的生产者重试机制是指当生产者尝试将消息发送到消息队列中时，如果因为某些原因（如网络问题、队列不可用或其他任何导致消息发送失败的问题）导致消息未能成功发送，那么生产者会根据预设的策略尝试重新发送消息的过程。生产者确认机制是一种确保消息从生产者安全达到消息队列的方法，尤其是在使用像RabbitMQ这样的消息中间件时，这种机制尤为重要。生产者确认（Publisher Confirms）也被视为是一种可靠性保障，使得生产者在发送消息后可以知晓该消息是否已被消息队列成功接收。
SpringCloud微服务03-微服务保护-分布式事务-MQ基础-MQ高级
qq_52439738的博客
05-21 861
这就存在一个问题：如果用户一直未支付，交易服务处理失败，此时库存已经扣减，但未卖出，存在数据不一致。2.内存的空间有限，如果瞬间来了很多消息，它会满了后再向磁盘写入，这样会造成阻塞，如果是持久化消息，来一个会先进入内存然后写入磁盘一个，不会造成阻塞，效率更高。故障隔离的原理是我把消息给消息代理了就不管了，消息代理会一直发送消息给你，你出现故障了，也会一直给你发消息，直到你能处理好之后停止。此时使用延迟消息，交易服务生成订单后，会向自己发送延迟消息，查看订单状态，为未支付会修改库存等。
RabbitMQ高级-rabbitMQ消息队列高级部分笔记
weixin_73355042的博客
06-02 596
每个只能配置一个，因此我们可以在配置类中统一设置。我们在publisher模块定义一个配置类：内容如下：@Slf4j@Overridelog.error("触发return callback,");});由于每个消息发送时的处理逻辑不一定相同，因此ConfirmCallback需要在每次发消息时定义。具体来说，是在调用RabbitTemplate中的convertAndSend方法时，多传递一个参数：id。
MQ的可靠性
computers11的博客
05-22 839
消费者如何保证消息一定被消费？开启消费者确认机制为auto,由spring确认消息处理成功后返回ack,异常时返回nack开启消费者失败重试机制，并设置MessageRecoverer,多次重试失败后将消息投递到异常交换机，交由人工处理。
架构师系列-消息中间件（八）- RocketMQ 进阶（二）-生产端消息保障
dengwei_dw的专栏
04-25 877
发送方式发送 TPS发送结果反馈可靠性适用场景同步发送一般有不丢失重要的通知场景异步发送快有不丢失比较注重 RT（响应时间）的场景单向发送最快无可能丢失可靠性要求并不高的场景通过这段源码很明显可以看出以下几点如果是异步发送默认重试次数是两次，通过递归的方式进行重试对于同步而言，超时异常也是不会再去重试。同步发送重试是在一个for 循环里去重试，所以它是立即重试而不是隔一段时间去重试。
利用本地消息表和MQ解决消息可靠性
weixin_33895604的博客
05-12 1879
2019独角兽企业重金招聘Python工程师标准>>> ...
微服务开发与实战Day07 - MQ高级篇
ltt159264的博客
06-14 940
首先，分析一下消息丢失的可能性有哪些。消息从发送者发送消息，到消费者处理消息，需要经过的流程是这样的：消息从生产者到消费者的每一步都可能导致消息丢失：综上，我们要解决消息丢失问题，保证MQ的可靠性，就必须从3个方面入手。
【SpringCloud】微服务6—消息队列MQ高级
m0_73509988的博客
07-28 604
每个RabbitTemplate只能配置一个ReturnCallback，因此我们可以在配置类中统一设置。log . error("触发return callback,");} });} }log . error("触发return callback,");} });} }Slf4j;import orglog . error("触发return callback,");} });} }
RocketMQ快速入门：如何保证消息不丢失｜保证消息可靠性（九）
55555的博客
06-20 1691
在金融、电商等对数据完整性要求极高的行业，消息的丢失可能会导致数据不一致，严重影响业务逻辑和数据统计，也影响客户体验，所以在很多业务场景下，我们都要求数据不能丢失。而rocketmq中，如何对消息防丢失进行处理的呢？
消息中间件MQ-基于RabbitMQ分布式事务处理
qq_30531735的博客
06-25 421
一、回顾 1.消息中间件核心概念 消息中间件，本质就是接收数据、保存数据、发送数据的网络应，常常应用在分布式架构系统中，实现业务服务（系统）之间拆分解耦、可靠性消息通信等协同处理。基于消息（数据）传递和消息队列，实现跨进程的通讯。 理解上可以认为是一个外置的queue队列，但需要协同不同的服务或系统，所以复杂的多，一般的消息中间件设计核心有5个： 支持的协议–解决消息通讯的问题 持久化机制–消息数据存入磁盘 消息分发机制–发布订阅（推送）、拉取、重发等，解决消息消费方式 高可用机制–支持集群部署，实现高
MQ消息中间件
qq_41973154的博客
12-13 4131
消息中间件知识点总结-RabbitMQ,延时队列、优先级队列、惰性队列
rocketmq - 新手入门
qq_30022651的博客
05-21 1342
环境搭建 集群 单机 网上自己拉 遇到的坑： -内存溢出 修改配置（测试机太小） -多broker一条服务器启动 必须多个store路径 不同的端口 并且端口不要后面加一个数（本人就是加一个数 10911 第二个broker 10912 日志一直报找不到nameserver 其实是端口冲突了 ） -外网访问必须要写暴露外网IP 关闭namesrv服务：sh bin/mqshutdown namesrv 关闭broker服务 ：sh bin/mqshutdown brok
一线大厂的 MQ 组件实现思路和架构设计思路
javalingyu的博客
05-25 364
首先来看看一线大厂的 架构图 一线大厂的 架构图 如上图所示，中间是我们的 MQ 集群架构， 在上层利用 keepalived 和 HA-Proxy， 最下面是 两个大的 MQ 集群 做一个高可用。当然了，在实际大厂里面 可能就不止 两个集群了，可以是很多个集群，然后集群之间利用 federration 插件进行数据同步 。 上面的生产端组件：这里面可能就有很多的架构设计，比如生产端怎么对一个容器进行缓存，举个例子，我们生产端发送消息，都是利用 RabbitTemplate 进行，在高并发场景
基于MySql,Redis,Mq,ES的高可用方案解析
m0_71777195的博客
07-31 1225
本片文章主要是分析当下不同应用场景下的几个主流系统的高可用策略，来看一下如何来保障的系统的高可用常见的高可用思路冗余（如数据副本、主备服务等）拆分（数据拆分、服务能力拆分等）持久化redis持久化RDB数据落盘加载方式+AOF记录操作命令用于回放策略主从，主从从全量数据冗余、读写请求分离，负载均衡的思想；核心问题在于主节点挂掉之后需要人工参与手动指定主库哨兵机制PING/PONG的探活机制，监听主节点，宕机之后自动选主，确保高可用；httpshttpshttps。...
【微服务】springboot整合对象映射工具MapStruct使用详解
congge
08-25 2909
springboot 整合 MapStruct 使用详解
微服务中间件之Nacos-安装篇
一个老Java开发的自白
08-25 696
Nacos是由阿里巴巴开发的云原生应用管理平台，支持动态服务发现、配置管理。安装适用于Linux/macOS和Windows，需下载最新版本安装包并安装Java JDK 1.8+。可选配置外部数据库。Linux/macOS通过命令行解压并启动，Windows则直接解压后运行启动脚本。访问管理界面需浏览器打开http://localhost:8848/nacos，默认用户名为nacos。
Spring框架：从依赖注入到微服务
2302_78593467的博客
08-25 799
Spring框架，作为Java后端开发中最受欢迎的框架之一，以其强大的功能、灵活性和易用性，帮助开发者构建高效、可扩展的企业级应用。从简单的依赖注入到复杂的微服务系统，Spring都提供了强大的支持。通过本文的介绍和实例，希望读者能够对Spring框架有一个更深入的理解，并在实际开发中灵活应用。Spring Boot是Spring的一个子项目，它简化了基于Spring的应用开发。依赖注入是Spring框架的核心特性之一，它允许开发者将组件的依赖关系自动注入到组件中，从而减少代码的耦合性。
深入理解微服务中的负载均衡算法与配置策略
最新发布
kfashfasf的博客
08-26 854
看起来，对于实现其他的负载均衡算法策略，有几个关键点。首先，需要继承父类，并且实现其抽象方法。@Slf4j@Override//这里实现自己的逻辑即可@OverrideOK，剩下的就按照局部配置或者全局配置下，让我们的规则生效即可。在这里只讲述了算法规则的配置和自定义方法，实际上负载均衡器的操作也是类似的套路。这里就不重复演示了。今天，我们主要补充了上一章关于微服务通信的内容，并深入探讨了负载均衡算法的重要性。我们首先详细讨论了Ribbon默认使用的负载均衡算法。
分布式事务 task 兜底
08-25
分布式事务是指在分布式系统中，涉及到多个数据库或服务之间的操作时，保证数据的一致性和完整性的一种机制。由于分布式环境的复杂性，存在许多因素可能导致事务执行失败或部分失败。为了兜底处理这些失败的情况，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值