RocketMQ 怎么保证的消息不丢失？

最新推荐文章于 2024-05-15 04:52:44 发布
最新推荐文章于 2024-05-15 04:52:44 发布
阅读量103 收藏
点赞数
分类专栏： 进阶知识点
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/aishenla/article/details/113868842
版权

三个阶段

produce阶段：总结为几个字就是：同步发送+自动重试机制+多个Master节点

broker阶段：同步异步刷盘+主从模式

Consumer消费阶段：业务逻辑完成后手动进行ack确认+自动重试

参考文章：https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247493757&idx=1&sn=914ba23493199e1e4fd34be063f0215f&chksm=ebd5d751dca25e4752c921f4250c98fab02c8741c107e9b97bc257fce8c75dfdfb4c9eab307e&scene=21#wechat_redirect

轮子飞了
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
RocketMQ实践：确保消息不丢失与顺序性的高效策略
12-23
在使用Apache RocketMQ时，确保消息的不丢失和顺序性是维持系统稳定性和可靠性的重要方面。RocketMQ提供了多种策略来解决这些问题。 一、确保消息不丢失 1. 环节中的丢消息可能性：在消息的生产、传输、存储和消费...
rocketmq消息队列
08-05
3. 消息持久化：RocketMQ支持消息的持久化存储，即使在系统故障后，也能保证消息不丢失。 4. 顺序消息：对于对消息顺序有严格要求的应用，RocketMQ提供了一种保证消息全局有序的功能。 5. 分布式事务：RocketMQ支持...
RocketMQ消息丢失解决方案：事务消息.docx
10-26
RocketMQ 消息丢失解决方案：事务消息 在本文中，我们将讨论如何解决 RocketMQ 中的消息丢失问题，特别是在生产者发送消息到 MQ 过程中的消息丢失问题。我们将介绍 RocketMQ 的事务消息机制，如何使用事务消息来...
2024年最全RocketMQ消息丢失场景及解决办法_rocketmq如何处理消息丢失(1)，Jetpack-MVVM-高频提问和解答
最新发布
2401_84911322的博客
05-15 789
如果消费者还没有返回CONSUME_SUCCESS时就宕机了，那么RocketMQ就会认为你这个消费者节点挂掉了，会自动故障转移，将消息交给消费者组的其他消费者去消费这个消息，保证消息不会丢失。只有返回了CONSUME_SUCCESS，消费者才会告诉RocketMQ我已经消费完了，此时如果消费者宕机，消息已经处理完了，也就不会丢失消息了。上面这段代码中，RocketMQ在消费者中注册了一个监听器，当消费者获取到了消息，就会去回调这个监听器函数，去处理里面的消息。那么如何保证消息的零丢失呢？
SpringBoot整合rocketmq事务消息
02-13
4. **事务消息的补偿策略**：在事务消息的处理过程中，可能会出现网络问题导致消息丢失或者重复，这时我们需要设计合理的补偿策略，如幂等性设计，确保业务不受影响。 5. **应用示例**：在提供的`transaction-...
redis在滑动窗口的实现
aishenla的博客
07-01 1604
整体思路:每一个行为到来时，都维护一次时间窗口。将时间窗口外的记录全部清理掉，只保留窗口内的记录。zset集合中只有score值非常重要，value值没有特别的意义，只需要保证它是唯一的就可以了。 当然，上述几个连续的redis操作都是针对同一个key的，使用pipeline可以显著提升redis的存取效率，还可以增加事务控制。但这种方案也有缺点，如果这个量很大，如60s内100万次，则不适合做这样的限流，会消耗大量的存储空间。 import redis.clients.jedis.Jedis; publ
红黑树与AVL树，各自的优缺点总结
aishenla的博客
02-26 1157
RB-Tree和AVL树作为BBST，其实现的算法时间复杂度相同，AVL作为最先提出的BBST，貌似RB-tree实现的功能都可以用AVL树是代替，那么为什么还需要引入RB-Tree呢？ 红黑树不追求"完全平衡"，即不像AVL那样要求节点的 |balFact| <= 1，它只要求部分达到平衡，但是提出了为节点增加颜色，红黑是用非严格的平衡来换取增删节点时候旋转次数的降低，任何不平衡都会在三次旋转之内解决，而AVL是严格平衡树，因此在增加或者删除节点的时候，根据不同情况，旋转的次数比红黑树要多。 就插
JVM性能调优及关键调优参数详解
aishenla的博客
02-25 534
JVM内存调优 对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。 1.Full GC 会对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比较慢，因此应该尽可能减少Full GC的次数。 2.导致Full GC的原因 1)年老代（Tenured）被写满 调优时尽量让对象在新生代GC时被回收、让对象在新生代多存活一段时间和不要创建过大的对象及数组避免直接在旧生代创建对象 。 2)持久代Pemanet Generation空间不足
RocketMQ的Consumer是如何做的负载均衡？
aishenla的博客
02-19 453
RocketMQ的Consumer是如何做的负载均衡？比如：5个Consumer进程同时消费一个Topic，这个Topic只有4个queue会出现啥情况？反之Consumer数量小于queue的数据是啥情况？ 1 queue个数大于Consumer个数，且queue个数能整除Consumer个数的话， 那么Consumer会平均分配queue。（比如上面表格的Consumer有2个 可以整除部分） 2 queue个数大于Consumer个数，且queue个数不能整除Consumer个数的话， 那么会有一个
Redis与数据库一致性问题解决方案
aishenla的博客
03-17 419
1、先删缓存，再更新数据库 该方案会导致不一致的原因是。同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形: （1）请求A进行写操作，删除缓存 （2）请求B查询发现缓存不存在 （3）请求B去数据库查询得到旧值 （4）请求B将旧值写入缓存 （5）请求A将新值写入数据库 上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。 那么，如何解决呢？采用延时双删策略 伪代码如下 public void write(String key,Object d
Redis高并发的解决方案
aishenla的博客
12-30 415
使用Redis实现分布式锁最简单的方案是在获取锁之前先查询一下以该锁为key对应的value存不存在，如果存在，则说明该锁被其他客户端获取了，否则的话就尝试获取锁，获取锁的方法很简单，只要以该锁为key，设置一个随机的值就行了。比如，我们有一批任务需要由多个分布式线程处理，每个任务都有一个taskId，为了保证每个任务只被执行一次，在工作线程执行任务之前，先获取该任务的锁，锁的key可以为taskId。因此，获取锁的过程可以用如下伪代码实现： function boolean getLock(taskId)
Spring循环依赖以及解决方式
aishenla的博客
03-15 404
Spring为了解决单例的循环依赖问题，使用了三级缓存。 这三级缓存分别指： 3 singletonFactories ： 单例对象工厂的cache 2 earlySingletonObjects ：提前暴光的单例对象的Cache 1 singletonObjects：单例对象的cache Spring首先从一级缓存singletonObjects中获取。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactorie
InnoDB与MyISAM 聚集索引与非聚集索引
aishenla的博客
03-24 308
InnoDb： 支持acid事务，支持行级锁和外键约束，容灾性好，可建立缓冲池存数据及索引，不保存行数，锁粒度为行。 MyLASM： 不支持事务，外键，读写时需锁表，效率低，保存了行数，读多于写时可选择。复合索引速度快于innodb 聚簇索引和非聚簇索引： InnoDB使用的是聚簇索引，MyLASM使用非聚簇索引，对于聚簇索引存储来说，行数据和主键B+树存储在一起，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说，主键B+树在叶子节点存储指向真正数据行的指针，而非
mysql如何高效的设计索引
aishenla的博客
07-01 282
MySQL中的索引 索引是一个基于链表实现的树状Tree结构，mysqlInnoDB引擎使用的是b+树，根节点不存数据，只存储指针地址，最下端的叶子节点才存储数据，叶子结点一点构成一条双向链表，方便区间查找。 聚集索引 主键id是聚集索引，存储着整行数据，例如表users(id, user_id, user_name, phone, primary key(id))，id是聚集索引，存储了id, user_id, user_name, phone整行的数据。 辅助索引 辅助索引也称为二级索引，索引中除了存储
Redis的缓存穿透——布隆过滤器BloomFilter
aishenla的博客
03-03 264
什么是缓存击穿 在高并发场景下，如果某一个key被高并发访问，没有被命中，出于对容错性考虑，会尝试去从后端数据库中获取，从而导致了大量请求达到数据库，而当该key对应的数据本身就是空的情况下，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力。 在高并发的场景下，缓存相当于数据库的防火墙，如果用一个肯定不存在的key去访问系统，每次都会绕过缓存去访问数据库，缓存则失去了作用。 BloomFilter原理： 简单的说就是：通过将一个key的hash值分布到一个大的bit数组上面，判断一
elk+kafka+zookeeper整体架构及安装
aishenla的博客
03-25 223
elk+kafka+zookeeper整体架构，安装部署 kafka架构组件概念详解 Zookeeper 在 Kafka 中的作用
nginx安装配置（笔记整理）
aishenla的博客
12-23 206
Nginx 的安装 1 、准备工作 （1 ）打开虚拟机，使用远程连接工具连接 linux 操作系统 （2 ）到 nginx 官网下载软件 http://nginx.org/ 2 、开始进行 nginx 安装 （1 ）安装 pcre 依赖 第一步 联网下载 pcre 压缩文件依赖 wget http://downloads.sourceforge.net/project/pcre/pcre/8.37/pcre-8.37.tar.gz 第二步 解压压缩文件 使用命令 tar –xvf pcre-8.37.
说一下公平锁和非公平锁的区别？
aishenla的博客
03-10 165
**公平锁：按照队列顺序，一个接一个的获取锁 优点：所有线程都能得到资源 缺点：吞吐量会降低，唤醒下一个线程的cpu开销比较大 非公平锁：无需排队，直接去获取锁，获取不到则会回到队列继续等待，合适时机可随时再去获取 优点：吞吐量加大，无需唤醒其他线程 缺点:会有部分线程从头至尾都获取不到锁，导致线程饿死** 参考文章：https://www.imooc.com/article/302143 ...
为什么B+树适合作为索引
aishenla的博客
02-26 156
B-Tree适合作为索引 平衡二叉树不适合作为索引。那么什么才适合作为索引——B树。 平衡二叉树没能充分利用磁盘预读功能，而B树是为了充分利用磁盘预读功能来而创建的一种数据结构，也就是说B树就是为了作为索引才被发明出来的的。 来看看关于“局部性原理与磁盘预读”的知识： 复制代码 局部性原理与磁盘预读： 由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读
rocketmq保证消息不丢失
05-20
RocketMQ 通过多种机制来确保消息不丢失，包括： 1. 消息持久化：RocketMQ 会将发送的消息持久化到磁盘上，即使在重启后也可以恢复。 2. 同步刷盘：RocketMQ 允许用户配置同步刷盘，这意味着在消息被发送到服务器...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值