阅读目录(Content)1. 丢消息检测消息丢失的方法确保消息可靠传递1. 生产阶段2. 存储阶段3. 消费阶段2. 重复消息消息重复的情况必然存在用幂等性解决重复消息问题1. 利用数据库的唯一约束实现幂等2. 为更新的数据设置前置条件3. 记录并检查操作3. 消息积压问题优化性能来避免消息积压1. 发送端性能优化2. 消费端性能优化消息积压的紧急处理如何保证消息的严格顺序？
RocketMQ简介RocketMQ领域模型如何让消息“丢失”小结：如果你担心某种情况发生，那么它就更有可能发生。的数字化之路格物致知 知行合一 记录开悟时的小欢喜 也希望能帮助更多人成为优秀的软件开发人员109篇原创内容公众号RocketMQ 简介RocketMQ 5.0： 云原生“消息、事件、流”实时数据处理平台，覆盖云边端一体化数据处理场景。RocketMQ领域模型 如上图所示，Apache
消费者与消费者组消费者（Consumer）负责订阅Kafka中的主题（Topic），并且从主题上拉取消息。Kafka中还存在消费者组（Consumer Group）的概念。每一个消费者都有一个对应的消费者组。当消息发布到主题后，会被投递给订阅它的消费者组中的一个消费者。Kafka支持两种消息投递模式：点对点（P2P，Point-to-Point）模式和发布订阅（Pub/Sub）模式.点对点模式基于
转载
2024-05-15 11:50:31
50阅读
Relay log 导致复制启动失败今天在使用冷备份文件重做从库时遇到一个报错，值得研究一下。一、报错现象dba:(none)> start slave;ERROR 1872 (HY000): Slave failed to initialize relay log info&nbs
通常在生产环境，我们的每个服务都不会以单节点的方式运行在生产环境，当同一个服务启动多个实例的时候，这些实例都会绑定到同一个消息通道的目标主题（Topic）上。默认情况下，当生产者发出一条消息到绑定通道上，这条消息会产生多个副本被每个消费者实例接收和处理（出现上述重复消费问题）。但是有些业务场景之下，我们希望生产者产生的消息只被其中一个实例消费，这个时候我们需要为这些消费者设置消费组来实现这样的功能
转载
2024-03-16 14:28:03
162阅读
1.消息队列解决什么问题？a.异步处理，对于一些实时性要求不是很强的业务（短信，邮件）可以用消息队列来异步处理，提高系统响应效率。b.应用耦合，减少应用的耦合性，比如订单系统和库存系统之间通过消息队列分离开来，即使库存系统暂时不可用，也不影响订单系统的使用。c.流量削锋，秒杀系统等并发量比较高的情况，为了防止系统卡死，可利用消息队列来排队。如果队列过长，还可以控制不再写入队列。b.消息通讯，实现点
缓存预热缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！现象： 项目刚上线，服务器迅速宕机。问题排查：1、请求数量较高2、主从之间数据吞吐量较大，数据同步操作频度较高3、
转载
2023-08-07 22:32:42
16阅读
文章部分图片来自参考资料，侵删概述我们从前面的发送流程知道某个主题的消息到了broker 的 messageque 里，假如让我们来设计一个消息队列的消费者过程，那么多个消费者应该如何消费数量较少的 messagequeue 呢？消费者有两种消费模式 ： 广播模式和集群模式 ，广播模式很好理解就是消费所有的消息；集群模式相当于多个消费者逻辑上认为是一个整体，最通俗的理解就是一个消息在集群里面只有一
转载
2024-03-23 15:11:06
95阅读
本文来说下kafka的基本概念与术语 文章目录消息队列kafka架构图Kafka相关概念及术语本文小结 消息队列把数据放到消息队列叫做生产者。从消息队列里边取数据叫做消费者。消息队列，我们一般简称为MQ(Message Queue) 队列是我们常说的一种先进先出的数据结构。消息队列可以简单理解为：把要传输的数据放在队列中。消息队列的两种模式：点对点：生产者生产消息发送到队列中，消费者从队列中取出并
转载
2024-04-24 22:10:41
65阅读
消息队列MQ面试题：介绍一下消息队列消息队列关于这个问题主要从三个方面回答。第一，消息队列是应用之间异步通信的方式，主要由三个部分组成。生产者，消息所承载业务信息的一个实例化，整个消息的发起方。中间的broker是消息的服务端，主要是处理消息单元，负责消息的存储、投递等功能，是核心部分。消费者，主要负责消息的消费，具体是根据消息承载的信息处理各种逻辑。第二，应用场景。主要分为三种1.异步处理，在实
转载
2024-03-26 12:48:12
27阅读
在我的工作中，常常会遇到“iOS推送不及时”的问题。这类问题不仅会影响用户体验，还可能导致关键的时效信息无法及时传递。为了帮助大家更好地理解如何解决这一问题，我特地记录下这次的探索与调试过程。
> ### 用户原始反馈
> 我们收到用户反馈：“我总是错过重要的推送通知，感觉推送总是慢半拍。”
#### 时间轴
- **第1天**：用户首次反馈推送延迟。
- **第2天**：团队内部讨论，并收集
不知道大家有没有遇到这样的事情，那就是微信经常延迟接收消息，明明别人早就将消息发过来了，但是等到自己收到时，却发现已经过了好几分钟了。如果错过了重要消息，还是很让人烦恼的，那微信消息为什么会延迟接收呢？有什么解决办法吗？下面笔者教你调整这几个设置，帮你轻松解决。为什么接收消息会延迟1. 微信自身服务器问题
转载
2023-09-22 18:54:14
237阅读
常见问题：ContentSizeFitter,适应宽高刷新不及时 特别是用ContentSizeFitter来处理Text时，真的烦 可以通过以下代码来手动刷新 GameObject obj=GameObject.Find("xxx/xxx"); //obj是挂在了ContentSizeFitter ...
转载
2021-08-03 12:27:00
233阅读
RabbitMQ延时消息队列延时队列即放置在该队列里面的消息是不需要立即消费的，而是等待一段时间之后取出消费。那么，为什么需要延迟消费呢？就拿购物商城来讲吧：网上商城下订单后一定时间后没有完成支付，取消订单。这里将下订单称为系统创建预约。系统创建了预约之后，需要在预约时间到达前一小时提醒被预约的双方参会系统中的业务失败之后，需要重试。这种场景是很常见的，我们可以思考，比如：?第二个需求，系统创建了
转载
2024-09-03 14:07:36
63阅读
1、如何保证消息不被重复消费？一、为什么会出现重复消费的问题？ RabbitMQ、RocketMQ、Kafka 都有可能出现重复消费的问题，导致重复消费的原因可能出现在生产者，也可能出现在 MQ 或 消费者。这里说的重复消费问题是指同一个数据被执行了两次，不单单指 MQ 中一条消息被消费了两次，也可能是 MQ 中存在两条一模一样的消费。生产者：生产者可能会重复推送一条数据到 MQ 中，为什么会出现
转载
2024-02-17 08:27:15
291阅读
怎么保证消息不被重复消费?（消息队列消费的幂等性）先大概说一说可能会有哪些重复消费的问题。首先就是比如rabbitmq、rocketmq、kafka，都有可能会出现消费重复消费的问题，正常。因为这问题通常不是mq自己保证的，是给你保证的。然后我们挑一个kafka来举个例子，说说怎么重复消费吧。kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后con
转载
2024-04-22 14:01:53
59阅读
重复消费重复消费如何产生的，图是正常消息执行过程。原因一1、生产者发送给消息队列以后，消息队列会应达给生产者，但是这个过程中，消息队列出问题了没有收到消息，那么生产者就会重复发生消息，这时就产生了重复消息。 2、生产者发生消息给消息队列，消息队列由于数量太大延迟了，生产者等待响应超时了，这时生产者又会从新发生消息给消息队列。 3、生产者和消息队列因网络问题引起，生产者会发起重试。这样也会产生重复消
转载
2024-03-26 13:08:48
31阅读
正在上传…重新上传取消一、基础篇1、为什么需要消息队列？1.1、异步处理秒杀系统需要解决的核心问题是，如何利用有限的服务器资源，尽可能多地处理短时间内的海量请求。我们知道，处理一个秒杀请求包含了很多步骤，例如：风险控制；库存锁定；生成订单；短信通知；更新统计数据。如果没有任何优化，正常的处理流程是：App 将请求发送给网关，依次调用上述 5 个流程，然后将结果返回给 APP。对于这 5 个步骤来说
转载
2024-05-03 16:42:53
95阅读
概念从字面理解，本质就是队列，FIFO先入先出，只不过队列中存放的是Message而已，是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是常见的上下游“逻辑解耦+物理解耦”的消息通信服务，在使用MQ之后，消息发送上只需要依赖MQ，不用依赖其他服务。功能1.流量削峰比如说，如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时是没有问题的，正常时段我们下单一秒后就能返回结
转载
2024-05-14 23:08:11
185阅读
努力只能及格，拼命才能优秀 Success自述发布/订阅发布/订阅模型分解临时队列/绑定Ending 自述前段时间有点忙，所以断更了，接下来接着更新,RabbitMQ的第三个场景------订阅者(publish)/发布者(Subscribe)。发布/订阅 工作队列背后的假设是每个人物都会交付给一个工作者，在该场景(发布/订阅)----我们将向多个消费
转载
2024-06-22 08:44:25
61阅读
